Тестування on jUst QA blog

Перше занурення у тестування – з чого почати?

Wed, 31 May 2017 23:32:58 +0300

Тестування програмного забезпечення – дивовижна сфера. На перший погляд, тут все просто – є “щось”, яке має бути “хорошим”, і є людина, яка бажає “все перевірити”. Але потім ця людина починає ходити на співбесіди, відправляти резюме – і якось “не беруть”. Так, насправді тестування далеко не така проста і банальна наука, як може здатися з реклами курсів “входу в айті”. Та й курси не завжди дешеві для тих, хто хоче “пірнути”. Як зрозуміти, чи варто Вам особисто пробувати?

Перше занурення у тестування

Почнемо з найпростішого: почитаємо Вікіпедію. Хоч довіряти їй варто на свій страх і ризик, але у визначеннях базових понять покластися можна. Але відразу обмовлюся – посилання хороше, але якщо подужаєте цю (а то і весь розділ) – відразу +50 в карму. Нехай не все буде зрозуміло, нехай важко, нехай зі словничком (благо гугл-транслейт можна в хромі налаштувати; а якщо зрозуміли, що написано до крапки з комою – то ще +50 в карму), але все найактуальніше і найсвіжіше вже років 10 (за більше не скажу – тому що 10 років тому не стежив) як з’являється спочатку англійською.

Отже, завантажили Ви себе термінами, які нічого не говорять, не хочу. Пора б і спробувати щось робити. Візьміть улюблену програму/сайт/олівець/кішку – і спробуйте подумати, поміркувати – а як би ви ЦЕ перевіряли? Спробуйте “накидати” прості перші тест-кейси. Що це за звір? Ви вже знаєте з минулого кроку. Якщо ні – повторюємо. Знайти “баги” – це не головне у тестуванні. Головне зрозуміти, що це таке, яким його хочуть бачити. Хто хоче? Ті, хто ЦИМ користується. А оскільки Ви взяли Вашу улюблену програму / кішку / кофтинку – то “тестуйте на собі”.

Вийшло накидати 20 тест-кейсів? Не набридло? Не нудно? Здорово! А 50? А як написати 50 КОРИСНИХ тест-кейсів? Ось тут пораджу цей блог. Олексій – ще той оповідач (шукаємо відео і дивимося), “ріже” по небажаю – але змушує думати. Особисто спілкуватися не доводилося, але в “нашомовній” “ком’юніті” один із тих людей, до критики кого варто дослухатися.

Далі

А далі що? Далі залежить від того, що Ви зараз відчуваєте. Тому що це перше занурення і навіть якщо весь контент (Ви ж знаєте, що це слово означає?) Вікіпедії вивчили напам’ять – поспішаю засмутити. Ви ще нічого не знаєте. Питання лише у тому, чи готові йти далі. Тому що далі книги, ютюб, океан технічних знань (те, що Ви не збираєтеся бути в майбутньому в програмуванні ще не означає, що “ручний кьюей” уникне скриптів), спроби продати себе на співбесіді, видавши за “синьйора з трирічним досвідом” ( у деяких виходило), курси (опціонально; ІМХО, на курси варто йти якщо у Вас вже є питання, а відповісти нікому, а не якщо є останні зайві тисячі і хочете загребати мільйони) і практика-практика-практика… І глибокого осягнути ВСІ сфери тестування одна людина ніколи не зможе, не спокушайтеся.

Ну звичайно ж, як я міг забути: http://software-testing.ru/ та стрічка блогів. Та й спробуйте вирішити завдання. Прості, банальні, але для розминки підійде.

Логіка у тестуванні

Wed, 17 Aug 2016 23:22:21 +0300

Існує безліч жартів, анекдотів, наукових праць, книг та іншого про те, що жіноча та чоловіча логіка різні. Найдивовижніше, що так воно і є насправді! І, по-хорошому, її необхідно враховувати при UX-тестуванні. Тому як леді та джентльмени приділятимуть увагу одному і тому ж елементу сторінки (діалогу, вікна, програми) по-різному. У цьому випадку можна сказати що робота тестувальника виявляється сильно межує з роботою психолога.

Логіка

Але… Мені доводилось також працювати з клієнтами з різних предметних областей, з різних країн. І результатом хотів би “налякати” тих, хто тільки вступає на тернистий шлях QA. Логіка професій, логіка людей різних національностей також відрізняється! І не варто завжди покладатись на інтуїцію, коли тестуєте не повністю задокументовані вимоги. Уточнюйте у бізнес-аналітиків (клієнта) нюанси та тонкощі, тому що для німця касира 1+1=2, а для шведа архітектора може виявитися 1+1=10.

Висновки

Завжди пам’ятайте, що людина, яка замовляє музику, може любити зовсім іншу, ніж Ви. І дорого буде оплачувати замовлений концерт симфонічного оркестру із власної кишені, якщо насправді клієнтом очікувалась група стилю кантрі. Ось така логіка

200 дисертацій з тестування у вільному доступі від редакторів qahelp.net

Fri, 15 Apr 2016 03:26:46 +0300

12 червня 2015 року на сайті qahelp.net було зроблено запис “200 дисертацій з тестування у вільному доступі”, повний перелік яких публікую нижче. Сторінку було додано в закладки та на якийсь час забуто. Роблячи ревізію по закладках виявив, що сайт, на жаль, недоступний став (якщо хтось знає – підкажіть, чому?). Але завдяки веб-архіву вдалося відновити вміст – чим і поділяюся, щоб кожному бажаючому не довелося повторно проходити “квест”.

Примітка: деякі посилання ведуть на 404 або “cannot find document in database”.

200 дисертацій із тестування

Технологічний інститут Флориди (той самий, у якому працює Сем Канер) веде бібліографію дисертацій із тестування. Ми відібрали для вас ті, які мають електронну копію у вільному доступі. Читати не перечитати – просто скарб!

On the feasibility of using FSM approaches to test large web applications
Generation of tests from labeled event structures
An algebraic axiom environment for software testing (axenvironment)
Quality measurement and the utilisation of measurement results in a software development process
Test suite development using a structured framework
Formal models and analysis for software component interaction testing
Proposal for a software metrics-based critiquing system
A test planning system for functional validation of VHDL DSP models
A testing metric for designs modelled as hierarchical finite-state machines
Software comprehension: Theory and metrics
Software Design Based on Operational Modes
An infrastructure to support usability problem data analysis
A usability study of the Tksee software exploration tool
The variations in the use of I-CASE toolsets: a grounded theory approach
Mutation testing of hierarchical finite state machines in the Rational Rose Real Time toolset
Adaptive mode transition control architecture with an application to unmanned aerial vehicles
System-level fault diagnosis in the distributed PVM environment
Utilizing the notion of removable blocks to enhance program slicing algorithms
Safety verification conditions for software-intensive critical systems
Requirements engineering with use cases: A basis for software development
Using program slicing in software maintenance
Towards a regression test selection technique for message-based software integration
Efficient dynamic detection of input related software faults
Automatic testing of software with structurally complex inputs
Probabilistic Program Analysis for Software Component Reliability
The cat in the reaper: Usability testing of software instruction manuals
Reachability analysis and testing of asynchronous message-passing programs
Robustness testing of a distributed simulation backplane
Test driven development of embedded systems
Extending the constructive cost model through empirical defect modeling
A unique examination of the buffer overflow condition
The effectiveness of category-partition testing of object-oriented software
Conflict identification and resolution for software attribute requirements
Detection of faulty components in object-oriented systems using design metrics and a machine learning algorithm
A comprehensive framework for testing graphical user interfaces
Slicing-based coupling measurements
Process enhancement and database support for vehicle operational readiness reporting
Documentation and validation of the requirements specifications. An XML approach
Automatic generation of software test cases from formal specifications
A knowledge-based tool for regression testing
A software test plan generation approach for pedagogical purposes
An investigation into the determinants of software product development time
High-yield (fault-directed) approach to test suite evaluation
Generating test templates via automated theorem proving
High level test generation using software testing metrics
Inference in nonhomogeneous Poisson process models, with applications to software reliability
Introducing «FireWorks»: A tool for regression testing within the Smalltalk environment
On proportional sampling strategies in software testing
Knowledge-Based Program Understanding and Testing Assistant (KBPUTA)
Input validation testing: A system-level, early lifecycle technique
OCL exception handling
Implementation of the digital communication system in the F/A-18 aircraft
Test methodology for SRAM based FPGAs
Traceability in object-oriented quality engineering: A basis for regression analysis of object-oriented software
A Software Testing and Reliability Early Warning (STREW) metric suite
Safe software components
A measure for module cohesion
The Validation by Measurement Theory of Proposed Object-Oriented Software Metrics
Compiling with proofs
Testing instances of design patterns
Program reliability estimation tool
Software system defect content prediction from development process and product characteristics
Metamodeling: Rapid design and evolution of domain-specific modeling environments
Cause-effect validation of requirements for distributed systems
Specification mutation for test generation and analysis
Using Discrete-Event Simulation to Address the Probe Effect in Software Testing of Real-Time Distributed Systems
Enhancing software reliability with speculative threads
QUIM map: A repository for usability/quality in use measurement
Domain testing: Divide and conquer
Expert systems and test-plan generation
Development of decision support system for reliability
Achieving usability via design architecture and patterns: The things we implement that affect usability
Performance assertion checking
Predicting open-source software quality using statistical and machine learning techniques
Requirements-based design evaluation methodology
The use of data flow information for the selection and evaluation of software test data
Type qualifiers: Lightweight specifications to improve software quality
Analysis and quantification of test driven development approach
Issues in automation of checkpoint encoding for anti-random testing
Towards plug-and-play services: Design and validation using roles
An analysis of the difference in software project management practices between organizations registered to ISO 9001 and non-registered organizations
Coverage-directed validation of hardware models
Measuring inheritance coupling in object-oriented systems
A formal method for modeling and analysis of requirements for software
Automated construction of software behavior models
Safety-critical software testing in airborne systems: The modified condition/decision coverage criterion
A demand-driven approach for efficient interprocedural data flow analysis
Towards an integrated model for specifying and measuring quality in use
Reusable strategies for testing safety-critical systems
On the complete testing of simple safety-related software
Strategies for testing Web applications from the client side
Constructing black-box test suites for systems specified in Larch/C++
Testing multimedia software using Hybrid Control Flowgraph-Petri Net approach
A virtual RSNS direction finding antenna system
Key Success Factors for Keyword Driven Testing — LogiGear
Test automation snake oil
Helping everyday users find anomalies in data feeds
An implementation of the Schick-Wolverton and the Jelinski-Moranda software reliability models
A discipline of specification-based test derivation
Constraint-based feature validation
Analyzing infinite-state programs with abstract interpretation
Profile analysis techniques for observation-based software testing
An integrated testing and fault localization methodology for spreadsheet languages
A methodology and software environment for testing process model’s sequential predictions with protocols
Things that find bugs in the night
Managing software requirements: Organizational and political challenges
Integration of the Navy Tactical Environmental Database Service with the Joint Effects Model
Automating test generation for discrete event oriented real-time embedded systems
Efficient, effective regression testing using safe test selection techniques
Transformational approach to software reliability assessment
Dataflow analysis of software fragments
Stimulus response requirements specification notation: an empirically evaluated requirements specification notation.
Automatic generation of test cases and anticipated test outcome based on a tabular design specification
On mutation and data flow
Using Simulation to Empirically Investigate Test Coverage Criteria Based on Statecharts
An Architecture-Based Software Reliability Model
Constructing Bayesian-network Models of Software Testing and Maintenance Uncertainties
Automated Regression Testing using DBT and Sleuth
Automatic Test Generation using Checkpoint Encoding and Antirandom Testing
Pythia: A regression test selection tool based on textual differencing
Using a Neural Network in the Software Testing Process
Testability in hardware/software codesign systems
Software testing and reliability growth models
Effectiveness testing of embedded user support for US army installation-level software
Factors influencing a personal software process
Reliability quantification of nuclear safety-related software
Testability-directed specification of communications software
Towards a proportional sampling strategy according to path complexity a simulation study
A study on test cases generation for object-oriented programs based on UML state diagram
Program-based, structural testing of shared memory parallel programs
Software test generation based on flow models
A formal specification-based approach to object-oriented software testing at the class level
An empirical study of the branch coverage of different fault classes
A generic timing test framework for multimedia software testing
Quality assurance of Web applications: A survey
Integration of model checking into software development processes
Operational profile specification, test case generation, and reliability estimation for modules
Software component interaction testing: Coverage measurement and generation of configurations
Formal metrics for quantitative assessment of the quality of expert systems
COM-tester [microform] : a script testing tool for MS COM
Specification-based regression testing measurement with risk analysis
Empirical studies of the effects of incorporating fault exposure potential estimates into a test data adequacy criterion
Test data generation for relational database applications
Enhancing traditional behavioral testing through program slicing
Extending white box testing to database applications
The impact of team software organizations on software quality and productivity
Role of Larch/C++ specifications in black-box testing of object-oriented software
A trace-driven simulator for palm OS devices
A study on reproducible testing for distributed multithreaded Java programs
Structured testing: Analysis and extensions
Pattern-based design and validation of communication protocols
A quantitative approach for analyzing the impact of tools on software productivity
Distributed sensor network software development testing through simulation
SafeJava: A unified type system for safe programming
Validating complex agent behavior
A use case driven validation framework and case study
Foundations for the run-time analysis of software systems
A Taxonomy of E-Commerce Risks and Failures
Culture and international usability testing the effects of culture in interviews
Tools to support a formal verification method for systems with concurrency and nondeterminism
Leveraging test measurements into proposing additional domain tests
Feature engineering of software systems
An open-source, extensible spacecraft simulation and modeling environment framework
A view-based system for eliciting software process models
The complex quality world: Developing quality management systems for software companies
Verification and validation in software product line engineering
Scenario-driven requirements engineering: Method and tool
An Automated Oracle for Verifying GUI Objects
Automated test system for ADSL equipment
Group branch coverage testing of multi-version software
Object-oriented program testing using formal requirements specification
QUIM editor: A tool for quality in use measurement
ADaPT: Adaptive development and prototyping technique
Applying formal methods to software testing
The effects of roles and personality characteristics on software development team effectiveness
Enhancing visibility of annotations of software artifacts
Advanced software engineering models for quality improvement
Managing multiple interdependencies in large scale software development projects
A load-dependency model for software reliability
Context-driven testing of object-oriented systems
Implementation of a three-group classification model using case-based reasoning
Early component-based reliability assessment using UML based software models
Assessing software metrics
Identifying the mechanisms driving code inspection costs and benefits
A distributed approach to passively gathering end-to-end network performance measurements
Generation of grey box use cases for personal communication systems using simple design machines
Web-CAT a Web-based center for automated testing
Detecting errors in software using a parameter checker: an analysis
Comparative study of synchronous remote and traditional in-lab usability evaluation methods
Axiomatic verification to enhance software reliability
Improved techniques for software testing based on Markov chain usage models
Automatic detection of software failures with hierarchical supervisors
Metrics-guided models and methods for cost and quality management of component-based software
Metria-Guided Quality Management for Component-Based Software Systems
Relational specification as a testing oracle
Automatic continuous testing to speed software development
The specification-based validation of Reliable Multicast Protocol: Problem report
A hierarchical approach to the formal verification of embedded systems using MDGs
Usability analysis of the channel application programming interface
A run-time environment for concurrent Ada software test analysis

Чому важко бути QA? (частина 2)

Thu, 14 Apr 2016 10:37:25 +0300

Чим більше можливостей, тим важче вибрати. Вадим Мозговий

[![Складно бути QA тому, що багато шляхів розвитку]Придивіться до шляху: в одній широкій дорозі сходяться багато стежок

Доброго часу доби. Минулого разу в замітці торкнувся теми, чому важко бути QA і в списку проблем дійшов до пункту “неочевидність розвитку”, про який хотілося б детальніше поговорити сьогодні.

Сам я потрапив у тестування з університетського курсу прикладної фізики за порадою мого близького друга, який уже тоді був успішним програмістом. Його думка тоді була “Піди, навчися пару місяців програмувати”. Минуло 8 років. Програмувати вчитися можна все життя. А ось професію свою я покидати поки не збираюся:)

Але є дві небезпечні крайнощі, які зустрічаєш через деякий час після початку:

Все здається зрозумілим, людина потрапляє в зону комфорту – і залишається “на все життя” “клікером”: кави, новини, подивитися котиків, переглянути зафіксовані баги, подивитися робочу пошту та нові хотівки замовника, пообідати – а там і додому пора, розслабитися компанії улюблених серіалів.
Все здається зрозумілим і хочеться бігти далі: вирости в QA ліда, тимліда, директора, автоматизатора, свій бізнес і політ фантазії.

QA на роздоріжжі

Проблема в тому, що QA – це набагато комплексніша, ніж здається на перший погляд. Тест-кейси вигадувати – потрібно як розуміння продукту, і певний, хоча б інтуїтивний, математичний апарат. Потрібна певна дисципліна підтримки документації в актуальному стані. Для того, щоб розуміти, яка документація ефективна і потрібна, а яка буде тільки дарма витраченим часом. Розуміння “тайм-менеджменту”, “ризик-менеджменту”. Розуміння того, як працює “залізо”, на якому крутиться продукт, що створюється, як працює операційна система. Тому, залишаючись “в своїй професії” для того, щоб робити свої завдання ефективно, QA поступово освоює наступні:

Програмування; причому, далеко не завжди однією мовою
Програмування лише на рівні ОС: bash, powershell; потрібно як для автоматизації завдань наступного пункту, так і для нетривіального тестування безпеки
Базові знання в DevOps: щоб не чекати поки до тебе дійде сис.адмін , щоб підправити налаштування тестового оточення або просто розгорнути пару додаткових віртуалок
Проектний менеджмент
Бізнес-аналіз
Залежно від продукту – може бути додатковий розвиток у “не-айтішній” галузі економіки, медицини, фінансів, продажів
Дизайн і прикордонні області: як для тестування юзабіліті так і для того, щоб робити няшні скріншоти в джиру.
SEO, SMM та інші мережеві та маркетингові технології – для розуміння, які елементи потрібні будуть бізнесу
Психологія, уміння вирішувати конфлікти, вести переговори, мотивувати
І ще 100 500 пунктів, з якими ви зустрічаєтеся так чи інакше

Що ж робити?

Найважливіше і найскладніше – вибрати собі мету. Або цілі. Перестати обманювати себе і – що найголовніше – не давати тобі заснути у “зоні комфорту”. Світ IT розвивається дуже швидко 24 години на добу: якщо це не зробили ми зараз, то ввечері, вночі чи вранці це зроблять замість нас в Америці, Китаї чи Індії (як би не любили у нас жартувати з приводу коду “індусів” – на десять) тисяч пару геніїв можна зустріти, які обіймуть керівні посади в Google, Microsoft та інших гігантах). Вибрати та розвивати себе у певній сфері тестування: досі професіоналів у тестуванні безпеки, продуктивності не так багато. А з розвитком операційних систем і збільшенням BigData продуктів потреби в них тільки зростатимуть.

Це складно, але важливо. Challenge, який потрібно пройти. І навіть залишаючись “просто тестувальником” – потрібно відточувати мистецтво тест-дизайну (бо вчорашні тест-кейси можуть стати завтра неактуальними).

Так що, як би не говорилося в “рекламі” різноманітних курсів, що за пару місяців з домогосподарки можна стати супер-оплачуваним QA – це не так легко. Це найскладніший шлях розвитку QA. Більше того, написане вище – це більше розвиток QA як “технічного фахівця”, а саме про QA – наступного разу.

Навчання тестувальників. Презентація компанії Mail.ru

Wed, 24 Dec 2014 17:37:05 +0200

Знайшов і захотілося поділитися: сподобалися поради з презентації про навчання тестувальників від компанії Mail.ru. Презентація була показана під час конференції SQA Days 16

https://www.slideshare.net/slideshow/embed_code/key/6Anp22qe0pjAv6 Обучение тестировщиков. Практический опыт и советы

Обучение тестировщиков. Практический опыт и советы from SQALab

Математика для тестувальників

Fri, 28 Nov 2014 00:48:09 +0200

Відео однієї з доповідей SQADAYS#13

Повторення, як кажуть, мати вчення. А такі речі варто повторювати.

Спочатку була стратегія…

Mon, 24 Nov 2014 01:17:19 +0200

Що спільне між тестувальником і… припустімо, Наполеоном? Наполеон хотів підкорити світ, досягнувши абсолютної влади. Тестувальник теж хоче “підкорити” продукт, досягнувши абсолютної якості. Як полководцю Наполеону, так і тестувальнику необхідно “чуття” у своїй роботі: мають бути розвинені тактика та стратегія. Тактика допомагає керувати часом прямо зараз, виконуючи поставлені (або більше) на день завдання. Стратегія – бачення майбутнього – допомагає вибудувати процес тестування від початку до успішної здачі та супроводу.

Стратегія – це загальний опис методів та підходів, які будуть використані у тестуванні та є вступною частиною та основою для тест-плану. Як назвали стратегію тестування в одній розумній статті, це огляд з висоти десяти тисяч футів. Власне далі буде про стратегію.

Стратегії тестування

![Стратегії тестування](https://i0.wp.com/cs621629.vk.me/v621629859/7f8/CalKiyBYTio.jpg?resize=800%2C600)Стратегії тестування

Якби була успішна стратегія щодо завоювання світу – вже він був би підкорений. З тестуванням простіше та складніше одночасно: успішних стратегій, які дозволяють випускати no-bugs релізи – безліч. І часто вони залежать від команди, проекту, замовника, цілей, наявних коштів тощо. І все-таки можна виділити кілька основних.

Орієнтоване на ризики. Тестування, в якому управління, вибір, пріоритети, використання підходів, завдань та ресурсів підбирається на підставі конкретних ризиків, називається орієнтованим на ризики.
Орієнтоване на моделі тестування використовує так звані формальні моделі (не ментальні) для управління активностями, такими як управління, дизайн, реалізація, виконання та звіти про тестування.
Стратегії, основу яких лежить процес, природно переважно поділяються на “традиційні” і “ітераційні” (гнучкі).
3.1. Agile стратегія: методи розробки ПЗ, в яких методи розробки та реалізації виконуються змішаними спільними командами, що самоорганізуються. Проте, у разі тестування ведеться практично всією командою весь цикл виробництва.
3.2. “Традиційний процес”, в якому стадії слідують одна за одною через пропозицію, ініціацію, аналіз вимог, дизайн, реалізацію, тестування, вихід у продакшн та підтримку. У традиційних процесах тестування проводиться окремо взятою групою вже ближче до кінця процесу після проведення всіх інтеграційних маніпуляцій.
Тестування, засноване на досвіді: тестування, в якому знання, навички, набутий досвід закладаються при плануванні, дизайні, реалізації та отриманні звітів про тестування. Багато тестувальників закладають різні аспекти такого підходу до тестування, хоча й буває, що хтось може використовувати їх “надзвичайно широко”. Концепції тестування, заснованого на досвіді, включають такі елементи як передбачання помилок, дослідне і ad hoc тестування.
Тестування перевірки вимог: такий підхід до стратегії тестування, у якому вимоги та інші артефакти ПЗ використовуються для перевірки відповідності коду вимогам та артефактам. Основним завданням є показати, що всі вимоги дотримані та показати відповідність стандартам та регулюючим специфікаціям. Перевіряючі тести закріплюються у письмовій документованій (“скриптованій”) формі тестових процедур та звітів.
Стратегія на підставі атак: тестувальники намагаються знайти помилки, ґрунтуючись на патернах, які повинні б “зламати” програмне забезпечення (застосовуючи атаки). Така стратегія є гібридом тестування, заснованого на досвіді та тестування, заснованого на ризиках. По суті, це є “максимально практичним” тестуванням.
Математично обґрунтована стратегія: у цьому випадку тести плануються, проектуються, реалізуються та аналізуються на підставі математичних концепцій та технік. Ці тести включають статистику, проектування експериментів, методику формальних доказів, комбінаторику, методики випадкових чисел, математичний аналіз (теорії про класи еквівалентності і граничні числа).
Валідація користувачами: дана стратегія містить мету показати те, що розробка створила той самий продукт, який відповідає бажанням користувачів та замовників. Продукт перевіряється на підставі “оперативних концепцій”, вимог, дизайну, моделей, реалізацій, оскільки будь-який із цих елементів може містити помилки. Оцінка якості відповідності може бути в такому разі складною і досить суб’єктивною (“добре-погано вийшло”, “подобається-не подобається”), тому багато таких стратегій намагаються уникати.

Насправді рідко бувають “чисті” стратегії. Зазвичай, залежно від контексту, стратегії поєднуються для отримання максимального ефекту та відповідності очікуванням власника бізнесу. Але в будь-якому випадку, добре продумана стратегія є ключовим пунктом для отримання якісного продукту і набагато важливіше мати чітку стратегію і слідувати їй до того, як буде складено основний детальний план і піде “занурення в глибокий тест-дизайн”. Важливо вміти складати та застосовувати різні стратегії. Тоді продукт, над яким працюєте, досягне того, чого не зміг досягти Наполеон.

Джерело

А ще можу порекомендувати наступне відео 🙂

“Testing” what is it? (by Michael Bolton)

Wed, 29 Oct 2014 15:24:24 +0200

Testing can means different

Testing is — among other things — reviewing the product and ideas and descriptions of it, looking for significant and relevant inconsistencies.
Testing is — among other things — experimenting with the product to find out how it may be having problems—which is not “breaking the product”.
Testing is — among other things — something that informs quality assurance, but is not in and of itself quality assurance.
Testing is — among other things — helping our clients to make empirically informed decisions about the product, project, or business.
Testing is — among other things — a process by which we systematically examine any aspect of the product with the goal of preventing surprises.
Testing is — among other things — a process of interacting with the product and its systems in many ways that challenge unwarranted optimism.
Testing is — among other things — observing and evaluating the product, to see where all those defect prevention ideas might have failed.
Testing is — among other things — a special part of the development process focused on discovering what could go badly (or what is going badly).
Testing is — among other things — exploring, discovering, investigating, learning, and reporting about the product to reveal new information.
Testing is — among other things — gathering information about the product, its users, and conditions of its use, to help defend value.
Testing is — among other things — raising questions to help teams to develop products that more quickly and easily reveal their own problems.
Testing is — among other things — helping programmers and the team to learn about unanticipated aspects of the product we’re developing.
Testing is — among other things — helping our clients to understand the product they’ve got so they can decide if it’s the product they want.
Testing is — among other things — using both tools and direct interaction with the product to question and evaluate its behaviours and states.
Testing is — among other things — exploring products deeply, imaginatively, and suspiciously, to help find problems that threaten the value.
Testing is — among other things — performing actual and thought experiments on products and ideas to identify problems and risks.
Testing is — among other things — thinking critically and skeptically about products and ideas around them, with the goal of not being fooled.
Testing is — among other things — evaluating a product by learning about it through exploration, experimentation, observation and inference.

Author

Michael Bolton (http://www.developsense.com/)

Білль о Правах Тестувальника

Thu, 18 Sep 2014 10:15:16 +0300

Білль о Правах Тестувальника. Автор Том Гілб (Gilb 2003)

Тестувальники мають право відбирати вхідні дані для процесу тестування та відкидати працю низької якості.
Тестувальники мають право на несуперечливі та чіткі вимоги.
Тестувальники мають право тестувати якомога раніше з розвитком системи.
Тестувальники мають право включати свої тестові сценарії до інших технічних специфікацій.
Тестувальники мають право бути стороною, яка встановлює рівень якості, відповідно до якої вони тестуватимуть.
Тестувальники мають право на відповідні ресурси для професійного виконання своєї роботи.
Тестувальники мають право на рівномірне навантаження, а також на власне життя.
Тестувальники мають право вказувати на ризиковані наслідки використання продуктів, які їм не дозволили протестувати належним чином.
Тестувальники мають право на розгляд будь-яких специфікацій, які можуть торкнутися їхньої роботи.
Тестувальники мають право зосереджуватися на тестуванні продуктів та встановленні їх якості та надсилати погану роботу назад.

Посилання на джерело

Чи складно навчитися тестуванню?

Wed, 30 Oct 2013 13:49:46 +0200

Вчора в книзі Testing ASP.NET Web Applications “потрапила” на очі одна коротка, але водночас містка фраза. “Testing is easy; good testing is hard” (“Тестування є простим; добре тестування є важким” – переклад особистий)
Власне – це все.

За бажання придбати книгу Testing ASP.NET Web Applications можна тут

Тестування ASP.NET веб-додатків

Завдання для тестувальника початківця

Thu, 29 Aug 2013 09:42:31 +0300

Доволі часто в мене запитують “Як навчитись тестуванню?” Звичайно, є курси та їх цінність ніхто не збирається скасовувати! Але деякі люди просто не мають того “стартового капіталу”, з яким йти на курси, але є час і бажання себе спробувати до першої співбесіди.

Напевно, багатьом потрапляла до рук програма ListBoxer (потрапила вона і мені як тестове-вступне завдання на першому місці роботи). Але попросила мене якось “поділитися знаннями” одна добра знайома, у якої “під рукою” не було на той момент жодного апарату, куди можна було б встановити ListBoxer. Ось і з’явилася ідея накрапати простеньке (і водночас творче:)) завдання пошуку явних помилок і тренування написання тестових сценаріїв. А потім цим завданням поділився далі. І далі. І далі… 🙂
То чому б її не викласти тут? 🙂 Zadachka

А хто має бажання погратись із ListBoxer – посилання в студії ListBoxerFull
та невеликий бонус dumb (файли ListBoxer та Dumb взяті з http://iqa.com.ua/)