Автор: Грегори Пачига (Gregory Paciga) Оригинал статьи Перевод: Ольга Алифанова
Сегодня я поучаствовал в онлайн-дискуссии о тестировании, где спросили что-то вроде "А каково соотношение автоматизированного и исследовательского тестирования в вашей компании?"
Я, конечно, понимаю суть вопроса, и не буду вдаваться в педантизм, отвечая на него – но это мой блог, хочу быть педантом – значит, буду. В вопросе для меня интересно то, что даже если ограничиться одной компанией, одной командой или одним продуктом, можно ответить на него очень по-разному. Критически важно тут то, что для измерения соотношения нужно измерять обе сущности в одинаковых единицах.
QA инженер имеет внушительный арсенал техник тест-дизайна: классы эквивалентности, граничные значения, попарное тестирование, диаграммы состояний и переходов, таблицы принятия решений, сценарии использования и альтернативные сценарии, перебор комбинаций, деревья решений ...эмм, это все что я помню, если что-то забыл, поправьте.
Так вот, сценарии использования и альтернативные сценарии, мы обычно получаем от аналитиков из спецификации.. таблицы, деревья и диаграммы мало кто чертит, так как это занимает много времени (при дефиците ресурсов). Как правило, в ходу две популярные техники: классы эквивалентности и граничные значения, и только отдельные умнички используют pairwise ( попарное тестирование ).
Скажу честно, принять эту технику я смог далеко не сразу. Я тогда еще не до конца преисполнился познанием и из-за непонимания было недоверие к, сгенерированным инструментом, кейсам.
Конечно, на собесах, у всех от зубов отскакивает: "создаются все возможные отдельные комбинации каждой пары входных параметров" или "в 97 процентах случаев, баги находятся на комбинации двух параметров", но давайте разберемся, почему pairwise сложно применить ручками и поймем как забить на это и успешно применять его в своей работе.
