Опытом делится Сергей Мурашов, ведущий тестировщик в ITQ Group.

Давным-давно, до времен IT-бума в России, когда слова Agile, DevOps, Scrum и ему подобные скорее воспринимались чем-то непонятным и одиозным — сродни новоязу. Когда разработчик, подобно богине Дурге, делал работу за себя и за того парня, свое скромное существование влачил непритязательный тестировщик.

Но времена шли, поколения менялись, а вместе с тем менялся и рынок. А рынок, как известно, диктует условия труда. И вот уже программист — не восьмирукое божество, которое выполняет функции целой фабрики. Роль «‎одного незаменимого» осторожно уходит за кулисы, а идеология IT вместе с подходом к разработке меняются. Пусть и не на 180 градусов, но всё же уходят куда-то в сторону, уступая место новой философии. И имя этой философии — КОМАНДА.

Теперь тестировщик становится не просто monkey cliker’ом, а инженером по обеспечению качества, как бы громко это ни звучало. Конкуренция на рынке ПО, требования к выпускаемой продукции, популярность микросервисной архитектуры,  декомпозиция всего и вся буквально вынудили российские компании оглянуться на западный подход к разработке ПО.

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

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

Тестировщик (не) должен быть проактивен.

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

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

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

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

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

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

Тестировщик (не) отвечает за проект.

Описанная выше ситуация актуальна для многих стартапов или аутсорсных команд. Представим её логичное продолжение. К вам приходит РП и недовольным голосом спрашивает:

Почему нужно так много времени на тестирование, и по какой причине оно еще не начато?

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

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

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

Карикатурный пример, не имеющий ничего общего с реальностью — объявит читатель и будет наполовину прав. Настолько сильную концентрацию несправедливости вы вряд ли встретите на реальном проекте. С другой стороны, с этими проблемами по одиночке вы столкнетесь не раз. Что делать в этой ситуации? Выход один - подстилать себе солому самому.

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

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

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

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

• Чувствуете, что разработка захлёбывается в задачах, но молчит в тряпочку — обозначайте это на статусе.

• Понимаете, что техническая документация не соответствует разработке — помечайте все моменты и выносите их на обсуждение.

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

Многие подумают, что такой человек в команде занимается не своими обязанностями, пытается изобразить что-то непонятное и вообще… Однако, все вышеперечисленное есть ни что иное, как роль QA в команде (не путать с QC). И это нечто большее, чем «два притопа, три прихлопа». Ведь свободную неделю, в которую пишется общая документация, можно потратить на подготовку своих тест-кейсов, чётко понимая, что через 2 недели они опять поменяются. Или же можно заняться налаживанием коммуникаций, сделав часть работы за аналитиков и разработчиков, получив при этом бесценный опыт.

Тут, конечно же, стоит добавить два больших «‎НО».

Если у вас есть лид в команде, то все шишки полетят на него, а не на вас. Но ведь мы хотим развиваться профессионально и достичь карьерного роста? Значит, рано или поздно придется брать ответственность на себя. С другой стороны, если вы одинокий волк, забредший по непонятным причинам к такому же стаду, только переодетому в овец (будем надеется, что метафора всем понятна), то отдуваться придется по полной.

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

Тестировщик в команде (не) всегда один.

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

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

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

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

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

Тестировщик (не) психолог и оратор.

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

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

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

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

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

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

• Узнали, что разработка сдвигает планы по выкладке доработки на стенд? Обозначайте сроки сдвига начала тестирования и риски.

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

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

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

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

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

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

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

• Апеллируйте к возможным ошибкам на проде;

• К пошедшему под откос первоначальному плану;

• К обозначенному ранее сроку тестирования и опасности выпуска задачи в релиз;

• Предупреждайте об огромном количестве времени, которое на все это уйдет.

• А затем непринужденно переходите к путям решения, к рискам и возможным альтернативам.

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

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

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

Тестировщик (не) умеет давать оценку.

Еще одна задача, с которой вы столкнетесь (или уже столкнулись) – оценка ваших и чужих трудозатрат. С этим неизбежно работает каждый лид и не только. Первый и один из главных навыков профессионала в любой сфере – оценка своих трудозатрат. И, казалось бы, что может быть проще, чем прикинуть человеко-часы по функциональному тестированию?

Есть 10 форм. Если на 1 форму мы тратим 3 дня, значит, в итоге потратим 30 человеко-дней.

Спешу огорчить – это так не работает. Рассмотрим на примере. Вы даёте те самые 3 дня на форму, а разработчик закладывает по 2 дня на каждую. Тайминг объясняется простотой реализации и тем, что есть наработки с предыдущих форм. Сказано — сделано!

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

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

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

Но вот незадача. Вечером того же дня к вам приходит РП и спрашивает:

• Учтено ли время на исправление дефектов?

• Написана ли тестовая документация для пользователей с подготовкой тестовых данных?

• Заложено ли проведение обязательного регресса на дополнительном стенде?

Выпучив глаза, вы понимаете, что первый пункт вы, допустим, закладывали, но о двух других, слышите впервые. Как не допустить такой ситуации? Задавать правильные вопросы.

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

• Общий процесс разработки ПО;

• ЖЦ релиза и из чего он состоит;

• Возможность тестирования на заглушках;

• Подготовка тестовых данных пользователя;

• Процесс сопровождения пользовательского тестирования;

• Необходимость нагрузочного тестирования, автоматизации и регресса.

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

Разработка часто оценивает свое время без учета накладок. Когда они случаются, несут ответственность именно те, кто стоит с правого края цепочки разработки программного продукта.

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

Можно ли избежать такой ситуации? Разумеется — нет. Вы ведь не Господь Бог, чтобы  отвечать за действия всей проектной команды, неожиданные хотелки заказчиков  и менеджмент со скупыми коммуникациями.

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

Главное, что стоит понять сразу – оценка и риски неразрывно идут друг за другом. Этап тестирования является фактически финишной чертой перед выпуском продукта в продакшн, а на тестировщиках лежит огромная ответственность за то, чтобы релиз прошел в соответствии с ожиданиями заказчика. Об этом каждому начинающему и продолжающему QA-специалисту нужно помнить всегда.

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

Желаю вам успехов в тестировании!