💭 Чем занимается Software Test Automation Engineer?
Дисклеймер. Всё описанное ниже — результат моего опыта, описанный максимально простым языком, и даже может быть совсем не похоже на то, что и как делаете вы.
Внезапно понял, что пытаюсь тут писать про фреймворки и автотесты, но у многих людей, с которыми разговариваю, есть лёгкое непонимание чем именно занимается Software Test Automation Engineer (“автотестер”, “автоматизатор”, “автоматизированный тестировщик”, STAE). Т.е. все причастные знают про профессию, многие хотят стать автоматизатором, кто-то даже работает этим вот, но не все (даже из тех, кто уже работает автотестером, да-да) знают, что же делает STAE. Давайте попробую рассказать с высоты своего 2,5-летнего “опыта”.
👔 Обязанности
Условно свои ежедневные обязанности я могу разделить на четыре группы:
Далеко не везде так. Насколько я знаю, в некоторых командах STAE занимается ТОЛЬКО разработкой автотестов. Для мануальщины, развёртывания окружения и триажа есть специально обученные люди. Но у нас так. Задача STAE — реализовать полный цикл тестирования с момента получения ТЗ до подписи под релизом.
Важно понимать, что на самом деле все 4 группы мы делаем параллельно и постоянно. Держите это в голове.
🖐 1. Мануальное тестирование
Итак. Мы получили ТЗ, составили и утвердили всевозможные тест планы и тестовые стратегии, набросали чек листы, поделили планируемую работу на спринты и даже прикинули когда закончим работу. В момент когда разработчики выдали первые фичи, которые можно протестировать (не обязательно так, просто специфика проекта) мы начинаем тыкать в фичу палочкой и писать описание мануальных тестов в TMS (Test Managemen System; TestLink, например). В среднем один человек у нас на проекте пишет тесты для одной фичи ~2 недели.
Опять же, уточню, что к этому моменту мы уже сделали:
- Подготовительную работу для разработки автотестов. Мы начали писать фреймворк, определились с какой-то структурой классов и необходимыми методами.
- Часть работы по автоматизации процесса тестирования. У нас есть как минимум тестовый сервер и та самая TMS куда мы заносим мануальные тесты, а в дальнейшем туда будут автоматически отправлять результаты наши автотесты.
💻 2. Разрабока автотестов
У нас есть заготовка фреймворка, у нас есть мануальные тесты и это значит, что мы можем начинать писать автотесты. Писать автотесты в самом начале обычно сложнее, чем ближе к концу проекта. И дело не в “набитости руки”. Дело в том, что в начале у фреймворка не хватает функционала и, например, вам нужно иметь возможность писать данные в файл — вам нужно написать для этого метод, вам нужно читать данные из файла — вам нужно написать для этого метод. И так каждый раз. Это утомляет. С другой стороны ближе к концу вам нужно думать о большом количестве зависимостей, которыми обрастает фреймворк чтобы изменив один метод для себя не сломать что-то в других тестах. В идеальном мире этого не случится, в реальном — регулярно.
Короче, тут мы пишем много кода, дебажим его, исправляем, опять дебажим. В среднем ~2 недели.
🤖 3. Автоматизация процесса тестирования
Люди в массе своей ленивы. Тестировщики в массе своей люди. => Тестировщики в массе своей ленивы. Они придумали множество способов сделать свою жизнь проще делигировав часть своих задач компьютерам. Главный друг тестировщика — системы предназначенные для обеспечения процесса непрерывной интеграции программного обеспечения. Их больше одной. На вскидку могу вспомнить Jenkins (используется у нас на проекте), CircleCI, Travis CI… Если понятным языком и применительно к работе STAE, то это утилита, которая позволяет запустить следующий процесс по различным тригерам (например, по времени, по обновлению в системе контроля версий и т.д.):
- Забрать последнюю версию кода тестируемой программы из системы контроля версий;
- Сбилдить (читай “собрать”, “скомпилировать”) тестируемую систему из исходников;
- Установить тестируемую систему на хардвер (сервер, компьютер, виртуальную машину, какой-то девайс);
- Запустить автотесты;
- Собрать и сохранить логи тестов;
- Отправить (“зарепортать”) результаты тестов в TMS;
- Показать статистику по последнему прогону тестов или за период.
У этого процесса есть название, Continuous Integration или попросту CI (читается “си-ай”). Про концепцию в любом случае будет полезно и интересно почитать если собираетесь связать жизнь с этой их IT.
В этот процесс мы и встраиваем наши тесты чтобы они запускались на ежедневной основе и если что-то сломалось, то мы могли понять когда и в результате каких изменений это произошло. Удобно. Вообще Jenkins это очень удобная штука. Грубо говоря, вы можете сделать так, что каждый вечер, когда все уже уйдут с работы и не будет никаких обновлений, условный Jenkins сам (что важно!!!) запустит описанную выше цепочку и когда вы придёте на следующий день на работе вы увидите результаты тестов и займётесь триажем.
🔎 4. Триаж
Если верить Википедии, то “Триаж (фр. triage, сортировка) — распределение пострадавших и больных на группы, исходя из нуждаемости в первоочередных и однородных мероприятиях (лечебных, профилактических, эвакуационных) в конкретной обстановке.”
Применительно к тестированию это процесс “разгребания логов”. Пришли вы утром на работу и видите, что в результате прогона тестов Jenkins’ом из 100 ваших тестов 85 прошли (“passed”), а 15 — не прошли (“failed”). Вот с этими 15ю вам нужно разобраться чтобы понять причины фейлов, найти виноватых, завести дефекты или исправить/доработать код самих тестов (так тоже бывает, да; например, вы могли не учесть что-то и тест падает именно из-за этого). Это обычно самая неприятная часть работы (лично для меня). Горы логов, у вас есть ваша “основная работа”, которую вы должны закончить в ближайшие две недели, часто совершенно непонятно что именно случилось и почему тест упал. Долго, нудно, но очень важно.
⏰ Среднестатистический рабочий день STAE (меня)
9:00 Пришёл на работу. Просмотрел почту, заглянул в Jenkins, проанализировал фейлы тестов, завёл дефекты или сделал таск на изменение кода тестов.
11:00 Ежедневный митинг с командой. Обусдили новости, рассказали что сделали и чем будете заниматься до завтра.
11:30 Ныряем в запланированные задачи с перерывом на обед и ещё какие-то митинги. Обычно пишем код (или проверяем чужой), делаем что-то в Jenkins или TMS.
18:00 Если нет митингов с заказчиком (который часто из США и только пришёл на работу) ушёл домой.
20:00 Jenkins запустил рутинный процесс, который будет бежать до утра.
🍀 Вместо заключения
Ещё раз уточню, что всё вышесказанное — мой опыт. Меня так научили: “работа автоматизатора над тестами заканчивается в тот момент, когда тесты автоматически (!!!) запустились в CI”. На самом деле, конечно, не закончилась. Потом будет бесконечный триаж, поломки в Jenkins, проблемы с оборудованием…
С какими-то изменениями это всё применимо, как мне кажется, к большинству проектов если разработка ведётся хотя бы по каким-то методологиям, а на представляет собой анархию. Мы же всё-таки инженеры. ;)
Если возникают вопросы — задавайте в комментариях, с радостью отвечу на что смогу. Если нет — значит я неплохо всё описал и лайк, шер, алишер!