Привет, Хабр! Чтобы не вводить никого в заблуждение, кратко перескажу, о чём пойдёт речь. Если тема будет вам близка или вы сталкивались с подобным, буду рад узнать ваше мнение и послушать советы.
Краткий пересказ:
Как я/мы в компании создаём процесс тестирования практически с нуля. Какие шаги предпринимались и как вообще получается в современном мире существовать без тестирования.
Вводные данные
Я — QA, который работает в средней по размерам IT-фирме, которая, в свою очередь, является «дочкой» довольно крупной промышленной компании и обеспечивает поддержку и разработку внутренних систем. Когда я только пришёл, помимо меня был только один тестировщик на ~15 разработчиков. Ни о каком адекватном процессе тестирования речи и не шло.
Работа осуществляется в рамках спринтов по две недели. Задачи, выполненные разработчиками, проверяются во время ревью более крутыми разработчиками, затем мерджатся и раскатываются на тестовый стенд, где уже их проверяет аналитик на соответствие требованиям.
В целом, кажется, ничего плохого нет — две линии проверки. Вот только количество багов явно было больше запланированного, а это, в свою очередь, вызывает ночной кошмар любого менеджера: сдвиг сроков.
Было принято решение взять нескольких тестировщиков, да не просто каких-то, а с навыками автоматизации, чтоб оно всё там как-то само.
Так я, собственно, и попал в команду — молодой и неопытный. На самом деле, не настолько всё было плохо: разработчики работали по TDD, так что unit-тестов хватало, и пайплайны отрабатывали автоматически. Да, не было тестирования как процесса, но ведь давным-давно, в далёкой-далёкой галактике, именно так и начиналось программирование.
Итак, первые 2 недели для меня были адаптационными. Я писал с нуля код для Selenium-тестирования, знакомился с проектом и погружался в процессы. После наступило время начинать тестирование. Этот этап я сейчас назвал бы «Внешним тестированием».
У меня была система и контакты аналитика — на этом всё. Весь процесс тестирования напоминал метод чёрного ящика в тёмной комнате, проводимый слепым. Точно так же было и с автоматизацией: я писал автотесты, общался со вторым тестировщиком, когда возникали вопросы, но всё это было, на мой взгляд, не очень эффективно. Обнаруженные неточности и потенциальные баги я фиксировал, но по каждому нужно было писать с классическим вопросом, известным любому QA: «Это баг или фича?». Вы сами можете сделать вывод о пользе подобного тестирования.
Со временем, когда я закончил с основой под автотесты и немного разобрался в проекте, я понял, что нужно что-то менять. Именно об успешных шагах далее и пойдёт речь, неудачи пока оставим.
Шаг 1. Тест-план
Можно сразу вспомнить про тест-план и то, что там описывается большинство вопросов. Он как бы был — честно-честно. Вот только его составлял я, как прилежный ученик, это первое, чем я занялся. Если этот текст читает кто-то из Middle+, Senior QA, представьте, что вы попросили своего джуна написать тест-план и теперь строго его придерживаетесь... не смешно, да? Смотря на тот план сейчас, хочется себе провернуть голову на 180 градусов до характерного щелчка, но что было, то было. Так что если вы читаете эту статью с целью построить или улучшить свой процесс тестирования, проверьте наличие адекватного тест-плана.
Что сделал я, когда понял, что меня не устраивает то, что написано в нём? Начал читать теорию. Далее уже методом проб и ошибок, а так же на примерах из интернета, получилось несколько прикольных вариантов. Я старался описывать тестирование проекта без подробностей, так же рассчитывать время на разные этапы и определять приоритеты.
Например: у нас было много страниц справочников и страниц с данными о курсах валют. Корректность работы страниц для курсов очень, мега важна для системы, а вот справочники трогают не так часто. Будет логично сначала реализовать автотесты для функционала высшего приоритета, а справочники сделать когда-нибудь потом. Вот только оценка тестов для страниц-справочников составляла всего два дня. Они шаблонные и очень простые по функционалу, но их много. В то время как на курсы нужно было потратить пару недель, и это не считая другой функциональности высшего приоритета. Так как до релиза времени хватало, я поменял их местами и не прогадал. Представьте, что пользователь нажимает на заголовок колонки, желая отсортировать элементы, а вся система зависает и падает у всех. За последующие 2 месяца тесты справочников отловили с десяток подобных ошибок и ещё всякую мелочь.
Естественно, всё не получается с первого раза. Была и бесполезная работа, и бесполезные пункты в плане, на которые уходили дни, но результат постепенно проявляется.
Банальный совет: Сначала выпишите главные для вас критерии планирования и вопросы, даже неформальные. Например: зачем вам тест-план, какие у вас навыки, что вы от него хотите, кто его будет читать, сколько времени у вас. И во время написания иногда перечитывайте. Вдруг вы повернули не туда.
Шаг 2. Общение и вовлечение
Если кратко, я заметил, что далеко не всегда мне понятно назначение существующих элементов системы, а баги постепенно мимикрируют под фичи и наоборот. Что, в свою очередь, порождает заведённые тикеты с багами, которые таковыми не являются. Меня спасли созвоны с программистами, а также постоянное общение через мессенджеры. Нет, я не задалбывал всех вокруг: для созвонов вопросы сначала записывались на бумагу и затем по ходу встречи вычёркивались. В случаях сообщений, для меня лучшая тактика — если это не срочно и не критично, писать в определённое время. Например, утром и после обеда, чтобы не нарушать цикл работы программиста. Вечная борьба: двадцать минут описывать проблему текстом или созвониться на 3 минуты. Я всё же сторонник текста, и если мне нужна информация от человека, я постараюсь максимально упростить человеку понимание того, что я от него хочу. Например, используя подписи к скринам, а не просто кидая картинку с чем-то красным и словами: «Оно не работает, разберись». В качестве вывода хочу сказать, что не стоит бояться коллег, особенно программистов, которым в случае чего эти баги и править, но и бесить их не стоит — обычно вы с ними в одной лодке.
Банальный совет: Если вы написали письмо человеку с вопросом по механике процесса или потенциальному багу, то перед отправкой перечитайте и попробуйте взглянуть с его точки зрения. Скорее всего, таким образом вы найдёте пару мест, где требуются уточнения.
Шаг 3. Перекрёстные опросы по задачам в Jira и планерки
Ещё одна проблема, с которой я столкнулся и которая, вероятно, знакома многим, — это описание задач, которые нужно протестировать. Представьте, что задача, над которой разработчик сидел четыре дня, описана тремя строками. При этом там написано что-то вроде: «Разработать такую-то штуку и не забыть вот про это». Или наоборот: задача объёмом с томик «Войны и мира» сделана за час — такое напрягает.
По идее, это не должно быть проблемой, ведь как задача сформулирована, так она и проверяется. Но я заметил, что получается быстрее, а главное — качественнее проверять, если я понимаю, что и зачем делал программист.
Тут отсылка к прошлому шагу, где говорилось про общение. Маленький нюанс: если задача ставится аналитиком, тимлидом или берётся из древнего бэклога, то сам программист может неправильно её понимать. На этот случай мы ввели практику, что во время или после дэйли перекрёстно задаются вопросы по задачам. Проверяется, что все друг друга понимают. Задача QA — слушать, задавать вопросы и анализировать позиции всех сторон.
Банально? Да! Но если у вас нет такой практики, советую попробовать. Это так же касается планирования спринтов, разбора бэклога и точечных обсуждений. Зовите своего тестировщика на все эти мероприятия, пусть послушает, что там и как. С одной стороны, это трата времени, с другой — буст для последующего тестирования. Возможно, придётся поэкспериментировать со временем, выделяемым на это, тут уж всё зависит от ваших процессов.
Шаг 4. Статус тестирования - это важно
Скажу вещь, над которой многие посмеются, но ещё полгода назад у нас не было нормальных флажков «Протестировано» для задач в Jira.
Представьте! Точнее, они были, но относились к проверке аналитиком и далеко не всегда проставлялись так, как надо.
Тут уж главной проблемой было практически в одиночку придумывать и менять процесс. Добавили к задачам поле «Протестировано QA», в котором отражается состояние тестирования. Определили, в каких случаях и как он проставляется, кто возвращает задачи в работу и т. д. Заодно немного закрутили болты с полем «Протестировано» для аналитиков. На перестройку понадобилось совсем немного времени, и теперь проще отслеживать статус тестирования задач как для QA, так и для программиста. Вместо того чтобы лазить по комментариям к задаче, писать тестировщику или аналитику, теперь можно посмотреть на статусы.
Хотя, признаюсь, у нас до сих пор есть проблемы с этими статусами, так как нигде не зафиксировано, что является блокирующим и как в таком случае себя вести в конце спринта.
Банальный совет: Если у вас появилась идея, как сделать какой-то процесс в компании лучше, прежде чем его предлагать, посчитайте, сколько ресурсов и времени на это нужно. Особенно это касается новых сотрудников, которые часто мотивированы, но могут что-то не учитывать. Если вы посчитали трудозатраты на изменения и они получились намного меньше выгоды, то у вас будет дополнительный аргумент в пользу изменения. Но не забудьте посчитать время и желание людей изменять уже существующие процессы.
Шаг 5. Отчёты по ошибкам в разрезе автоматизации
Однажды меня попросили посмотреть на ошибки с последнего спринта и посмотреть, почему они проходят мимо автотестов. Именно тогда и появилась идея делать ежемесячные отчёты по найденным ошибкам.
Суть их такова: берём ошибки за месяц и внимательно проверяем причины их появления (в урожайный месяц их 40–60), так же смотрим на наличие автоматизации для этого блока. В качестве параметров я использую:
Тип ошибки (UI, «Кто-то неправильно настроил систему», функциональная и т. д.)
Есть ли автотест, проверяющий этот блок
Как нашли ошибку (автоматически или вручную)
И исходя из этих факторов, формирую вывод по каждой ошибке: нужно ли создать автотест для неё или нет.
Так же я подбиваю и другую статистику, которую после публикую в Confluence. Из неё, например, понятно, что аналитик любит ставить ошибкам наивысший приоритет вне зависимости от реального влияния ошибки. А так же можно найти момент, когда программисты решили, что нужно делать больше багов (я знаю, что они их создают, чтобы у меня была работа). Из интересного: так было определено, что нужно вводить автотесты для пользователей с разными правами и доступами на страницы. Как оказалось, программисты просто убирали кнопки страниц из списка, но не закрывали доступ.
Если вы захотите попробовать составить такой для себя, то можно воспользоваться моим вариантом или поэкспериментировать с критериями, чтобы получить более подходящий вам вариант.
На этом я пока остановлюсь. Статья написана с целью поделиться своим опытом и получить фидбек по вашим случаям, когда вы меняли процессы или что-то добавляли.
Спасибо всем, кто дочитал!