Что тестировщик уже умеет для работы аналитиком
Всем привет! Меня зовут Мария Макарова, я работаю системным аналитиком в Мир Plat.Form.
В ИТ я почти 10 лет, а непосредственно в аналитике — сравнительно недавно.
В этой статье я хочу поделиться своим опытом смены деятельности в ИТ, а именно рассказать про переход из тестирования в аналитику. Думаю, это будет интересно тем, кто ищет варианты развития, сомневается в переходе в другую сферу или может вообще только в начале своего пути в ИТ.
Сначала немного предыстории
Несмотря на то, что у меня профильное образование в области информационных технологий, после окончания университета я пару лет работала не совсем по профилю — была специалистом информационного сервиса и сопровождала действующих клиентов, у которых была установлена правовая система.
Спустя время я решила вернуться в ИТ и по совету одногруппницы прошла собеседование на должность специалиста по тестированию в региональном подразделении интегратора. Автоматизации тогда толком еще не было, поэтому сначала все тестировали вручную.
Постепенно стала развиваться автоматизация, которая дошла и до того проекта, на котором я на тот момент работала. Вначале я сильно загорелась идеей изучить java и тоже писать код. Да, для тестов, но все-таки — код.
Закупившись книгами и курсами, я погрузилась в процесс обучения, а также смотрела автотесты, которые уже писали опытные ребята на проекте. Спустя время мне стало очевидно, что все-таки перейти из ручного тестирования в автоматизацию не получится, так как обучение шло тяжело из-за отсутствия реального интереса к программированию.
В частности, после и так целого дня интенсивной работы снова садиться вечерами за монитор мне уже было невыносимо. Обсудив вопрос с начальником, решили, что как тимлид тестирования на проекте я останусь, но развиваться в сторону автоматизации не буду. Пришло время определить для себя новые перспективы.
Размышляя о дальнейшем развитии, поняла, что остается два варианта: скрам-мастер или аналитик. Какое-то время я усилено изучала обе эти темы, общалась с коллегами на данных должностях, брала небольшие задачи по этим сферам, но никак не могла сделать выбор. В итоге я остановилась на том проекте, где задачи меня заинтересовали больше. Это были задачи по аналитике.
И так, что же мне пригодилось в аналитике из работы тестировщиком
1. Собирать информацию о работе системы и знать источники этой информации
Когда тестировщик приходит на новый проект и в новую команду, есть несколько вариантов развития событий.
Идеальная ситуация: на проекте есть документация — актуальная, понятная, достаточно полная. Авторы документации также работают в команде, вас с ними знакомят. Есть коллеги, которые обозначают, что к ним можно обращаться по любым вопросам. Бизнес-заказчики всегда на связи и готовы оперативно и добродушно отвечать на уточняющие вопросы.
Но обычно происходит так: информация по функционалу системы разбросана по разным источникам, многие из которых давно не обновлялись. Авторы документации в лучшем случае на другом проекте, а то и вообще уже не работают в компании, со своими вопросами до них не добраться. Заказчики отвечают не охотно и односложно.
И тогда тестировщику приходится самому делать много работы: расспрашивать разработчиков и других тестировщиков о системе, актуализировать имеющуюся документацию по мере возможностей, налаживать коммуникацию с заказчиками (самостоятельно или через менеджера проекта), задавать много вопросов.
По сути, в данной ситуации тестировщик выполняет задачи аналитика.
2. Описывать и структурировать требования/знания/данные
Тестировщик в своей работе тоже готовит своего рода документацию по системе — это тестовые сценарии. Тест-дизайн — важная часть работы в тестировании. Ведь трудно проверить корректность поведения системы, если не знаешь, по каким сценариям ее проверять. Поэтому, изучив ТЗ и документацию, тестировщик должен написать тестовые сценарии, и лучше, чтобы это были хорошие тестовые сценарии: понятные, пошаговые, без двойного толкования, с примерами тестовых данных, с однозначным ожидаемым результатом, максимальным покрытием возможных вариантов работы системы и т.д. Интересно, что в моей практике большинство коллег из тестирования не любили именно эту часть работы, она казалась им скучной, а я наоборот обожала писать тест-кейсы.
Получается, что тестировщик в своей работе тоже занимается сбором и переработкой информации о работе системы.
Как это перекликается с аналитикой?
Описывать требования, проектировать схемы, составлять таблицы. Составлять таблицы. Вносить правки. Описывать требования. Проектировать схемы. Описывать требования. День за днем. Это теперь большая часть работы, если ты перешел в аналитику. И частично ты к этому уже готов.
3. Смотреть на проект и глазами тестировщика, и со стороны разработчика
Как мне кажется, это очень важное преимущество у тех, кто переходит в аналитику из тестирования. Так как во время уточнения требований по системе, ты уже в процессе разговора понимаешь, какие вопросы еще могут возникнуть у тестировщика (ведь его «голос» все еще в твоей голове). Когда пишешь документацию, то какую-то ее часть ты уже оформляешь в стиле тестовых сценариев. За время работы в тестировании ты обычно плотно общаешься с разработчиками по теме багов, в результате чего начинаешь хоть немного, но понимать их логику, ход рассуждений, что им особенно важно для разработки, и потом также это используешь для более полного описания требований.
4. Уметь работать в команде
Работа аналитиком также предполагает много общения, взаимодействия с командой и с разными отделами на проекте (и менеджеры, и, возможно, даже вендоры). У одних узнай, другим расскажи, третьих сведи и вообще собери встречу, ведь кажется, что нужно снова все вместе обсудить. Особенно, если речь идет про большие проекты, большие команды, интеграцию систем. Стрессоустойчивость на созвонах — как отдельный вид искусства.
Но это не означает, что нужно перестать учиться и посвятить время только практической части.
В аналитике существуют свои правила, требования, стандарты. Я бы рекомендовала пройти обучающий курс, почитать профильную литературу, посетить конференции — так вы сможете получить структурированные знания в области аналитики, обнаружить свои пробелы, наметить план по их устранению и снова нырять в учебу. У нас в Мир Plat.Form есть и своя внутренняя школа по обучению сотрудников, курс по аналитике я проходила именно у нас.
Вкратце, что еще предстоит освоить для работы в аналитике:
Теперь ты не всегда тот, кто спрашивает, но ты — тот, кто объясняет. В целом, это перекликается с пунктом «умение работать в команде», но все же предполагает больше общения, взаимодействия, проявления инициативы в этом вопросе. Общения станет больше.
Самое весомое различие — это, пожалуй, изучение разных протоколов, нотаций и т.д. Диаграммы последовательности, схемы процессов в нотации BPMN, написание документации по API — это и многое другое, что при работе в тестировании было уже подготовлено кем-то, аналитику приходится делать самостоятельно. Важно изучить и работу программных средств, которые для этого требуется (Draw.io, Swagger и т.д.).
Нужно знакомиться с «окружением» вашего проекта, а не только внутренней работой системы. Например, кто пользуется системой, для кого она, какая вообще у нее бизнес-цель, нефункциональные требования и т.д.
Существует бизнес-анализ и системный анализ. Ты можешь думать, что будешь заниматься чем-то одним, но зачастую на проекте приходится выполнять задачи из обеих областей, грань между ними тонка.
Вот такими выводами и наблюдениями захотелось поделиться. В аналитику приходят разными путями, один из них — тестирование. Не бойтесь пробовать новое, ищите свое, развивайтесь!
