Чтобы стать QA Engineer, глубоких познаний в программировании не нужно: скорее нужна внимательность к деталям, умение вовремя выявить баг и понимание итогового продукта. Это делает работу очень привлекательной для желающих быть причастными к IT-сфере (все-таки одна из самых перспективных отраслей, все понимаем). И вроде работа классная, задачи понятные, но на практике организовать деятельность QA бывает очень непросто, ведь зачем-то еще в команде нужны тестировщики, разработчики и бизнес-аналитики.
Случается, что пригласив в команду такого нужного QA Engineer, работодатель в реальности даже не знает чем нового сотрудника нагрузить. И тогда новоиспеченному работнику приходится организовывать свою работу самостоятельно. В такой ситуации оказалась и Ирина.
Она устроилась в английскую компанию, где несколько дней ходила и буквально выискивала себе работу. Команда разработчиков справлялась и без нее: они проверяли список запросов, вводили проекты в промышленную эксплуатацию, работали с широким покрытием автотестов. Конечно, случались и некоторые баги, иначе ее бы не приняли на работу. Например, не всегда разработчики понимали задачу до конца, возникали сложности на стороне заказчиков, обнаруживались баги. К тому же девушке хотелось, чтобы перед запуском ее мнение тоже учитывалось.
Поэтому Ирине пришлось начать построение работы QA Engineer с двух вопросов:
— Какая в компании иерархия, и кто за что отвечает?
— Что компания ожидает от QA?
Дальше — проще. На основании полученных ответов выстраиваете рабочий процесс и определяете зоны ответственности. Но начать придется все равно с азов: совместно проговорить определение профессии QA Engineer, расставив все точки в сфере IT. В зависимости от компании, на QA будет ложиться разный объем задач. Например, где-то будет чуть больше необходимости тестировать, где-то чаще придется заниматься переговорами с заказчиком, возможно, придется самостоятельно править некоторые ошибки.
Затем донесите до остальных сотрудников то, чем вы теперь занимаетесь, как планируете справляться с этими задачами и какими методами. Доносить рекомендуем в письменном виде. Договоритесь заранее к какому числу все должны ознакомиться с документом. Если вас парализует мысль о возможных неточностях в уставе, предстоящей ошибке (а вдруг на деле все будет не так?), то спешим вас успокоить — это же всего лишь на бумаге, а не в камне высечено. Если что, перепишите, дополните.
Вообще, к любому документу, связанному с новым полем деятельности, рекомендуют возвращаться через полгода. Этого времени вполне достаточно, чтобы определить и выявить неработающие истории, устранить неточности.
При формировании поля деятельности QA Engineer важно обозначить используемые методы тестирования. Самые популярные — тест на опережение (proactive) и тестирование рисков (risk-based).
При проактивном подходе к тестированию помните о качестве конечного продукта, насколько возможно его соблюсти и вообще реализовать. Тут надо сказать, что на этом моменте переоценить роль QA Engineer`а практически невозможно. Ведь именно он становится той логической и часто недостающей прослойкой между менеджерами проекта и разработчиками. Потому что мысли проджекта всегда будут направлены на комфорт пользователя, а разработчик слишком техничен, чтобы успевать думать еще и о юзерах. И тут появляется он —- супергерой QA Engineer. Который и нашим и вашим сделает хорошо.
Тестирование на рисках основано на предположении где может возникнуть баг, проверки этого места и предотвращении потенциальной проблемы.
Очень важно познакомить команду с последовательностью тестирования, которой вы собираетесь пользоваться. Ваша команда должна понимать все процессы, а проект должен оставаться прозрачным для всех участников. Ирина рекомендует взять систему ISTQB, но можно поискать и более комфортные для вас варианты.
Обговорите свои и чужие обязанности. Объясните, что несмотря на появление QA Engineer, необходимость тестировать максимальное количество раз остается на каждом из участников команды.
Сделал — затести!
Более того, есть смысл даже проговорить или прописать кто что тестит, а главное, каким образом: вручную или автоматически. Идеально, если при этом есть задокументированный Тест План, доступ к которому есть у любого участника процесса.
И, самое главное, при составлении документа с перечнем своих QA-обязанностей, не забывайте регулярно задавать себе 2 вопроса:
— Я правда хочу этим заниматься?
— Я действительно буду это воплощать в проекте?
Без этих двух вопросов весь этот полезный документ превратится в набор красивых слов для начальства. Но мы же тут не за этим собрались, а чтобы решить вполне конкретные задачи, обозначить область ответственности и сделать работу команды по-настоящему эффективной.
Прямой список обязанностей QA Engineer нигде не зафиксирован и должностную инструкцию иногда приходится создавать буквально на коленке. Впрочем, как и в любой другой новой сфере деятельности, которая еще не внесена в реестр профессий.
Сама Ирина, кстати, говорит, что периодически отходит от написанного в документе: берет на себя лишнее, забывает о главном. Потому что ничто человеческое QA Engineer`ам не чуждо. И именно для этого документ и создавался, чтобы всегда вовремя вспомнить о своих обязанностях и ответственности.
