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

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

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

Модель

Традиционное

Shift-Left

Этап подключения QA

В конце жизни задачи

При зарождении задачи

Затраты по времени

Много

Может занять как много, так и мало времени, в зависимости от разных факторов

Ожидаемое качество

Все работает прекрасно в 99.8% случаев

Все работает прекрасно в 99.9% случаев

Что такое вообще Shift-Left тестирование?

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

Наверное, многие 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 вынужден в каждом конкретном случае делать выбор, использовать тот или другой метод, а может, оба сразу, и сделать это он может лишь на основе своего опыта и профессионализма. И это самая главная сложность реального тестирования в проектах.

Аналогия: тестировщик и картограф

Решая простую задачу «добраться из пункта А в пункт Б по самому кратчайшему пути» вы, скорее всего, воспользуетесь картой. Но уверен, что немногие из вас задавались вопросом, чего стоило создание этой карты. Создатель карты досконально знает местность, которую картирует. Так и QA должен как можно лучше разбираться в продукте, иначе его работа может вызвать коллапс в работе других команд. Особенно это актуально при Shift-Left-тестировании. С другой стороны, сам этот метод способствует лучшему узнаванию продукта.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Комментарии (1)


  1. amarao
    02.03.2022 14:49

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

    Вот где-то тут надо закапывать. Потому что здоровая разработка (в отсутствие внешних паталогических причин выглядит так): exploratory programming, проверили, что идея работает, пошли писать. Написали boilerplate, CI, место для тестов (у благродных донов для этого cookiecutter или что-то подобное), поехали писать тесты с кодом под него.

    А "тестирование без автоматизации", это как программирование без клавиатуры. Можно, но... параолимпиада чистой воды.