Путь развития тестировщика: как найти компанию по душе

Ксения Лопатина

QA-инженер в ISPsystem

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

Предисловие

Я окончила университет по специальности «Программная инженерия». Учебный план включал программирование, управление проектами, качество ПО и многое другое. Изучали даже тестирование, правда, всего один семестр. С таким багажом можно было пойти во многие компании. От разнообразия разбегались глаза, но с чего-то надо было начинать. В поисках работы я забрела на сайт с вакансиями ISPsystem, увидела вакансию тестировщика ПО и подумала: «Почему бы и нет?». Прошла собеседование, и меня взяли.

Тогда, три года назад, я и понятия не имела, что меня ждёт. О профессии знала из пары-тройки статей и короткого курса в университете. Спроси меня, кто такой тестировщик, ответила бы, не моргнув: человек, «жмякающий кнопки», его миссия — проверять функциональность софта и искать в нём ошибки. Реальность оказалась куда сложнее. Но обо всём по-порядку.

Начало пути. Работа как на заводе

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

Со временем мне начали давать небольшие задачи по приёмочному тестированию. Разработчики исправляли в продукте ошибки, а я проверяла — «жмякала кнопки». Задачи ставились в Bugzilla, в них было описание проблемы, иногда шаги воспроизведения и комментарии разработчика. Приходилось разбираться.

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

Конвейер по выпуску фич

Чем больше я погружалась в процесс, тем больше работа напоминала заводской конвейер. Только вместо изделия — задача. Она двигалась по пути Клиент — Продуктолог — Разработчик — Тестировщик.

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

У каждого отдела была своя канбан-доска. Задачи на них выводились из Bugzilla в виде карточек. На доске продуктолога хранился бездонный бэклог, поэтому она была самой длинной. Карточки с неё кочевали на доску разработчиков, а оттуда — к тестировщикам.

На доске отражались только задачи в очереди и в работе, после завершения они исчезали с доски. Закрыв задачу, сотрудник не знал, что произойдёт с ней потом. Как на конвейере: запчасть выходит из цеха, а что с ней будет дальше — не наша забота.

Примерно так выглядела доска тестировщиков. Цвет карточек отражал приоритет и очередность задачи

Распределение ресурсов

Когда я подросла и нарастила навыки, мне начали давать более сложные и важные задачи. Но была одна особенность — все люди внутри команды делились по фичам и отдельным модулям. Один хорошо знал интеграции, другой был гуру в финансах и документах — соответствующие задачи каждый и получал. Деление касалось не только разработчиков, но и тестировщиков, и я знакомилась с продуктом только с тех сторон, по которым мне ставили задачи.

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

Время перемен. Новая команда и новые роли

Спустя 8 месяцев работы на «конвейере» меня взяли в другую команду — на замену уволившемуся тестировщику. Пришло время перемен.

Новая команда работала над новой версией того же продукта. От предыдущей она отличалась по составу и процессам. В составе были специалисты, с которыми я раньше не работала: UX-дизайнеры и фронтендеры. Все работали по скраму с трёхнедельными спринтами, стендапами, ретроспективами и прочими его атрибутами. Вместо Bugzilla и бесконечных канбан-досок использовали удобный YouTrack.

Существенное отличие было в процессе движения задач. Задачи размещали на одной доске и группировали по модулям — так все видели общую картину. У задач в очереди не был заранее определён исполнитель и тестировщик — людей не делили по модулям. Это уже не конвейер!

И всё же первые пару недель мне было некомфортно из-за шквала новой терминологии и процессов, которые я не понимала. Пока во всё въезжала, тестировала как раньше. Но примерно через спринт приняла рабочий процесс, привыкла к ежедневным стендапам и у меня начали появляться новые интересные задачи.

Движение задач в новой команде

Тестирование прототипов — новый дивный мир

В предыдущей команде за проектирование отвечал программист, в новой — UX-дизайнер. На прототипах основывалась работа над продуктом: с них начиналась разработка новой функциональности, они же являлись техническим заданием для разработчика.

Стало ясно, что взаимодействовать с UX-дизайнерами я буду не меньше, чем с программистами. Тогда я почти ничего не знала о дизайне, тестировании прототипов и вёрстки. Началось время открытий.

В первое время мне было сложно выстраивать работу по-новому. Поэтому поначалу я тестировала прототипы. Я быстро поняла, что для этого нужно встать на место пользователя и подумать:

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

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

Новые задачи тестировщика

Я продолжала заниматься задачами приёмочного тестирования. Но теперь оно проходило иначе. Если раньше я проверяла только функциональность, то теперь ещё и соответствие задачи прототипу, вплоть до цветов, размеров, расположения и поведения элементов.

Пришлось осваивать новые инструменты. Фронтендеры научили работать с консолью разработчика: идентифицировать проблемы, находить элементы и их параметры, изучать запросы, отправляемые и возвращаемые данные. А еще показали дополнительные браузерные инструменты, которые упрощали проверку: Tape, JSON Formatter, Eye Dropper, Web Developer.

Кроме тестирования у меня появлялись и другие задачи.

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

Не обходилось без задач по автоматизации — не менее интересных: от скриптов на Bash до покрытия модулей автотестами.

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

Как найти компанию по душе

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

Задайте как минимум три вопроса:

1. Какие задачи в компании решает тестировщик? С кем взаимодействует?
2. Есть ли возможности для роста? (Возможно, компания заинтересована лишь в приёмочном ручном тестировании, а быть может есть варианты роста в конкретных направлениях, например в тестирование безопасности или автоматизации).
3. Как может измениться пул задач с течением времени?