Виммельбух, 3, перетяжка
Виммельбух, 3, перетяжка
Виммельбух, 3, перетяжка

Полоса препятствий. Как тестировщики стали незаменимой частью для бизнеса

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

5К открытий5К показов

За последние несколько лет тестирование прошло настоящую полосу препятствий на пути к тому, чтобы стать незаменимой частью для бизнеса. Мало кто понимал ценность этой профессии, а это сказывалось на ее востребованности в компаниях, да и на отношении к ней.

Я начинал как тестировщик, а потом стартанул свое агентство по аутсорс тестированию «Кавычки». И это было более 10 лет назад. За это время я на своем бизнесе увидел, как изменилось отношение к тестировщикам. А компании, которые никогда не рассматривали работу с тестировщиками, начали активно прибегать к услугам по тестированию. Расскажу, какие тренды повлияли на это, кто такие тестировщики сейчас, и кому они действительно нужны.

Полоса препятствий

Почему никто не понимал ценность этой профессии, и откуда появилась полоса препятствий:

  • Во-первых, еще лет десять назад рабочий день штатного тестировщика был таким: 90% — ждать разработчиков и ничего не делать, а 10% — тестировать и снова ждать. Такому сотруднику не всегда можно найти занятие на весь день, особенно если компания развивает какой-то конкретный продукт. Поэтому складывалось ощущение, что тестировщик — это человек, который ничего не делает.
  • Во-вторых, из-за первого пункта многие не понимали, зачем нужен тестировщик. Разработчики же могут сами все проверить — если можно сэкономить, то зачем платить.
  • В-третьих, работала известная всем баллада о том, как разработчики недолюбливают тестировщиков. Да и сейчас это тоже актуально, если обе стороны не умеют договариваться и налаживать процессы взаимодействия. Тестировщики находят баги в коде и постоянно спорят с командой разработки, потому что выпустить продукт с ошибками — хуже, чем не выпустить его. В некоторых случаях критичные баги могут означать глобальные изменения. А это сорванные дедлайны сдачи проекта. Такое, кстати, нередко случается, когда тестировщик получает уже конечный продукт, а не включается в процесс с самого начала.

Когда все начало меняться

Раньше тестировщики нужны были только разработчикам и продуктовым командам —  и то не всем. Во многих даже крупных компаниях тестированием занимались и менеджмент, и разработка без участия хотя бы одного тестировщика. Логика у них была такая: зачем  платить деньги и брать человека в штат, когда мы можем сделать это сами: сэкономим и продукт глубже знаем, не будем тратить время на погружение и проверки. Сейчас понимание  важности тестирования на проекте меняется. Продукты развиваются все быстрее, потребители продукта становятся требовательнее к качеству. А для того, чтобы обеспечить продукту качество, нужно детально сфокусироваться на нем. И как итог — растет востребованность тестировщиков.

Аутсорс

В условиях быстрого роста технологий и конкуренции для многих стало понятно, что за определенные деньги можно доверить работу по тестированию кому-то другому. А самим тратить это время на вещи, которые развивают бизнес и двигают его вперед. Таким решением стал аутсорс. Это оказалось удобно, например, специалист на аутсорсе может работать несколько часов в день, закрывая задачи по тестированию и обеспечению качества. При этом ему нужно платить только за часы, а не полноценную з/п.

Ощутимо это понимание изменилось где-то года 3-4 назад — именно тогда к нам стали приходить стартапы из Америки, Китая и Австралии. Сейчас уже многие стартапы закладывают в разработку тестирование. Потому что понимают, что для тестирования необходимо уделять достаточное количество времени. А тестировщик на аутсорсе эффективнее, профессиональнее и дешевле, чем в штате. К тому же, команды тестирования на аутсорсе имеют большой бэкграунд работы с разными проектами, их кругозор шире, и они могут глобальнее посмотреть на продукт.

Развитие собственных IT-продуктов

То же самое происходит в крупных компаниях. Сейчас сложно найти компанию, которая не занимается собственным IT-продуктом. Для этого набирается команда разработки — чаще всего инхаус. При этом задачи по тестированию, как правило, лежат на разработчиках. Но в силу того, что IT развивается быстро — команда разработки начинает расти, а продукт непрерывно улучшаться. И теперь времени на проверку требуется гораздо больше. Ни разработчики, ни менеджмент уже не справляются с этой задачей, поэтому усиливается тенденция, когда компании нанимают тестировщиков. В том числе и на аутсорс. Это могут быть отдельные дополнительные единицы тестировщиков, в помощь к штатным; целая аутсорс команда по тестированию или даже QA лид, который настраивает процессы работы между командами. Так разработчики могут сфокусироваться на продукте, а тестировщики на качестве этого продукта, менеджмент на планах, а топ-менеджмент на бизнесе.

Тестировщики становятся частью команды

Сейчас тестировщики —  это уже не обособленные единицы. Они становятся частью команды и частью продукта. И это обязательное условие для того, чтобы качество продукта не пострадало. Раньше многие думали, что работа тестировщика начинается тогда, когда свою работу закончил разработчик. К сожалению, и сейчас это мнение по прежнему распространено. Но даже по своему опыту мы видим, что во многих крупных компаниях начинаются подвижки. Чем раньше тестировщик начнет свою работу и чем раньше его допустят к продукту, тем эффективнее пойдет процесс для всей команды. По сути, это анализ продукта: кому он нужен, кто будут пользователи, как они будут с этим взаимодействовать т.д. Да, это работа аналитика. Но если на этапе аналитики подключить тестировщика, то это лучше сказывается на качестве продукта, который он будет тестировать.

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

Чем раньше тестировщик начнет погружаться, тем шире у него будет знание продукта. И это еще одно важное понимание, которое глобально меняет отношение к тестировщикам. Тестировщик нужен не столько разработке, сколько бизнесу. Потому что важно понять — будет ли функциональность приносить прибыль, будут ли довольны им клиенты. Это история не про найти баг и отчитаться о нем. Это про то, как помочь бизнесу заработать.

Тестировщик, а куда дальше?

Расширилась и область движения тестировщиков по карьерной лестнице. Как это выглядит:

  • тестировщик;
  • старший тестировщик (когда есть команда);
  • QA ( когда несколько команд);
  • директор по качеству (его инструмент — это процессы и люди).

Тестировщик может вырасти в директора по качеству и отвечать не за функциональную составляющую продукта, а за качество продукта целиком. А это процессы между тестировщиками и разработчиками, дизайнерами и менеджерами. Это процессы между потребителем и продуктом. Тестировщик налаживает процессы внутри компании и делает их максимально эффективными. Его задачи могут распространяться на всю компанию, а не только на IT. Это могут быть даже процессы между бухгалтерией и менеджментом.

Вместо вывода

Значимость тестировщиков на проекте изменилась. Сейчас это эксперты, которые понимают бизнес логику продукта. Они смотрят не только на ошибки, а на качество и пользу продукта для бизнеса и его клиентов. Это люди, которые налаживают процессы как внутри рабочей группы, так и в компании в целом. Во многом этому поспособствовал аутсорс — тестировщики стали выгоднее в таком формате. К тому же, у тестировщиков на аутсорсе большой опыт, что тоже является плюсом для компаний. Еще одним триггером стала быстро растущая роль IT-продуктов в компаниях. Логичнее и эффективнее разделить обязанности между разработчиками и тестировщиками — так процесс идет быстрее и качественнее. И что очень важно, меняется понимание, кому действительно нужны тестировщики. Они нужны бизнесу. Тестировщики смотрят на продукт глазами пользователя. Это ценный опыт, благодаря которому, они двигаются в сторону понимания, какой функционал будет прибыльным для бизнеса.

Следите за новыми постами
Следите за новыми постами по любимым темам
5К открытий5К показов