На IT Ring от Parimatch Tech топ-специалисты поспорили о будущем «ручных» тестировщиков и вот к чему пришли

Три раунда. Шесть спикеров. В центре зала – боксерский ринг. Так в Киеве прошла первая конференция IT Ring, организатор которой Parimatch Tech.

Свет софитов, ведущий объявляет в подвесной микрофон имена участников, а удар в гонг дает понять: время выступления вышло. IT-специалисты сражаются не за победный пояс, а за свою точку зрения, и вместо кулаков у них аргументы. Зрители – активные участники, которые голосуют онлайн за того, чьи доводы убедительнее.

Предмет спора – будущее IT-профессий. В партнерском материале редакция MC.today собрала самые интересные мысли первой конференции, где IT-бойцы выясняли, какие тестировщики нужны компаниям и должен ли управляющий проектами разбираться в программировании. А 9 июня на IT Ring будут обсуждать профессию DevOps. Это специалисты, которые отвечают за корректную работу IT-продукта на всех устройствах.

Ручное тестирование или автоматизированное: за чем будущее

О каких профессиях речь

Automation QA Engineer – тестировщик-автоматизатор, который пишет код для проверки корректной работы программы. Средняя зарплата – $2 тыс., по данным DOU на зиму 2021 года

Manual QA Engineer– тестировщик, который проверяет программы на ошибки вручную, имитируя шаги пользователя. Средняя зарплата – $1,3 тыс.

Я уже десять лет слышу, что мануальное тестирование умирает. Но почему-то рынок вакансий с этим не согласен: по запросу «тестировщик»на портале Dou.ua находим приблизительно 900 предложений, из которых 300 для автоматизаторов и 250 для «мануальщиков». А кто остальные 350? Вряд ли автоматизаторы.

Ручное тестирование выгоднее тем, кто только заходит в эту профессию, – не нужно разбираться в коде на старте. Это выгодно и компаниям с ограниченными бюджетами. Работа junior QA engineer, то есть младшего «ручного» тестировщика, стоит в три-четыре раза дешевле, чем автоматизатора с опытом – $300–500 против $1500–2000. Младший «мануал» может сразу приносить пользу, а автоматизатору для этого нужно вырасти хотя бы до среднего уровня. Качество продукта, если вы имеете дело с хорошим «ручным» тестировщиком, не страдает.

Многое зависит от проекта. Если мы хотим выпускать обновления каждые 15 минут, как Booking.com, то придется нанять автоматизаторов. Но если это небольшой проект, так много обновлений не будет. Да и чтобы создать код, который позволит написать те же автотесты, нужно два-три месяца. А за это время небольшой проект уже отдадут заказчику.

Если команда занимается проектом, где еще не утвержден даже дизайн, автоматизатору с каждым изменением в продукте придется переписывать тесты.

Есть предубеждение, будто «ручные» тестировщики не очень умные. Мол, автоматизаторы крутые, а вы, «ручные», клацайте. Это ошибка. Автоматизатор не может написать основу для автотестов, не вчитываясь в код продукта. А разбираться в чужом коде сложно. «Ручной» тестировщик в код не полезет – он с ним не работает. Такой специалист пойдет и спросит программиста, как все устроено и на что обратить внимание. 15–20 минут – и мануальный тестировщик решит проблему, пока автоматизатор все еще будет разбираться в коде.

Автоматизированное тестирование стоит дороже. Но с ним команда быстрее понимает, что пошло не так – информацию о состоянии продукта можно получить за 10–15 минут.

У каждого теста, который создает тестировщик-автоматизатор, есть свое название – в нем кратко отражается суть: что проверяем. Когда запускается проверка, сразу понятно, что тестируем и по какому сценарию. Есть два вида сценариев. Позитивный – когда проверяют, как система справляется с тем, для чего создана. Негативный – выясняют, как она отреагирует на нетипичные для нее запросы. Если нужно, тест не только покажет, что именно не работает, но и добавит видеозапись, снимки экрана. Получить информацию можно, как только разработчик загрузит изменения на сервер программы. Самого тестировщика вообще не нужно подключать к процессу.

Без автотестов вы не сможете сразу проверить, корректно ли работает программа после обновления. Есть риск, что вы обнаружите ошибку уже после выхода продукта.

Допустим, вы с нуля создали сервис и планируете перепроверять его программный код вручную несколько раз. Не лучше ли сразу автоматизировать проверку? Чем дольше тянете с тем, чтобы нанять автоматизатора, тем больше времени он потом потратит на решение накопившихся задач. Вы будете платить и за ручное тестирование, и за авто, а значит, терять деньги.

Может показаться, что маленьким проектам, стартапам автоматизация не нужна. Мол, дорого стоит, к тому же на написание тестовой программы уйдет пара месяцев. Но какой стартап не хочет стать корпорацией? Компании, которые сфокусированы на быстром старте, будут двигаться в сторону автоматизации, сколько бы она ни стоила. Когда проект переходит в фазу MVP (минимально жизнеспособный продукт. – Прим. ред.), как правило, автотесты уже написаны, поэтому можно быстро улучшать программу.

Я не согласен с теми, кто говорит, что на старте проекта должен работать только мануальный тестировщик, что автоматизатору нечем будет заняться. Это не так.

Плох тот автоматизатор, который не хочет ничего делать руками. Ключевое в названии профессии – именно «тестировщик». А это значит, что он по умолчанию должен уметь проверять проектную документацию, искать в ней неточности и противоречия. Иначе может случиться так, что продукт придется частично переделывать. Например, если требования, указанные в бизнес-анализе, будут противоречить техническому дизайну.

В течение пяти лет мануальный тестировщик в команде станет скорее исключением, чем правилом. В бизнесе выигрывает тот, кто быстрее выдает новинку и не теряет в качестве. Поэтому все автоматизируется.

Управленец или технарь: что должен уметь тест-менеджер

О какой профессии речь

Test Manager – руководитель команды тестировщиков, отвечающий за успех и эффективность работ по тестированию. Средняя зарплата – $3,5 тыс., по данным DOU на зиму 2021 года

Тест-менеджер должен не просто спроектировать план работы, сделать его эффективным, но и донести до заказчика, в чем ценность тестирования для бизнеса, когда и как она окупится.

Клиенту понятно, за что он платит программистам: он видит приложение и радуется красивой зеленой кнопке. А результат работы тестировщиков для него выглядит как список ошибок в Jira (программное обеспечение для управления проектами. – Прим. ред.). Именно тест-менеджер объясняет бизнесу, что стоит за этим списком.

Представьте, что на работу нанимают проектного менеджера, а когда выясняется, что он не умеет кодить, его выгоняют. Странная ситуация, ведь код не его компетенция. Но почему-то, когда вспоминают о тест-менеджерах, представляют человека, который силен и в управлении, и в коде.

У тест-менеджера, сильного и в управлении, и в технологиях, и в лидерстве должен быть, пожалуй, двадцатилетний опыт работы. Такие специалисты – редкие звери, единороги, которых сложно найти и еще сложнее нанять. Если же приходит человек с пятилетним опытом и заявляет, что он может все, вероятно, что знания его поверхностные.

Цель тест-менеджера – организовать эффективный процесс тестирования. Как он делает это? Во-первых, определяет, какие нужны инструменты, фреймворки (каркас программной системы. – Прим. ред.). Во-вторых, помогает команде получить нужные технические знания. В-третьих, разрабатывает стратегию и тестовый план. В-четвертых, оценивает безопасность, производительность (объем операций и скорость их выполнения. – Прим. ред.) и другие нефункциональные характеристики качества продукта.

Тест-менеджеру без технических навыков сложно решить, на чем команде нужно сфокусироваться. Допустим, он приходит в проект, где работают над автоматизацией тестировки, и убежден, что сможет двигать ее дальше. Но вот инженер, который отвечает за техническое видение и развитие проекта, говорит, что уже год команда автоматизирует процесс, но результатов нет. А человек, ответственный за эту автоматизацию, уверяет, что технологии работают и проблема не в них. Как этот вопрос решит менеджер, который не разбирается в технической экспертизе?

Выходит, технические навыки нужны тест-менеджеру, чтобы он мог самостоятельно оценивать технические нюансы разработки, понятно формулировать задачу для команды и оценивать результат работ.