Введение
Вы когда-нибудь участвовали в проекте разработки ПО, в котором отсутствовали жизненно необходимые меры по обеспечению качества? Вы в этом не одиноки. Такое случается в потрясающе огромном проценте компаний и проектов. Даже если компании знают о существовании такого понятия, как QA, и что его нужно выполнять, все усилия обычно приводят лишь к большому спринту QA прямо перед релизом. Это стрессовый период, в который мы пытаемся заставить ПО хотя бы немного работать. Разумеется, весь этот хаос повторяется на следующем цикле релиза без малейших улучшений.
Чему нас учат в вузах
Проблема в том, что при изучении computer science вас не учат, как обеспечить стандарты качества ПО. Основную часть времени тратят на изучение алгоритмов, принципов работы компьютера, историю каких-то языков и концепций и так далее. Кроме того, по крайней мере, в моей учёбе, был семестр, посвящённый методикам управления проектами и Scrum. Всё это замечательно, но тут совершенно отсутствует QA. Пренебрежение QA — это огромная потеря, потому что больше 90% всех студентов после завершения учёбы работает в контексте компаний. Они должны будут выпускать ПО вовремя и без багов.
Почему компании едва успевают выпускать ПО вовремя
Я сталкивался с этим бесконечное количество раз. Стандарты и меры обеспечения QA одними из первых попадают под нож, потому что для проектов важнее всего бюджет. Зачастую они планируются на конец проекта, но если разработка затягивается (а такое бывает часто) или происходит разрастание фич (что бывает всегда), на QA больше не остаётся времени. В конечном итоге мы получаем абсолютный минимум неструктурированного тестирования и выпускаем цифровой карточный домик с шатающимися стенами.
В некоторых компаниях и командах применяются некие стандарты QA. Обычно их внедрением занимается сотрудник сеньор‑уровня. Чаще всего он на своём горьком опыте знает, что без QA работа постепенно становится всё более сложной. К сожалению, даже наличия стандартов недостаточно. Очень часто команды просто пишут тесты, чтобы удовлетворить метрикам управления проектом.
Как сойти с этой карусели
Мне потребовались долгие годы опыта, чтобы набраться уверенности и начать говорить об отсутствии мер обеспечения QA в проектах. До этого мне приходилось спорить с менеджерами, ночевать на работе перед релизами, иметь дело с разваливающимися в продакшене системами и искать отсутствующий мониторинг. Всё это было невесело. Эти ситуации схожи с другими улучшениями кодовой базы или проекта, которые незаметны менеджерам, например с рефакторингом. Но в случае с QA это было особенно сложно, потому что если мы не внедряли никаких мер его обеспечения, мы так и не учились делать это правильно.
Только высказывая своё мнение и поднимая это на обсуждение снова и снова, мы сможем сделать первые шаги, чтобы выйти из этого порочного круга.
Поговорим о деньгах
В какой-то момент я осознал, что использую неподходящие аргументы. Если говорить, что ПО будет «стабильнее» или что оно «сильно упростит поддержку», то эти доводы не будут иметь особого смысла для тех, кто не работает над самой кодовой базой. Нужно говорить о деньгах. Мы, разработчики, должны говорить о том, сколько стоит отсутствие QA. Это язык бизнеса и руководства в целом. Сейчас я всегда стараюсь объяснить меры обеспечения QA на таких примерах: «Если не заняться этим сейчас, то трудозатраты на разработку (а значит, и затраты) через четыре месяца увеличатся на 15%» или «Нам нужно реализовать юнит‑тесты для всех фич, или наши фазы стабилизации релизов с каждым разом будут становиться всё длиннее. Это напрямую относится ко всем создаваемым нами фичам, потому что нам приходится каждый раз вручную тестировать все побочные эффекты. В результате при каждом релизе наш прогресс будет всё меньше».
По моему опыту, переход на такие примеры помогает донести мысль. В конечном итоге, ваши усилия улучшат жизнь каждого, только пока это не все понимают.
Минимальная эффективная доза
Чтобы быть реалистичными, важно не оверинжинирить меры обеспечения QA, тратя на них предварительно большие суммы. Мы не должны мешать развитию проекта в целом; к тому же такой подход понравится не всем стейкхолдерам. Я всегда советую выделить самые жизненно важные части приложения. Обычно существует определённый сценарий использования, фича или нечто иное, на чём построено всё приложение. Это какая-то базовая функциональность, которая обязана работать корректно, чтобы ПО имело ценность для клиента или пользователя. Вот её-то и нужно тестировать. Придумайте меры и способы обеспечить её работу так, как это задумано.
Мне нравится термин «минимальная эффективная доза» (МЭД). Это минимальная доза, дающая желаемый результат. В области QA это может быть план ручного тестирования, автоматизированные тесты в конвейере или что-то другое. Вот с этого и стоит начинать. Если функциональность базовых фич обеспечена, можно постепенно расширять стабильность, например, добавлять для всех новых фич юнит-тесты. Кроме того, подумайте об источниках информации, которые вы не можете контролировать, например о внешних API или вводимых пользователем данных. Находите способы валидировать и их тоже, потому что это очевидные точки, в которых ваше ПО может вылетать из-за неправильного использования. Проводите итерации и работайте инкрементно. Это относится и к QA.
Что я ищу
В каждом новом проекте, который я начинаю или продолжаю, я ищу концепцию QA. Какой бы маленькой она ни была, команде нужно подумать о ней.
Что мы выпускаем?
Что нам нужно, чтобы это работало?
Как это сделать?
Какие из мер мы намеренно исключим и почему?
Наличие письменной документации плюс, возможно, плана тестирования — отличный фундамент, на котором может развиваться ПО. Они показывают, что мы, команда, подумали, как двигаться дальше. Подумали с точки зрения МЭД. Кроме того, я рекомендую регулярно пересматривать выбранные методики, допустим, раз в квартал.
При написании кода я не пользуюсь TDD, но крайне рекомендую писать тесты параллельно с написанием ПО. Это подходящее время для написания теста. Если вы пишете тесты в процессе реализации фичи, то получите дополнительное преимущество: код будет структурирован так, что его действительно можно тестировать. При написании тестов для уже готового ПО часто выясняется, что в его коде слишком много взаимных зависимостей или что нарушены принципы единственной ответственности. Благодаря тестам вы показываете, что поняли желаемое поведение и гарантировали, что всё работает, как ожидается. Это даже можно назвать документацией к коду.
Преимущества для проекта
Когда вы заводите об этом разговор, окружающие вас люди понимают, что вас заботит проект. Поднимая вопрос качества и предлагая возможные решения, вы расширяете свою сферу влияния как разработчика. Это может принести пользу и вам, и проекту. Качество жизни разработчиков и менеджеров повысится. Это определённо заметят.
Только при наличии мер обеспечения QA проект может расти здоровыми темпами.
Меняем проекты к лучшему
Вы уже используете меры обеспечения QA в своих проектах или в них всё очень шатко? Хотите расширить свои навыки разработчика и быть известным как человек, пишущий качественное ПО?
Начните с малого. Подумайте о МЭД своего проекта. Возьмите на себя ответственность и станьте в своей команде тем, кто меняет всё к лучшему. Не всем нужно быть проповедниками QA, но вы можете учить людей необходимым методикам, показывая их на своём примере. Станьте тем, кто начнёт это обсуждение.
