Теория: Способы смещения тестирования влево

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

Что такое смещение влево

Смещение влево — это техника, при которой мы смещаем тестирование влево по жизненному циклу продукта, то есть привносим его на этапы разработки требований, проектирования продукта, дизайна, разработки и написания кода.

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

Представим, что команда допустила ошибку на стадии разработки технических требований. Никто ее не заметил, поэтому дальше прошли этапы дизайна и разработка. И уже в самом конце тестировщик находит ошибку.

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

Наглядно эта проблема видна на диаграмме:

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

Рассмотрим конкретные техники, которые помогают смещать тестирование влево.

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

Три амиго. Во время этой практики команда обсуждает требования к продукту с трех сторон:

• Тестировщик задает множество вопросов и продумывает будущие проверки
• Разработчик начинает продумывать, как ему реализовать требования к продукту
• Продакт-оунер понимает, какой результат компания получит и в какие сроки

Написание тест-кейсов по документации. В этом случае тестировщики изучают документацию и по ней пишут тест-кейсы. Ориентируясь на них, разработчики проверяют результат своей работы на соответствие требованиям. При этом необязательно писать кейсы для всех требований. Достаточно предоставить корнер-кейсы — то есть тесты на исключительные случаи, которые разработчикам неочевидны.