Когда прекратить тестирование

Мне очень интересно поговорить об этой теме с другими тестировщиками или людьми, у которых я беру интервью. Я получаю всевозможные ответы, такие как: «Я буду продолжать тестирование, пока не завершу критерии приемки», «Я буду продолжать, пока не найду все ошибки» и т. д. Мне нравится учиться у всех и видеть, какова их жесткая стоп-линия для тестирования функции/задачи или если тестирование никогда не прекращается. Мы много слышим о критериях входа и выхода, но достаточно ли этого?

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

Когда мы начинаем тестирование? 🏁

Я хотел бы начать с вопроса ко всем вам. Когда мы начинаем тестирование?

Как упоминалось в моих предыдущих блогах, начинать тестирование надо как можно скорее и не откладывать его на потом. Почему? Что ж, это сокращает затраты, время и усилия на доработку и повторное тестирование функций, что приводит к лучшему качеству продукта. Как объяснялось в моем предыдущем блоге о жизненном цикле разработки программного обеспечения, мы можем начать уже на стадии требований, понимая детали и то, что у нас уже готово для тестирования. Кроме того, обзор дизайна также очень важен и полезен. Это помогает тестировщикам понять требования с точки зрения дизайна и наоборот, и, как тестировщики, мы также можем дать рекомендации или даже похвалить работу дизайнера.

Когда мы прекращаем тестирование? ❌

Еще ни разу в своей карьере я не сталкивалась со «стоп-тестированием». Может ли часть тестирования вернуться, если в какой-либо части функции было обнаружено новое улучшение или ошибка? Мы не знаем, но всегда хорошо относиться к этому непредвзято 👐

Я считаю, что тестирование - это нескончаемый позитивный процесс. Я еще не слышала от кого-то, что программное обеспечение готово на 100% после тестирования. Если бы я это сделала, мне бы пришлось задаться вопросом, возможно ли это?

Следующие пункты могут быть рекомендациями, которые помогут вам прекратить задачи тестирования:

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

Как любопытный тестировщик, я всегда держу свои антенны в режиме тревоги. Важно обратить внимание на более мелкие детали и ошибки в продукте, чтобы выяснить, почему продукт не работает так, как задумано. Невозможно найти все ошибки, которые могут существовать, но руководство команды в любом случае примет решение о том, когда выпустить продукт. Релиз может сопровождаться с некоторыми нежелательными ошибками! Видите ли, мы еще не прекратили тестирование. Вопрос в том, сможем ли мы найти эти ошибки до релиза и какова их серьезность?

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

Чеклист 🔖

Вы можете использовать этот чеклист, чтобы определить, достаточно ли у вас уверенности для завершения тестирования:

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

Некоторые полезные показатели, которые вы также можете использовать 🟩:

• Дашборд с отображением процента пройденных тест-кейсов.
• Процент завершения, основанный на количестве выполненных тест-кейсов.
• Процент неудачных тестов.

Заключение

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

Если вы можете выбрать большинство пунктов из чеклиста и отметить их «Да», тогда вы знаете, что потенциально можете прекратить тестирование. С другой стороны, если вы видите больше «Нет», чем «Да», вы знаете, что чего-то не хватает, и вы можете поработать над этим, чтобы избежать появления ошибок в продакшене!

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.