В странах бывшего СССР сложилось вполне определённое отношение к тестировщику как к роли второго плана:
- На роль тестировщика готовы брать кого угодно, кто умеет достаточно уверенно нажимать на кнопочки.
- Тестировщики редко участвуют в судьбе проекта, принимают решения по требованиям и срокам.
- Тестировщиков стараются подключать как можно позже, когда надо «покликать» и «поискать ошибки».
- За исключением небольшого числа продуктовых компаний, большинство работодателей предлагают тестировщикам зарплату в 1,5-2 раза ниже, чем разработчикам.
Почему такое происходит, вполне понятно: мало кто вживую встречал квалифицированных тестировщиков, тестировщики не делают полезный результат (продукт не пишут), да и вообще у нас принято экономить на всём, на чём только получается. Интересен другой вопрос: что получается благодаря такому подходу? Рассмотрим на примерах.
Давайте экономить на зарплате
Здесь всё понятно. Чтобы проект приносил больше прибыли, его надо лучше продавать и сокращать производственные затраты. ОК, давайте наймём недорогого специалиста по тестированию (чаще всего, студента или свежего выпускника), который будет тыкать на кнопки и регистрировать ошибки в систему. Когда объёмы работы вырастут, и он перестанет справляться – наймём второго, и постепенно выстроим целый отдел тестирования. На первый взгляд всё кажется вполне хорошо, если бы не некоторые мелочи:
- Неквалифицированные тестировщики заводят баги без детального анализа. Такие ошибки сложно локализовывать и исправлять. Допустим, на каждую из 50 заводимых в неделю ошибок разработчики в среднем тратят лишние 15 минут на анализ. Сущие незаметные мелочи! Всего-то, 600 человекочасов разработчиков в год – или 3,5 человекомесяца!
- Со временем, когда у вас разрастается объём поддерживаемого кода, вам требуется регулярное регрессионное тестирование, дабы проверить, что ничего не сломалось. Ваши студенты-тестировщики целенаправленно и методично выполняют одни и те же тесты от релиза к релизу, изредка находя ошибки (привет, эффект пестицида!) Когда кому-то в голову (чаще всего, РМ’у) придёт идея об автоматизации, эти ребята напишут вам несколько сотен скриптов копипастом – и потом, вместо ручного тестирования, будут каждый релиз обновлять автотесты. В какой-то момент, чтобы всё это счастье поддерживать, вам потребуется больше тестировщиков: что-то между много и очень много. А много – это всегда дорого.
- В конце концов, несмотря на рост численности тестировщиков, вы будете сталкиваться с ошибками на продуктивной среде. Ругаться с пользователями, терять доверие, тратить своё время. В общем, вы продолжите тратить избыточные ресурсы.
И в какой-то момент, рано или поздно, все РМ’ы приходят к пониманию, что тестировщики должны быть достаточно квалифицированными, и находят себе в команду ребят посильнее (которые, правда, уже не всегда могут наверстать упущенное и расхлебать весь этот багаж бардака, который для них накопили). Тем не менее появляются нормальные тестировщики, которые и тесты адекватно проектируют, и фреймворк автоматизации готовят подходящий. И всё хорошо, только ведь тестировщики — это всего лишь тестировщики. Поэтому,
Тестировщиков не надо пускать к продукту слишком рано
«Вот сейчас мы напишем достойную тестирования версию, и им останется только проверить, что всё хорошо, и завести найденные мелочи!» Здесь, почему-то, опять начинаются проблемы:
- Поздно подключаясь к процессу, тестировщики не успевают вникнуть в среду. Не хватает понимания бизнес-сценариев, среды работы пользователей, и причин принятия многих проектных, архитектурных и дизайнерских решений. Примерно на этом этапе начинаются «тёрки» из-за разного видения, как и что должно быть реализовано, т. к. тестировщикам либо не хватает знаний, либо у них другое видение, но они не участвовали в разработке проектных решений. Поздравляю, много изменилось: у вас опять невысококачественное тестирование, взаимное недовольство, нехватка времени на серьёзные изменения в продукте.
- Проведя долгое время на вашем проекте (что многие адекватные тестировщики просто не будут делать в таких условиях), тестеры начинают понимать среду значительно лучше. Шансы успеха растут, если они участвуют в разработке требований и общении с клиентами. Но вы продолжаете подключать тестирование на последних этапах, потому что так принято? Скорее всего, вас ждёт одно из двух: при нехватке времени на тестирование будут пропускаться ошибки. При возможности подвинуть сроки вам просто придётся вносить слишком много серьёзных изменений. Конечно, это всего лишь багфикс, это нормально… Рано или поздно вам придется задать себе простой, но важный вопрос: «А как его можно было избежать, тем более на последних стадиях релиза?»
Окей, умные люди должны учиться на ошибках, хотя бы на своих. Глядя на всё это счастье, вы понимаете, что что-то не так. Вы подключаете тестировщиков к проекту на ранних стадиях, они готовят модульные тесты до готовности интеграционного решения, они вместе с командой обсуждают принимаемые решения, и в жаркую предрелизную пору вы не тратите время на пустые обсуждения и внесение запоздалых изменений в продукт. И всё могло бы быть хорошо, если бы не очередное «но»:
Тестировщики не могут влиять на качество продукта
При наличии должных сил и желаний, тестировщики могут его оценить. При достатке коммуникативных навыков – обосновать важность тех или иных изменений. Но повлиять на результат?
Медицине пока не известны случаи, чтобы аппарат УЗИ что-либо вылечил, а тестирование – это лишь диагностика. И на этом этапе, если в вашей команде тестирования ещё есть достаточно грамотные и незабитые сотрудники, начинаются новые «тёрки»:
- Для более грамотной автоматизации в продукте нужны легко поддерживаемые локаторы — пфффф! «Опять тратить лишнее время на тестирование!» — скажет РМ и отложит задачу до тех никогда-не-наступающих-времён-когда-команде-будет-нечего-делать.
- Чтобы точнее оценивать тестовое покрытие и его слабые зоны, нам нужны детализированные декомпозированные требования — пфффф! «Хватит разводить бюрократию, у нас аджайл!»
- Нам нужно лучше понимать пользователей и привлекать целевую аудиторию на этапе проработки бизнес-сценариев, оценивать юзабилити — пффффф! «Это отложит релиз на 2 недели, лучше потом переделаем по отзывам пользователей!»
Постепенно, все хорошие начинания улетают в трубу, и вместо обеспечения качества максимум, что могут делать тестировщики, – это своевременно сообщать о найденных ошибках. Декларирующие потребность в повышении качества РМ’ы на практике не готовы в него инвестировать, и наступает потихоньку коллапс. Поддержка старого функционала стоит всё больше и больше.
Разницу в распределении ресурсов команды во времени в двух подходах я постаралась изобразить на схеме:
По клику на картинку откроется полная версия.
И чем раньше вы начинаете вкладывать ресурсы в обеспечение качества и работоспособных процессов, тем больше, в конечном счёте, у вас остаётся на разработку нового функционала! Как бы неожиданно это ни звучало.
Выводы
Срезюмирую:
- Разработчик автотестов – это разработчик. Тест-аналитик – это аналитик. Если вы набираете людей в тестирование, предъявляя к ним меньше квалификационных требований, чем к разработчикам и аналитикам, то постепенно вы роете яму всей своей команде.
- Тестирование – это часть разработки, а не следующий за ней этап.
- В тестировании и обеспечении качества не могут участвовать только тестировщики. Продукт и процесс должны способствовать возможности тестирования и улучшений, и если вы не вкладываетесь в это с самого начала, то потом приходится платить значительно больше – на сложностях с поддержкой, внесении изменений, тестировании и общении с клиентами.
Всё ещё редко, но в ex-СССР начинают встречаться толковые процессы обеспечения качества. А вы готовы менять что-то в лучшую сторону?
