Среди всех заинтересованных лиц можно выделить подгруппу, с которой аналитики работают наиболее плотно - разработчиков (или как их называет BABOK - Implementation Subject Matter Expert) и QA. Как мы выглядим в их глазах, что они от нас ждут и чем они недовольны?
На эти и другие вопросы согласилась ответить Анна Каплун, Lead QA Engineer в компании Intellias, тренер в компании SkillUP.
Небольшая предыстория. Мне довелось поработать с Анной на нескольких проектах. Редко когда встретишь такого внимательного к каждой мелочи, грамотного и разностороннего специалиста (иногда въедливого, но только для пользы делу). Настоящий специалист по качеству, который мотивирует своих бизнес-аналитиков к постоянному профессиональному росту! Ну а теперь вопросы и ответы.
Почему ты не перешла в бизнес-аналитики?
Пробовала, просто понравилось меньше, чем тестирование. В моем случае причина скорее психологическая – слишком много общения по сравнению с работой в тестировании. Бизнес-аналитик работает как с заказчиком, так и с командой, причем со всеми ее участниками. В этом смысле у тестировщика «круг общения» в целом меньше, самое оно для интроверта, если нравится то, чем занимаешься.
Имеет ли смысл тестировщикам переходить в бизнес-аналитики?
Зависит. У каждого свои пути и свои интересы. Если не рассматривать тестирование как основное желаемое занятие, то бизнес-аналитика – одна из разумных, как по мне, альтернатив. Большинство знакомых мне «свитчеров» из тестирования переходили или в разработку, или в менеджмент, или в бизнес-анализ. Мне кажется, это путь для людей с системным мышлением, которые при этом любят и умеют общаться (но не настолько, как менеджеры), объяснять, добывать информацию. Также это разумная опция, если нравится предметная область. Хороший аналитик будет иметь с ней дело куда больше, чем среднестатистический тестировщик.
Должны ли тестировщики изучать техники и подходы бизнес-анализа/инженерии требований?
На мой взгляд, это полезное знание. Хотя бы в общих чертах имеет смысл познакомиться с основными идеями. Как минимум, стоит представлять, откуда берутся требования, как расставляют приоритеты. Особенно важно понимать формат, в котором требования записывают. Это может потребовать некоторой подготовки (скажем, к диаграммам UML определенно подольше привыкать, чем к, допустим, use case-ам по Коберну). Но знание это окупается сполна, поскольку сразу отпадет часть вопросов по содержанию требований. Ну, и еще один фактор за – в небольших проектах тестировщик иногда сталкивается с необходимостью самостоятельно решать задачи бизнес-анализа. Лучше подготовиться к такому заранее, мало ли, чем в жизни предстоит заниматься. За плечами не носить.
Как ты относишься к профессиональным сертификациям?
Как к способу упорядочивания знаний и конкурентному преимуществу. Не воспринимаю сертификации как некое обязательное доказательство профессиональных знаний и навыков. Но сдавать экзамены в своей сфере, думаю, полезно. Как минимум, это говорит о человеке, что ему хватило силы воли на подготовку. Кроме того, на некоторых проектах сертификация обязательна. Это может быть хорошим стимулом, если хочется работать в каком-то конкретном месте.
Что при взаимодействии с бизнес-аналитиками тебя раздражает больше всего?
В моем текущем проекте – их отсутствие. 😊 Если вспомнить предыдущий опыт, то сталкивалась с парой раздражающих крайностей: отсутствие конкретики и отсутствие общей картины. В первом случае это требования, из которых в целом понятно, что за программу мы делаем, но больше непонятно ничего. То есть когда дело доходило до декомпозиции и реализации конкретных задач, команде приходилось справляться своими силами, что приводило к довольно большому количеству изменений по результатам демо. Второй случай – обратная ситуация, когда более чем достаточно деталей, аналитик проверяет (или сам пишет) тест-кейсы и генерит тестовые данные, но проект в целом сложный, и за обилием деталей никто в команде (возможно, кроме архитектора, но до сих пор не уверена) не представляет, а что же за систему мы делаем, какие бизнес-задачи она решает. За перекрашиванием кнопок и добавлением колонок в таблицы с результатами поиска так и не нашлось времени узнать (а потом ушла с этого проекта, так что тайна до сих пор не раскрыта).
О чем бизнес-аналитики забывают написать?
О нефункциональных требованиях. Даже с учетом заданных вопросов добыть тут какую-то информацию практически всегда было трудно. Особенно, когда всем понятно, что пишем высоконагруженную систему, мне нужно запланировать и сделать тестирование производительности, а какие-то конкретные ограничения тут приходится чуть ли не самим придумывать. Помогали больше маркетологи и девопсы, чем аналитики. Вообще в целом ситуация с технической, скажем так, составляющей требований в большинстве случаев печальна. Не только производительности касается. Еще часто забывают о необходимости выписать тексты сообщений об ошибках (программисты и даже тестировщики – не совсем те люди, которых стоит обязать их придумывать, может получиться что-то курьезное), о единицах измерения (был забавный случай, когда вся команда была уверена, что возраст нужно измерять годами, а заказчик – что днями), о конфигурациях, для которых нужно поддерживать работоспособность системы… Список можно продолжать долго.
Каких знаний/навыков бизнес-аналитикам не хватает?
Часто не хватает навыков для уточнения технических требований, как писала выше. Помимо этого, далеко не все аналитики хорошо ориентируются в предметной области. Еще полезно представлять, что делают другие в команде, а значит, что они ожидают от требований. Архитектор ожидает хорошего представления об общей картине, тестировщик – что аналитик не забудет про детали и разнообразные corner cases (и не придется задавать множество вопросов «а что будет, если…») и т.д. Часто в команде нет выделенного UI/UX дизайнера, и на аналитика ложится работа по созданию макетов. Далеко не все владеют какими-то инструментами в этой области (приходится тестировщикам осваивать Balsamiq и подобное).
Какая часть требований действительно нужна тестировщикам/что тестировщики ждут от бизнес-аналитика?
Для создания end-to-end тестов тестировщику нужно знание о системе в целом, ее частях, как они взаимодействуют между собой с точки зрения бизнес-логики, данных, ограничений по времени. Для системных тестов нужно много подробностей по каждой функции: точное описание каждого отдельного данного (на вход и на выход) и ограничений (обязательность, разрешенные символы и т.п.), правил их взаимодействия, последовательностей шагов, которые пользователи могут осуществлять в программе, способов вызова каждой функции (про это, кстати, тоже часто забывают написать). Ну, и вышеупомянутое: corner cases, сообщения об ошибках, нефункциональные требования. Все это важно, просто с разных точек зрения.
Agile или Waterfall?
Можно ли один раз зафиксировать требования, или предполагаются изменения? Это и даст ответ. 😊 Каждому свое. В waterfall все очень понятно и предсказуемо (и это прекрасно), но цена ошибки аналитика в этом подходе крайне высока. Agile безопаснее.
Нужен ли выделенный бизнес-аналитик, если есть PO со стороны заказчика?
Зависит от мастерства РО. Если он хорошо делает свою работу, то можно и обойтись. Но, как и в любой области, действительно хорошие специалисты встречаются не так часто, как хотелось бы. Кроме того, РО – часто довольно занятые люди, это не основная их занятость, выделенный аналитик может решить проблему доступности РО для команды в любой момент времени.
Как ты оцениваешь идею ведения всех требований в виде тест-кейсов?
Не особенно разделяю эту концепцию. Все требования в виде тест-кейсов вести будет дорого и не оптимально. Приемочные требования можно представлять в виде описания конкретных проверок, но все вообще – зачем? Тестировщик думает с точки зрения возникновения ошибок, такая детализация в требованиях часто не нужна. Кроме того, некоторые тест-кейсы будут для требований бесполезны (описывать уже известное), а в тестировании – вполне, поскольку предназначаются для каких-то конкретных случаев, связанных с выбранным языком программирования, например. Тест-кейсы и требования – разные точки зрения, как по мне, и тест-кейсы будут избыточны для описания требований. Зачем смешивать?
Специалист по ручному и автоматизированному тестированию. В чем разница для бизнес-аналитика?
В конкретизации требований и наличии примеров, на мой взгляд. Автоматизатору нужны конкретные сценарии, с очень конкретными шагами и данными, которые он будет автоматизировать. Специалист по ручному тестированию чаще всего сам занимается составлением тестов, автоматизатор – как повезет. Если нет выделенного человека, ответственностью которого будет тест-дизайн, это может лечь на плечи бизнес-аналитика, следовательно, ему придется заботиться о том, чтобы автоматизатору было достаточно данных для работы. Это примерно то же, что и для программистов, но нужно описать тесты, а не логику приложения.
На этом месте вопросы и свободное время у Анны и меня закончилось :)
Тренинги от "Art of Business Analysis":