Сочетание Shift-Left и «Традиционной» модели тестирования в будние дни QA
В этом материале будет кратко рассказано, почему 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, не можете верно принять решение, всегда делитесь этим со своей командой. Игра в команде — залог успеха, а получение экспертизы от своих коллег порой бесценно.
Не бойтесь высказывать свои гипотезы, предложения, призывать других членов команды или даже компанию для достижения не только отличного уровня качества продукта, но и для дальнейшей его эволюции.
