Home

Автор: Владислав Тарасенко

Оригинальная публикация

В этом материале будет кратко рассказано, почему Shift-Left – это не всегда хорошо и почему не стоит забывать о традиционной модели тестирования. Рассмотрим паттерны поведения QA при тестировании обычных задач и как постепенно стать продуктивным тестировщиком, не утопая в регрессах и бесконечных проверках одного и того же.

Я часто подхожу к тестированию как к игре в шахматы. Это делает процесс поиска проблем не монотонным, порой даже увлекательным и полезным. В научной и технической литературе у этого метода тестирования есть название: Shift-Left тестирование, но всегда ли нужен такой подход?

Напомню краткое отличие одной модели от другой:

Наверное, многие QA задаются вопросом, какая модель тестирования всё-таки более продуктивна: традиционная или Shift-Left. Статистика показывает, что по предоставляемому итоговому качеству особой разницы между традиционной моделью и моделью «Сдвиг влево» нет.

При этом есть ряд минусов, которые делают модель Shift-Left даже хуже в определенных случаях. В аналогичных статьях, скорее всего, вы найдете утверждение: «Shift-Left ускоряет разработку и процесс тестирования», но я практически нигде не видел рассказов о том, какой ценой это достигается.

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

Можно уже закрывать статью и говорить, что Shift-Left хуже традиционки? Нет.

Представим ситуацию: нужно покрасить кнопку на форме оплаты, просто изменить цвет с одного на другой. Как обычно действует QA? Сейчас и узнаем!

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

1. Режим традиционной модели: «Так, вот когда задача придёт, тогда и протестирую, проверив, что цвет поменялся, что на разных устройствах и экранах кнопка в рабочем состоянии и что после выкладки в продакшн, с ней всё хорошо, и она соответствует ожидаемым требованиям». 

Результат: потратил на тестирование час, получил перекрашенную кнопку.

2. Режим Shift-Left модели: «Так, надо сходить к дизайнеру, узнать, почему они вообще хотят перекрасить эту кнопку, возможно, нужно перекрасить не только эту кнопку, а еще и другую, которая вот тут рядом. Насколько актуальный макет, и есть ли он вообще у предстоящей задачи. Так, а ещё нужно проверить брендбук, если макета не окажется, можем ли мы такие цвета использовать (привлечь коллег из дизайн команды), проанализировать нужна ли вообще эта кнопка (обсудить с продакт-менеджером возможные последствия и «подводные» камни реализации на основании ваших гипотез), и какие с ней могут возникнуть проблемы в будущем, можем ли мы что-то сломать этим изменением».

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

В данном случае использовали мы режим традиционный или Shift-Left, результат работы тестирования был бы одинаков: кнопку перекрасили бы и про задачу успешно забыли. Разница лишь в потраченном времени, которое, возможно, можно было бы использовать более рационально.

Ну, теперь уже можно Shift-Left убрать в корзину? И снова мой ответ – Нет.

Часто слышу от знакомых, что работать в Shift-Left модели – значит отказаться от традиционной полностью. Мне кажется, это не совсем верное решение, особенно, когда такие QA даже не знают, что происходит с их фичами после того, как они вываливаются в продакшн.

Снова вернемся к сценарию с кнопкой. Какой вариант развития событий мог бы быть?

Рассмотрим ту же кнопку, но при использовании гибридного подхода (Shift-Left и традиционки).

Перед тем, как разработчик приступит к перекраске кнопки, QA может задать наводящие вопросы о том, как именно эта кнопка будет перекрашена, будут ли задеты какие-то смежные функции, связанные с цветовым отображением. Получив ответ, что всё будет сделано достаточно тривиально и сломаться там нечему, QA принимает решение оставить проект до этапа приемки.

Когда задача поступает в тестирование, QA может поинтересоваться, как прошел процесс перекраски у разработчика, и если всё прошло так, как и было задумано, – тестирует и успешно завершает данную историю.

Вы, возможно, спросите: зачем я описал этот сценарий, если он ничем не отличается от двух предыдущих? Обратите внимание на дополнительные действия QA в сценарии гибридного подхода. Вот что это могло бы предотвратить:

• На этапе обсуждения разработчик сказал, что цвет кнопки берётся откуда-то из глубин кода, и никто не знает, используется ли этот цвет где-то ещё. Решили проигнорировать? Поздравляю, возможно, у вас где-то в другом месте вместо красной кнопки вылезла зелёная и, возможно, вы нескоро это заметите, так как у вас таких кнопок может быть миллион. Но когда к вам придёт аналитик и спросит, как так вышло, что за месяц упали конверсионные действия по одному из ключевых сценариев, а оказалось, что вы перекрасили кнопку «Отмена» в зеленый, а ранее она была красной, то тут-то пазл и начнёт собираться у вас в голове.

• При приемке задачи вы просто взяли задачу в тестирование, не уточнив у разработчика деталей процесса, увидели, что кнопка перекрасилась и всё работает корректно. Решили не спрашивать, о том, а как это изменения повлияло на продукт, что было изменено кроме цвета кнопки, есть ли у разработчика мысли о том, что необходимо посмотреть кроме цвета кнопки. В итоге после релиза обнаружилось, что выбранная реализация влияет на цвета кнопок у другой команды.

Это только два примера технического коллапса из множества возможных, которых можно избежать, если QA будет соблюдать два простых правила:

• будет активным в начальной фазе, будет задавать наводящие вопросы, уточнять детали (вот вам Shift-Left);

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

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

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

Если вы не полностью знаете свой продукт, если все его секреты хранятся в головах ваших коллег и порой никто не понимает, как это вообще работает, то поздравляю, тестирование для вас становится еще сложнее, и использовать какое-нибудь одно – либо традиционное, либо Shift-Left – скорее всего, будет ошибкой. В таких случаях вы вынуждены идти именно по гибридному пути тестирования, чтобы начать накапливать в себе эти знания и повышать скорость, качество тестирования, именно такой путь приведёт вас к накоплению опыта о продукте и в дальнейшем начнет играть вам на руку.

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

«Нужно немного времени на тестирование и, возможно, регресс» превращается в «тестирование здесь будет не нужно». Великолепие Shift-Left тестирования в действии, но не забывайте, какой ценой вы дошли до этого момента. Это и есть карта, созданная вами.

Таким образом, мы подошли к ряду тезисов, которые я выработал за полтора года работы по данному подходу:

• В первую очередь нужны знания о вашем продукте, по которым можно выработать верную стратегию тестирования.

• Наибольшую выгоду от процесса получаешь при гибридном подходе – используя как традиционную модель, так и Shift-Left тестирование.

• Приходится выходить за рамки простого тестирования и углубляться в аналитические процессы.

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

• Нужно полное погружение в продукт, а не только в задачи своей команды.

• Скорость и качество тестирования растет постепенно.

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

Для меня «Сдвиг влево» означает не дословное перемещение QA с этапов завершения задачи на этапы зарождения, а лишь напоминание о том, что QA имеет полное право и возможности начать свою работу как в начале процесса жизни задачи, так и в конце, применяя свои навыки и знания для этого.

Напоследок хочется добавить от себя несколько простых советов, которые помогут вам начать жить по гибридной модели тестирования:

• Старайтесь общаться с разработчиками по предстоящей задаче, узнавайте про возможные трудности в реализации фичи с точки зрения воздействия на «внешнюю среду». Например, вы меняете API, узнайте у разработчика, какие смежные команды (либо модули вашего продукта) этим API тоже пользуются. Это даст вам понимание, насколько задача будет тяжела в реализации и как сильно она влияет на смежный функционал, а также упростит жизнь в планировании интеграционных тест-кейсов.

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

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

• Если что-то не получается: не удается протестировать, возникает «странная» ошибка и тому подобные кейсы, и вы, как QA, не можете верно принять решение, всегда делитесь этим со своей командой. Игра в команде — залог успеха, а получение экспертизы от своих коллег порой бесценно.

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