Боль тестировщика: с какими проблемами сталкиваются QA‑инженеры

За последние двадцать лет программист перестал быть восьмируким божеством, которое выполняет функции целой фабрики. Роль «‎одного незаменимого» ушла за кулисы. Ны рынке IT появилось множество специализаций, а старые профессии были модифицированы и потребовали освоения новых навыков. Теперь тестировщик не просто monkey cliсker. Он стал QA-инженером — специалистом по обеспечению качества. Такой сотрудник занимается проверкой продукта на всех этапах работы — от составления документации до финального релиза.

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

Советы будут особенно актуальны для тестировщиков, которые трудятся в стартапах и аутсорсных командах — мой опыт получен именно на таких проектах. В этой статье поговорим:

• о неприятном сценарии, который может возникнуть в работе QA-инженера;
• о том, почему в команде иногда придётся брать на себя роль проджект-менеджера;
• как не стать крайним, если проект отстаёт по срокам;
• почему тестировщику иногда важно побыть оратором и даже психологом;
• как рассчитать сроки реализации проекта, чтобы снизить риск срыва дедлайнов.

Сценарий, к которому должен быть готов тестировщик

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

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

«Хорошо», — думаете вы и, сделав всё от вас зависящее, с нетерпением ждёте следующего спринта. Пока, наконец, программист не выложит вам первую сборку на тестовый стенд, и вы не начнёте проходить ранее написанные сценарии.

Проходит ещё две недели, и вы понимаете, что тест-кейсы уже не актуальны — требования поменялись. Разработчик внешнего сервиса полностью изменил API, и вообще — ждать выкладки на UAT не стоит.

Читайте также:

Что такое API и как он работает

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

Всё чаще вы начинаете слышать слово «‎тестирование», хотя эстафетную палочку вам ещё не передали. И тут вы понимаете: что-то пошло не так. Конечно, вы знали это ещё месяцем ранее, когда руководитель проекта вдруг разрешил разработчикам не писать unit-тесты. И сказал, что пользовательское тестирование вы будете проводить уже на следующей неделе, даже без проведения smoke. Но именно сейчас вы поняли, что совершили промах. Но где именно?

Ведь вы обозначали риски, вовремя говорили о необходимости регресса и о доработках кейсов, которые понадобятся в связи с изменением документации. И всё равно тень недовольства бросилась на вас. Давайте разбираться почему.

Почему иногда придётся быть проджектом

Представим логичное продолжение нашей истории. К вам приходит руководитель проекта и недовольным голосом спрашивает: «Почему нужно так много времени на тестирование, и по какой причине оно ещё не начато?»

Вы делаете круглые глаза и говорите, что ещё неделю назад не было даже готовой документации. А разработка не загрузила итоговую сборку на стенд.

Руководитель отвечает, что технолог Клара уже давным-давно выложила итоговый файл спецификации, а разработчик Петя ещё две недели назад сообщил вам о необходимости тестировать всю интеграцию через mock-сервисы и снифферы, не дожидаясь выкладки на стенд.

Пытаясь оправдаться, вы распинаетесь про важность тестирования E2E-кейсов, и говорите что вы вообще такую информацию не получали. На что руководитель заявляет: «Промах твой, так как ты недосмотрел за проектом и не довёл его до логического завершения. А в качестве кнута вот тебе минус 50% премии». Занавес опустился, в зале тишина…

«Карикатурный пример и не имеет ничего общего с реальностью», — скажет читатель и будет наполовину прав. Настолько сильную концентрацию несправедливости вы вряд ли встретите на реальном проекте. С другой стороны, с этими проблемами по отдельности вы столкнётесь не раз. Что делать в этой ситуации? Действовать самостоятельно.

Побуду адвокатом дьявола и скажу, что начальник выше прав. Его не интересуют ваше мнение о правильности тестирования и применении техник дизайна. Также его не волнует отсутствие опыта в создании mосk-серверов, незнание снифферов или методологии разработки ПО по V-модели. Его интересует лишь результат, а он не достигнут.

На вашем проекте может потребоваться даже нагрузка или автоматизация. И вы узнаете об этом в самый последний момент. Как и о том, что демо должны будете проводить именно вы. И будьте уверены: ни руководитель проекта, ни кто-то другой вам об этом не скажет.

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

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

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

Тут, конечно же, стоит добавить два больших «‎НО». Если у вас есть лид в команде, то все шишки полетят на него, а не на вас. Но ведь мы хотим вырасти профессионально и достичь карьерного роста? Значит, рано или поздно придётся брать ответственность на себя.

Ну и второй момент. Руководитель проекта всё равно виноват так же, как и вы. Даже если вы оба не виноваты. Бессмыслица? А вот и нет. Руководитель выбирает себе сотрудника, ответственного за проект, который будет ведущей скрипкой всего тестирования. Соответственно, если ведущий инженер не тянет позицию, значит, сплоховал именно начальник — выбрал слабое звено. Хотя, стоит признать, что иногда выбор и вовсе отсутствует.

Отслеживать работу коллег — важно

Но вернёмся к нашим нехорошим коллегам. Выдуманным аналитику Кларе и разработчику Пете, которые взяли да и свалили всю вину на нас. Можно ли винить их за это? Наверное, можно. Но так уж ли они неправы в том, как поступили?

Ведь первая сказала, что документация была готова ещё неделю назад, а второй — что нужно всё это дело тестировать на моках, пусть даже и шёпотом. Суть в том, что вам нечем крыть. Вы можете апеллировать к неправильности подходов к тестированию, разработке ПО в целом и к нечестности ваших коллег. Однако все ваши призывы без подтверждения будут не более чем сотрясанием воздуха.

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

Завтра на проект придёт новый аналитик и попытается переложить всю вину на вас, но во второй раз этот фокус провернуть не удастся. Просто потому, что у вас на руках будет доказательная база — спецификация неделю назад не была готова. И вы на просьбу получить вменяемые сроки о готовности получили в письме «будет готово, когда будет готово».

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

Иногда нужно быть оратором и даже психологом

Мы уже поняли, что тестировщик должен быть проактивным, немного параноиком и обладать качествами лидера. Или хотя бы к ним стремиться. Дальше — больше. Для следующего примера придётся обратиться к игровому опыту читателя — в жанре классических RPG. Обычно в подобного рода играх у персонажа можно улучшать различные характеристики. В реальности такой характеристикой будет красноречие.

А зачем инженеру по обеспечению качества красиво говорить? Возможно, десять лет назад такой вопрос был бы логичен. Но не теперь, когда появилось новомодное словосочетание soft skills.

Agile привнёс не только гибкую модель разработки, но и ежедневные совещания и конференции, которые требуют коммуникативных навыков. Если вы услышите где-то шутку, что разработчик днём разговаривает, а ночью работает — знайте, это не шутка.

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

Нужно определиться сразу: любая аудио-/видеоконференция есть не что иное, как поле битвы. Иногда оно может напоминать непринуждённый ежедневный статус, иногда — обсуждение проблемы или фичи, ещё реже — разбор полётов и пути решения проблем. Но суть игры при этом не меняется: вам нужно оставить последнее слово за собой.

Узнали, что разработка сдвигает планы по выкладке доработки на стенд? Обозначаем сроки сдвига начала тестирования и риски. Узнали, что заказчик захотел новую фичу, никому об этом не сообщив? Разработка возмущена. Но вашему возмущению нет предела. Стуча кулаком по столу, требуйте прислать письмо, чтобы зафиксировать новые требования.

Руководитель проекта говорит, что можно тестировать функциональность без фронтенда? Вы тут же парируете, что само API ещё даже не описано.

Только представьте реакцию, если QA начнёт учить разработчика писать код или будет управлять проектом за начальника. Чтобы всё это объяснить, завернуть в красивую обёртку и никого не обидеть, и нужно обладать пресловутыми soft skills.

Рассмотрим ещё одну ситуацию. Вы узнаёте, что необходимо пойти в релиз к определённому сроку. И у вас всё шло по плану до тех пор, пока разработчик не уволился, а на его место не пришёл другой. И вот проблема за проблемой, и вы теряете месяц, который нужен как воздух. И вам тут же хотят предложить альтернативу решения проблемы.

Вы выслушиваете её и где-то глубоко в сознании одобряете, но… нет, не соглашаетесь с ней. Скажите сейчас «‎ок», а завтра получите недовольство от вышестоящих, что сами на это подписались. А не подписаться вы уже не сможете. Парадокс, однако.

Зато вы можете поступить как бывалый торговец и произвести сделку наилучшим для вас образом. В психологии есть такой приём, называется «‎От большего к меньшему». Апеллируйте к возможным ошибкам на проде, к первоначальному плану, который пошёл под откос, к обозначенному ранее сроку тестирования и опасности выпуска задачи в релиз. Говорите об огромном количестве времени, которое на всё это уйдёт. А затем непринуждённо переходите к путям решения, к рискам и тем самым альтернативам.

Появляется резонный вопрос. В чём отличие от того, что предложил сам руководитель проекта пятью минутами ранее? Как минимум в том, что вы постелили себе немного соломы. И теперь, в случае обнаружения багов на проде (а они будут, это неизбежно — вспоминаем один из главных принципов тестирования), вы произнесёте своё долгожданное «‎я же говорил». И упрекнуть вас будет не за что. Ведь вы не забудете после обсуждения задокументировать всё это дело письмом.

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