Предыстория вопроса
Давным-давно, когда деревья были большими, солнце светило ярче, а телефоны не работали без проводов, программисты делали все сами. Сами выясняли, что хочет заказчик, сами писали программу, сами ее тестировали. Прошли годы, отрасль расширилась, и появились первые специализации. Аналитик стал выяснять и описывать требования, дизайнер – продумывать внешний вид, разработчик – писать код, тестировщик – проверять, правильно ли все работает. В наше время тенденция увеличения численности команд тестирования поставила перед руководителями новый вопрос, который пока еще не имеет однозначного ответа: нужна ли специализация тестировщиков внутри одной команды?
Специализация: когда она работает на нас, а когда – против?
Для начала отметим некие общие принципы, которые нужно учесть.
Итак, специализация явно нужна в следующих случаях:
- тестируется критичное ПО, ошибки в котором могут затрагивать жизнь и здоровье людей, а также крупные финансовые потоки;
- специализированные тестировщики одних направлений на вашем рынке дороже тестировщиков других направлений, а также существенно дороже широкопрофильных специалистов (нет смысла тратить «дорогой» труд на «дешевые» задачи и нет смысла учить тестировщиков на специалистов – выучась, они продолжат работать за прежнюю зарплату лишь до первого интересного предложения в LinkedIn);
- узкопрофильный тестировщик может обслуживать более одного проекта в вашей компании (например, автоматизаторы или юзабилисты часто работают сразу на нескольких проектах);
- вы решили отдать на аутсорс некоторые задачи – простые или сложные разовые (типа полной автоматизации устоявшегося регресса или юзабилити-оценку).
Нет смысла организовывать специализацию, если:
- в команде вы сталкиваетесь с постоянной текучестью кадров;
- у вас постоянно срываются все сроки, а тестируют все и вся (в этом случае ни к чему тратить лишние деньги на специалистов – любой тестировщик при выполнении экстренно попавшей к нему любой задачи не пропустит критичные баги, так как «по чуть-чуть» знает всё);
- у вас вообще 1-2 тестировщика на весь проект;
- разные специалисты имеют одинаковую цену у вас на рынке (освоение соседней специализации сотрудником никак не изменит затраты на команду, а «потрогать» соседнюю область ему будет интересно, что в итоге даже улучшит мотивацию на проекте);
- у вас вообще очень трудно нанять хоть какого-то тестировщика (придется учить того, кто есть).
Специализации в тестировании
Рассматривая основные специализации тестировщиков, мы постараемся описать их особенности, а также причины, которые могут побудить нас выделить тех или иных специалистов в отдельное направление.
1. Тест-аналитик.
Представьте себе тестировщика, который получил продукт целиком и видит его в первый раз. Как вообще составить план тестирования? Разбить ли продукт постранично или на модули? Нужно ли выделить основные сценарии использования и пойти по ним или постараться скомбинировать эти подходы? Тестировать ли API-интерфейс?
Все эти задачи решает тест-аналитик: он создает верхнеуровневые концепции продукта, рисует карты модулей и функций, продумывает необходимость тестирования документации и других сопутствующих аспектов. Конечно же, он работает в тесной связке с ПМ, ведь итогом его работы должно стать достижение единых целей проекта.
2. Тест-дизайнер.
Итак, мы получили общую концепцию тестирования от тест-аналитика. Что применить дальше? Какие методики использовать для максимального покрытия продукта в требуемые сроки? Какие выбрать граничные значения? Как осуществить разбиение на классы эквивалентности? Как комбинировать значения? Использовать ли Pairwise? Как именно по шагам воспроизводить сценарии пользователя?
Итогом работы тест-дизайнера всегда становятся уже готовые четкие тест-кейсы или чек-листы, по которым даже самый «зеленый» новичок может выполнить тестирование. Более подробно о работе такого специалиста вы можете прочитать в статье Антона Алексеева.
Причины для выделения в команде отдельного тест-дизайнера или тест-аналитика очень схожи, причем нередко один выделенный тестировщик совмещает обе эти функции.
Так когда же нам нужно выделить какую-то из упомянутых специализаций? Из опыта скажу, что это довольно частое разделение (тест-аналитик также может выполняет на проекте функции линейного тест-менеджера). Оно необходимо при следующих условиях:
- продукт сложен и требует хорошего знания реальных стратегий и задач пользователя;
- имеется большое количество автоматизаторов, которым для работы нужны готовые тест-кейсы;
- ПМ проекта находится в другой стране, разговаривает на другом языке или отказывается общаться более чем с одним представителем от команды тестировщиков (этому представителю придется максимально сфокусироваться на тест-анализе);
- вы регулярно набираете юниоров, не способных самостоятельно написать качественные тест-кейсы.
3. Автоматизатор (тестировщик, который пишет авто-тесты).
Эта специализация выделяется практически всегда. Рассмотрим необходимость ее обособления на конкретном примере.
Компания «Жалко денег» (все совпадения случайны) наняла несколько юниоров, которые успешно тестировали все вручную, вот только 90% времени их работы занимало прохождение регресса. Компания выбрала самого толкового новичка и выделила ему денег на курсы. Став автоматизатором, он написал автотесты на весь регресс, и тестирование релиза заметно ускорилось (хотя ручных тестировщиков при этом стало на одного меньше). Компания «Жалко денег» была очень довольна, пока этот самый автоматизатор не попросил повышения зарплаты. Компания, конечно же, отказала со словами: «Ты чего, мы ж за твое обучение платили!» На следующий день автоматизатор выбрал из шести предложений о работе самое дорогое и уволился! Компания была просто счастлива: автотесты работали, количество тестировщиков сократилось, зарплатный фонд уменьшился, жизнь удалась!
Но шло время, релиз сменялся релизом. Часть автотестов устарела, часть новых модулей попала в регресс, но автотестов на них уже не было. Компания пару раз оплатила переработки по субботам, но ситуация не улучшилась. Что делать? Нанять еще одного юниора или опять «вырастить» автоматизатора? Неее, компания сделала выводы из своих ошибок и приняла следующее решение: все тестировщики обязаны немного освоить автотесты! Скажем, по вечерам. Скажем, по материалам, оставшимся от ушедшего автоматизатора. Готовы угадать, что было дальше? Наиболее смышленые тестировщики справились с задачей и, указав опыт автоматизации, немедленно отправили резюме на оставшиеся 5 предложений о работе. Менее способные плакали и просили избавить их от мучений; их рабочие показатели падали, они пропускали баги уже и вручную. В конечном итоге, и эти бедолаги пошли обновлять резюме.
Из приведенного примера мы сделаем основной вывод:
Специализацию совершенно необходимо выделять в том случае, если такой сотрудник стоит на рынке дорого!
Очевидно, что нет никакого смысла тратить время «дорогого» специалиста на те задачи, которые может выполнить сотрудник «подешевле». В то же время не стоит надеяться и на то, что сотрудник, освоивший более дорогую квалификацию, не заметит того факта, что рынок предлагает за нее более высокую оплату.
4. Юзабилити-тестировщик.
Очень интересная специализация, позволяет понять, насколько продукт удовлетворяет явным и скрытым желаниям пользователя. Задача такого специалиста – проверить, как часто пользователь ошибается при выполнении сценариев, может ли он вообще понять, как их нужно выполнить, и не откажется ли пользователь от нашего продукта из-за проблем в работе с ним.
Функции юзабилити-тестировщика крайне редко возлагают на специально выделенного специалиста, так как обеспечить его постоянную занятость на одном проекте очень трудно. При этом и задачи, решаемые им, весьма специфичны – например, сбор фокус-групп. Поэтому чаще всего вместо специализации применяют другое решение – заказывают тестирование юзабилити на аутсорсе у специализированных компаний.
5. Ручной тестировщик.
Как правило, эта специализация присутствует в команде по умолчанию. Говорить о ее особом выделении можно в тех проектах, где большинство тестировщиков – автоматизаторы; тогда у нас появляется отдельный тестировщик для тех немногих тестов, которые невозможно автоматизировать (обычно это сложные плавающие UI, капчи, узнаваемые образы, анализ звука и т. д.).
6. Узкопрофильный отраслевой специалист (например, геймдизайн, банковское дело).
Существуют отрасли, в которых трудно начать тестирование без наличия дополнительных знаний. Для тестирования онлайн-казино нужно знать не просто правила игры в покер, но и все стратегии игроков, способы «мухлежа» и проблемы, которые могут возникнуть во время игры. Есть научные проекты, куда не возьмут без знания аэродинамики. Даже ММОРПГ-игры трудно тестировать без понимания механики боя с боссом в рейде.
Нужно ли содержать отдельных экспертов по отрасли? Как правило, нет. Если вы посмотрите на вакансии банковского ПО, то увидите: везде в требованиях указан опыт работы в банковской сфере. Если же проект связан с очень редкой областью знаний, то вам придется самостоятельно обучать тестировщиков; и в этом случае гораздо эффективнее окажется обучить сразу всех (чтобы работа не встала, когда единственный «знаток», например, уйдет в отпуск).
Выделение отраслевого специалиста не требуется, если вы уже имеете тест-аналитика или тест-дизайнера: их знание отрасли как раз и будет существенно глубже, чем у остальной команды.
7. Специалист по тестируемому продукту.
В целом, эта специализация похожа на предыдущую, но она возникает в том случае, когда проект очень старый.
Представьте себе человека, который может ответить на вопрос:
1) Какие модули могут быть связаны с новым функционалом и могут деградировать после релиза?
2) Всплывал ли такой баг когда-то раньше в каком-либо модуле?
3) Почему тут такой странный костыль и заводить ли баг?
4) Откуда у нас следы интеграции с Фейсбуком?
Такого сотрудника всегда ужасно боятся потерять! Нужен ли он? Мое личное мнение: нет! Наличие такого человека – всего лишь симптом проблемы: ваш продукт плохо задокументирован. Попробуйте каждый раз, обращаясь к нему за подсказкой, задуматься: в каком формате мы могли бы хранить информацию о взаимосвязи модулей? храним ли мы закрытые баги, есть ли по ним поиск? Эти решения позволят сделать «уникальную информацию» доступной всем.
Существует и частный вид такой специализации – «специалист по отдельному модулю продукта» (например, можно использовать разделение команды на тестировщиков «фронтэнда» и «бэкенда»). Как показывает практика, такое решение применимо только при следующей ситуации: модули настолько отделены друг от друга, что их можно практически рассматривать как разные проекты. Во всех иных случаях время, затраченное на коммуникацию «специалистов по отдельным модулям» (выяснение, «на чьей стороне мяч»), только увеличивает суммарные трудозатраты на тестирование.
8. Локализатор.
Еще один вид часто выделяемой специализации. Может показаться, что для адаптации продукта к условиям другой культуры достаточно просто перевести текстовую часть. На самом деле в каждой стране есть свои традиции (у англичан календарь начинается с воскресенья), часто встречаются устоявшиеся названия типовых кнопок и меню, а, например, для арабских пользователей и вовсе придется поменять компоновку страниц, ведь они читают справа налево. Если ваша компания регулярно выпускает релизы на разных языках, вам обязательно нужен тестировщик-локализатор на каждый язык.
9. Интегратор.
Это одна из новых формирующихся специализаций. В первую очередь она используется для тестирования продукта через API-интерфейсы, обеспечивающие интеграцию как модулей, так и продуктов. В основе этого направления лежат навыки не столько тестировщиков, сколько разработчиков (их юнит-тесты – это промежуточный шаг к системным тестам). В данный момент внутреннюю интеграцию модулей тестируют в большинстве случаев разработчики, а вот проверка внешнего API уже постепенно входит в компетенцию тестировщиков. При этом тестирование интеграции, построение запросов и ответов и просмотр логов обычно никак не адаптированы для тестирования вручную.
Сейчас мир IT все больше переходит от отдельных продуктов к интегрированным средам, в которых сообща работает множество продуктов. Авторизация через соцсети стала стандартом. Уже встречаются (хоть и не так часто) вакансии с заголовками «тестировщик-интегратор»; нельзя исключить, что эти навыки станут новой отдельной специальностью (подобно тестировщикам-автоматизаторам, которые отделены от разработчиков и от ручных тестировщиков). Я же придерживаюсь иного мнения: учитывая тенденцию сращивания продуктов, знание принципов тестирования продукта через API интерфейсы станет обязательным для всех тестировщиков.
10. Специалист по тестированию документов.
Есть два вида документации – внешняя и внутренняя. К внешней относятся «пользовательские соглашения», «справки», «сопроводительная документация», к внутренним – ТЗ, ПМИ, «сценарии использования». На данный момент практически весь этот массив информации проверяется самими тестировщиками. Исключение составляют продукты, где в документации обязательно должны быть представлены ссылки на действующие ГОСТы или законы РФ. Именно в этом случае иногда целесообразно выделить отдельного специалиста, знающего ГОСТы и (в идеале) имеющего базовую юридическую подготовку. Он сможет проследить за тем, чтобы компания не попала на большие штрафы из-за пары неудачных формулировок.
11. Специалист по безопасности.
Всем известны наши знаменитые хакеры! Они могут не только взламывать базы данных и изменять или стирать информацию, но даже подменять содержимое страниц сайта и перехватывать данные, которые пользователь вводит при работе с вашим продуктом. Конечно же, проверить степень защищенности продукта от таких взломов и предложить меры борьбы – нелегкая задача. Серьезные специалисты этого направления формируются не за один день и почти всегда предпочитают заниматься исключительно своими функциями. Если ваш продукт не связан с большими деньгами или с секретными данными, то брать такого специалиста на полную ставку вам будет нецелесообразно – есть смысл заказать разовую оценку защищенности продукта в специализированных компаниях (они же могут написать вам набор типовых тестов для будущих релизов, которыми вы будете проверять безопасность в дальнейшем).
Подведем итоги
Даже после простого перечисления специалистов-тестировщиков становится очевидно, что встретить их всех внутри одной команды практически невозможно. Скорее, мы будем говорить о самом принципе: нужно ли добиваться того, чтобы каждый тестировщик активнее развивался в сторону какой-либо узкой специализации, или, напротив, стремиться к их полной универсальности?
На этот вопрос нет однозначного ответа. Симфоническому оркестру и уличным артистам нужны разные музыканты, а для строительства сарайчика на даче не нужна команда строителей и архитекторов. В своей команде вы можете выделить одну или сразу несколько специализаций, поручить одному тестировщику две специализации; возможно, какие-то направления окажется проще отдать на аутсорс. В этой статье я постаралась подробно расписать принципы, на основании которых нужно принимать решение при комплектации команды. Добиться же идеального звучания именно вашей «рок-группы» сможете только вы сами.
