(из Цикла Историй Тестировщика testerstories.com/2018/11/dont-define-testing-around-bug-finding/#more-3598)
Всем привет. Как вы уже могли заметить, интенсивность запуска курсов в OTUS увеличивается с каждым месяцем, и в марте их особенно много. Сегодняшний материал мы хотим приурочить к запуску курса «Автоматизация веб-тестирования», который стартует уже в середине марта. Приятного прочтения.
Я до сих пор вижу много тестировщиков, которые говорят о количестве найденных багов и уязвимостей, как о мере успеха проведения тестирования. Недавно я увидел другую точку зрения, которая гласила, что суть на самом деле в качестве ошибок, но далеко не в их количестве. Однако и с этой мерой также стоит быть аккуратным. Сейчас мы об этом и поговорим.
Основная идея заключается в том, что способ тестирования определяется типом тех ошибок, которые вам нужно найти.
Я уже говорил о некоторых аспектах сегодняшней темы ранее в беседе о баг-хантинге. Не хочется повторяться, поэтому постараюсь быть кратким. Я оформлю свои мысли тезисно и применительно к команде, в которой я работаю.
То, что важно для меня в тестировании – это влияние на пользователей таким образом, чтобы они принимали правильные решения быстрее. Для этого необходимо использовать жесткий цикл обратной связи, чтобы сократить период между тем, как разработчики совершают ошибку и в последствие исправляют ее. Эти ошибки – это области, где различные качества – поведение, производительность, безопасность, удобство использования и т.д. – либо отсутствуют, либо ухудшились.
Это определенно не измеряется количеством найденных ошибок, однако природа ошибки играет определенную роль. Моя задача – найти ошибки, которые больше всего угрожают целостности и качеству разработки. Это, вероятно, можно отнести к «качеству» ошибок, то есть эти ошибки тем более важны, чем более угрожают целостности.
Ключом к эффективному исправлению ошибок, по моему мнению, является нахождение этих ошибок как можно быстрее, в идеале сразу же, как только они появились. Хотя с моей точки зрения, даже «качество ошибки» — это далеко не высшая мера.
Мы придаем такое большое значение качеству ошибки, однако неужели их количество вообще характеристика незначительная?
По факту, количество ошибок имеет значение, если вы очень сильно зациклены на уменьшении количества времени на их поиски. Скажем, в системе есть 10 критических багов. И я действительно быстро нашел два из них, и это действительно круто! Две критических ошибки были найдены до момента представления продукта. Но я не нашел другие перед развертыванием. Это значит, что 8 критических ошибок остались ненайденными. В этом случае, количество ошибок – это ключевая мера, даже если мы этого на тот момент не понимали.
Важно мыслить немного в другом ключе. Количество ошибок или их качество – это не так важно, как механизмы, по которым они случаются и, соответственно, механизмы их поиска. Есть много существующих вариантов:
- Механизмы, которые хороши в нахождении багов, но которые работают слишком долго;
- Механизмы, которые плохо находят баги, но очень быстро работают;
- Механизмы, которые «склонны» замечать баги определенного рода, но при этом в упор не видеть других;
- Механизмы, которые не пользуются большой популярностью у тестировщиков, но действительно работают и их не используют, потому что никто о них не знает в команде, именно поэтому то, что может быть найдено, остается ненайденным;
- Механизмы, которые могут работать хорошо и быстро, способные находить множество ошибок, но отклик от них получается настолько нечетким, что люди не могут принимать решения, основываясь на их выходных данных.
Сосредоточение на этих аспектах в мере не меньшей, чем на других известных, важно, поскольку помогает обойти некоторые традиционно-возникающие проблемы. Например, такие, когда ты прогнал уже сотню тестов, но не нашел ни одного бага. И это может быть и хорошо, но только в том случае, если ошибок действительно нет. Но если они все же есть, то это плохо, если применяющиеся способы тестирования не могут их выявить. Или же ситуация, когда я запускаю кучу тестов, нахожу незначительные ошибки, при этом пропуская более труднонаходимые.
Я и моя команда должны принимать определенные решения, основанные на проведенных тестах. Это значит, что мы должны верить тому, о чем говорят нам результаты проведенных тестов, соответственно, мы изначально должны доверять методам обнаружения, которые внедрили в эти тесты.
Некоторые методы обнаружения исходят из самих тестов, грубо говоря, из того, что они ищут и как они ищут. Другие методы обнаружения должны быть присущи самой среде и тестируемости (testability), которую мы определяем, чтобы определить, насколько вероятно и возможно ли в принципе, что тесты вызовут ошибку, если она существует.
В конце своих кратких размышлений, я хочу подвести к тому, что я не определяю успешность тестирования какими-либо определенными факторами. Но если вам все же хочется как-то определить это для себя, то стоит определять не по количеству найденных ошибок и уязвимостей и не по качеству этих ошибок, а по его конкретной способности механизмов тестирования обнаружить их.
Я обнаружил, что неопытные тестировщики, прочитав эту заметку, не увидят существенной разницы между идеей выделения возможностей (detecting abilities) и результатами, полученными после выделения этих возможностей. Что касается именно специалистов, то они должны крайне хорошо их дифференцировать.
Будучи в состоянии понять и сформулировать это различие, специалисты-тестировщики могут выйти за рамки бесполезного (только мнение автора) различия между “проверкой” и “тестированием” и вместо этого сформировать конструктивное понимание методов обнаружения, как человеческих, так и автоматизированных, которые позволяют проводит тестирование, чтобы помогать людям быстрее принимать лучшие решения.
Вот такой, казалось бы простой, но довольно полезный материал. По устоявшейся традиции ждем ваши комментарии и приглашаем на открытый вебинар, который уже 11 марта проведет Михаил Самойлов — ведущий автоматизатор в тестировании в Group-IB.
Автор: MaxRokatansky
