Home

Автор: Эдуардо Фишер (Eduardo Fischer)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Не изолируйтесь: общайтесь чаще

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

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

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

Не будьте спасателем: убедитесь, что у всех есть спасжилет

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

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

Используйте автотесты… с умом.

Автоматизированное тестирование – наверное, наиболее недооцененная часть технической работы. Обсуждения, использовать JavaScript или Python, AWS или GCP, MySQL или Postgre, возникают очень часто и могут занимать часы и дни – но аналогичные обсуждения тест-фреймворков и инструментария намного короче. Если ваша команда не уделяет особого внимания вопросу выбора подходящих для тестирования инструментов, это может создать трудный в выплате технический долг.

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

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

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

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

Вы не можете проверить все: следите за временем

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

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

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

Дополнительная литература:

Amber Pollack-Berti, Are we there yet? Driving quality & tackling automation debt

John Ferguson Smart, A Test Pyramid Heresy: a fresh look at test automation strategies

Обсудить в форуме