top of page

Взгляд на бизнес-аналитиков со стороны QA

Обновлено: 18 янв. 2019 г.

Среди всех заинтересованных лиц можно выделить подгруппу, с которой аналитики работают наиболее плотно - разработчиков (или как их называет BABOK - Implementation Subject Matter Expert) и QA. Как мы выглядим в их глазах, что они от нас ждут и чем они недовольны?

На эти и другие вопросы согласилась ответить Анна Каплун, Lead QA Engineer в компании Intellias, тренер в компании SkillUP.


Небольшая предыстория. Мне довелось поработать с Анной на нескольких проектах. Редко когда встретишь такого внимательного к каждой мелочи, грамотного и разностороннего специалиста (иногда въедливого, но только для пользы делу). Настоящий специалист по качеству, который мотивирует своих бизнес-аналитиков к постоянному профессиональному росту! Ну а теперь вопросы и ответы.


Почему ты не перешла в бизнес-аналитики?

Пробовала, просто понравилось меньше, чем тестирование. В моем случае причина скорее психологическая – слишком много общения по сравнению с работой в тестировании. Бизнес-аналитик работает как с заказчиком, так и с командой, причем со всеми ее участниками. В этом смысле у тестировщика «круг общения» в целом меньше, самое оно для интроверта, если нравится то, чем занимаешься.


Имеет ли смысл тестировщикам переходить в бизнес-аналитики?

Зависит. У каждого свои пути и свои интересы. Если не рассматривать тестирование как основное желаемое занятие, то бизнес-аналитика – одна из разумных, как по мне, альтернатив. Большинство знакомых мне «свитчеров» из тестирования переходили или в разработку, или в менеджмент, или в бизнес-анализ. Мне кажется, это путь для людей с системным мышлением, которые при этом любят и умеют общаться (но не настолько, как менеджеры), объяснять, добывать информацию. Также это разумная опция, если нравится предметная область. Хороший аналитик будет иметь с ней дело куда больше, чем среднестатистический тестировщик.


Должны ли тестировщики изучать техники и подходы бизнес-анализа/инженерии требований?

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