Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

Полный перевод книги Рикарда в PDF

Вышеописанные фазы тест-дизайна в реальности не происходят линейно. Они могут идти во всех направлениях, растягиваться на несколько релизов, и в них будет множество изменений и новых идей по мере интерпретации результатов тестирования.

Процесс скорее выглядит так:

Тестирование добавляет качество к информации о продукте

Самый неформальный тест-дизайн может неимоверно быстро происходить в голове опытного тестировщика, думающего о полностью новой идее в ходе исследовательского тестирования, или же тест-дизайн может быть основной для скриптов, кейсов и сценариев, которые тщательно исследованы и спроектированы заранее. Хорошее тестирование использует множество различных методов.

Идите по следу, ищите во многих местах, с разными перспективами; варьируйте многое или малое, прислушивайтесь к своим ощущениям, используйте известные вам данные, не перезагружайте систему, сделайте ее простой, сложной, импровизируйте!

Покрытие

Странно писать о тест-дизайне, не сказав ни слова о покрытии, однако репрезентативная модель покрытия как минимум крайне сложна, и ее невозможно получить в количественном формате, не удалив информацию о том, что важно (а именно такого покрытия нужно добиваться). Возьмем, к примеру, покрытие кода – можно спросить, что важнее – тестировать код или полезность продукта.

Предложенный в книге тест-дизайн генерирует скорее качественную информацию, а она субъективна и чувствительна к тому, что важно, так же, как и пользовательские отношения с продуктом. Вы можете отчитаться о том, что протестировано, а что нет, и что важного вы нашли, не упоминая проценты покрытия.

С точки зрения тестирования у моделей покрытия две цели:

1. Идентификация того, что тестировать.
2. Принятие решения о завершении тестирования.

Как можно видеть из предыдущих глав, моделей и подходов для определения, что тестировать, великое множество. Сомнительно, что слияние всех этих и других моделей в многомерные модели покрытия или модель моделей принесет пользу. Что касается вопроса, когда остановиться – мы можем посмотреть на него с другой стороны:

Выполнение тестов может продолжаться до тех пор, пока не перестанет приносить новую, релевантную информацию. Измените стратегию или остановитесь: тестирование насыщено.

Если бы мне пришлось выбирать модель тестового покрытия, я бы стремился покрыть все, кажущееся важным.

Изъяны

Мне кажется, что в этой маленькой книжке много полезной информации, однако она далека от совершенства. Вот наиболее важные известные мне проблемы:

1. Первая претенциозная коллекция эвристик тест-дизайна, которую точно можно улучшить.
2. Не для всех – слишком много теории, высокая плотность, для многих нерелевантна.
3. Стиль тестирования "пройдено/упало" ожидается/требуется во множестве контекстов, где не будут работать альтернативные подходы.
4. Много двойной работы, особенно при фрагментированных зонах ответственности.
5. Полноценный живой пример обогатил бы голые идеи.

Although I believe this little book has a lot of useful information, it is far from perfect. These are the most important problems I know of:

Завершение

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

Тесты не будут истинным отражением реальности, но, по моему мнению, у них неплохой шанс выявить реальные грядущие взаимоотношения между пользователем и ПО.

Прозрачность вашего тест-дизайна – основа отчетности.

Следует также стремиться к разнообразию задействованных людей. Это означает не только смешанную команду тестирования – это также значит, что другие роли должны различным образом участвовать в тестировании. Это нужно не потому, что они не доверяют тестировщикам, а потому, что все они стремятся создать отличный продукт, и одна голова хорошо, а две лучше. По той же причине вы можете подключаться на ранних стадиях проекта и помочь со сбором, анализом и пониманием требований.

Я думаю, что я раскрыл наиболее важные аспекты тест-дизайна, известные мне. Это неполная информация, и не вся она будет для вас релевантна. Я надеюсь, что все, кто дочитал до конца, почерпнули хотя бы несколько новых идей. Если это не так – надеюсь, вы напишете свою статью и пришлете ее мне.

Библиография

Большая часть контента основана на опыте. Частично я обсуждал это с коллегами и другими тестировщиками. Я старался расставлять ссылки на книги, статьи, курсы или блоги там, где это было применимо.

Книги

James Bach, Secrets of a Buccaneer-Scholar, Scribner, New York 2009

Edward deBono, Lateral Thinking - Creativity Step by Step, 1990 Perennial edition

Lee Copeland, A Practitioner’s Guide to Software Test Design, Artech House Publishers, Boston, 2003

Juliet Corbin and Anselm Strauss, Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory, Second Edition, SAGE Publications, Inc., Thousand Oaks 1998

Donald C. Gause/Gerald M. Weinberg, Exploring Requirements: Quality Before Design, Dorset House Publishing Co. 1989

Donald C. Gause/Gerald M. Weinberg, Are Your Lights On? How to Figure Out What the Problem REALLY Is, Dorset House Publishing Co. 1990

Gerd Gigerenzer, Adaptive Thinking: Rationality in the Real World, Oxford University Press, New York 2000

Gerd Gigerenzer, Gut Feelings: The Intelligence of the Unconscious, Penguin Group, New York 2007

Adam Goucher and Tim Riley, Beautiful Testing, O’Reilly Media Inc., Sebastopol 2010

Cem Kaner, Jack Falk, and Hung Q. Nguyen, Testing Computer Software, Second Edition, John Wiley & Sons, Inc., New York 1999

Cem Kaner, James Bach, Bret Pettichord, Lessons Learned in Software Testing, John Wiley & Sons, Inc., New York 2002

Michael Michalko, Thinkertoys: a handbook of creative-thinking techniques, Ten Speed Press, Berkeley 2006

Glenford Myers, The Art of Software Testing, Second Edition, John Wiley & Sons, Inc., Hoboken 2004 (originally published 1979)

Torbjörn Ryber, Essential Software Test Design, Fearless Consulting Kb, 2007

James Whittaker, How to break Software: A Practical Guide to Testing, Addison-Wesley, Boston 2002

Статьи

James Bach, Exploratory Testing Explained

James Bach, Heuristic Test Strategy Model

James Bach, Jon Bach, Michael Bolton, Exploratory Testing Dynamics

James Bach, Patrick J. Schroeder, Pairwise Testing: a Best Practice That Isn't

Jonathan Bach, Session-Based Test Management

Michael Bolton, Test Framing

Michael Bolton, Better Software columnsl

Fiona Charles, Modeling Scenarios using Data

Rikard Edgren, Henrik Emilsson and Martin Jansson, Software Quality Characteristics

Rikard Edgren, Addicted to Pass/Fail?

Rikard Edgren, More and Better Test Ideas

Rikard Edgren, Testing is an Island, A Software Testing Dystopia

Rikard Edgren, The Eye of a Skilled Software Tester

Rikard Edgren, Where Testing Creativity Grows

Elisabeth Hendrickson, Test Heuristics Cheat Sheet

Michael Hunter, You Are Not Done Yet

Cem Kaner, The Ongoing Revolution in Software Testing

Cem Kaner, What is a Good Test Case?

Cem Kaner, An Introduction to Scenario Testing

Joris Meerts, Functional Testing Heuristics - A Systems Perspective

Robert Sabourin, 10 Sources of Testing Ideas

Robert Sabourin, What Not to Test

Neil Thompson & Mike Smith, The Keystone to Support a Generic Test Process: Separating the “What” from the “How”

Курсы

James Bach, Michael Bolton, Rapid Software Testing

Michael Bolton, Lightning Talk on Emotions and Oraclesl

Michael Bolton, Confirmation Bias

Cem Kaner, Developing Skills as an Exploratory Tester

Cem Kaner & James Bach, Risk-Based Testing: Some Basic Concepts

Cem Kaner & James Bach, Black Box Software Testing, Exploratory Testing

Cem Kaner, Software Testing as a Social Science

Cem Kaner & James Bach, Black Box Software Testing, Specification-Based Testing

Cem Kaner & James Bach, Black Box Software Testing, Risk-Based Testing

Cem Kaner & Rebecca Fiedler, Black Box Software Testing, Test Design

Robert Sabourin, Just-in-time testing

Блоги

Blog portal

Michael Bolton

Context-Driven Testing

Rikard Edgren, Henrik Emilsson, Martin Jansson

Cem Kaner

Jonathan Kohl

Обсудить в форуме