- О проблемах с теорией ограничений
- Отслеживание дефектов
- Разбор и категоризация багов
- Исследование дефектов
- Адвокат качества — это тестировщик
- Сквозное тестирование
- Но мы такие Agile и Lean?
О проблемах с теорией ограничений
«Много лет специалисты по DevOps продвигали теорию ограничений, оптимизируя конвейеры и доставку ПО. Ручное управление релизами — Автоматизируйте. Развертывание? Управление образами? Автоматизируйте. Откатывание, после того как отправили на прод зажженный мусорный бак? Автоматизируйте. Любая малоценная деятельность, которую только могли обнаружить на пути кода из бэклога к клиенту, считалась «узким местом», которое надо было или убрать вообще, или оптимизировать.
И многим казалось, что самая медленная часть доставки ПО — это тестирование. А поскольку тестирование — это то, ради чего существует непрерывная доставка, на этом стоило бы остановиться. Да, можно и нужно делать тесты более быстрыми, более автоматизированными, распараллеленными и т. д. Но когда наиболее ценная деятельность у вас является узким местом, вы уже достигли оптимального результата. Вы достигли «наилучшей возможной оптимизации».
На этом оптимизации не закончились. Мы продолжали «рубить». Мы вообще убрали интеграционные и e2e тесты и все делали на уровне юнит-тестов. На уровне персонала мы оптимизировали всех, кто, как нам казалось, не умел кодить, не вникая в ценность их задач. Мы решили, что тестирование это узкое место. То есть QA-команда оказалась узким местом.
В индустрии в целом стали относиться к этой должности все хуже. Ожидания от QA-инженеров все увеличивались, а зарплаты снижались (а зарплаты всех остальных увеличивались), мы заключали с тестировщиками временные контракты, переводили их на другие должности, совмещали должности — в общем, мы делали все, чтобы избавиться от этой роли вообще.
Это создало спираль с положительной обратной связью, в которой каждый, кто хоть немного умел писать код, или кому не нравилось плохое отношение, уходил. Вообще, в индустрии считалось, что человек, долго занимающий должность тестировщика — просто недостаточно квалифицирован. Никто не рекомендовал эту профессию новым выпускникам. Она считалась «тупиковой». А наше «прощание» с QA-отделом было простым, руководство сообщило: «у нас больше не будет этой роли, разбирайтесь сами». Это было неуважительно и деморализующе по отношению к людям, которые всю карьеру провели на должности QA. Это грозило проблемами, потому что некачественное, непроверенное ПО это реальная проблема.
Вы, наверное, уже поняли: разработчики не знали о проблеме. Большинство компаний понятия не имеют, кто и что должен делать с точки зрения качества ПО. Те, кто все-таки сохранил эти роли, теперь с трудом находят места в штатном расписании, поскольку профессии уже нанесен большой ущерб.
Оказалось, для ускорения разработки нужно было не увольнять тестировщиков, а как раз наоборот.
Деградация профессии была худшей управленческой ошибкой. Профессии, на развитие которой ушли десятилетия, и последствия будут заметны. К тому времени, когда все компании, бездумно следующие «теории ограничений», осознают неправильность и неполноту теории, и ситуация будет исправлена, пройдут годы.
«Поломанная» роль QA, к которой мы уже привыкли, еще не осознана. Восстановления обязанностей не происходит. Кстати, совсем не удивляет, что разработчики не рады брать на себя обязанности QA, чуждые им — без какой-либо дополнительной компенсации, благодарности и вознаграждения. Те, кто еще помнит процессы в высокоэффективных QA-командах, могут воспроизвести эти модели поведения, но новые разработчики и менеджеры понятия не имеют, как всё делалось правильно, и не замечают, чего не хватает в процессах.
А главный принцип заключается в том, что обеспечение качества — это работа. Работа сложная. Как и с любой сложной работой, неверно предположение, что кто-то другой сделает работу за тебя, и сделает её быстро и незаметно, или что все сделает автоматизация.
Отрицание очевидного — это не стратегия. Кажется глупым писать такие очевидные вещи, но опыт подсказывает, что надо.
Вот вещи, которые необходимо сделать для восстановления управления качеством:
Отслеживание дефектов (Defect Tracking)
Чтобы пользователи могли присылать информацию о багах, а разработчики — регистрировать. Что такое баг? Баг — это отдельная заявка (тикет), в которой описывается, что не так и насколько это плохо. Там не описывается работа по устранению, а только сам дефект ПО, способ его воспроизведения, и его негативное влияние. В последние годы с удивлением обнаруживаю, что большинство команд разработчиков, с которыми я работаю, не отслеживают дефекты. У них целый океан оправданий: нет времени, это не моя задача, не хочу ничего исправлять, я получаю зарплату за новые фичи, а не за баги. Ни одно из оправданий не годится.
Просто управлять списком ошибок — это тоже РАБОТА.
Разбор и категоризация багов (Triage)
Разбор багов — это процесс, с помощью которого команда распределяет баги, присваивает им приоритеты, удаляет дубликаты, классифицирует, и так далее, в общем обрабатывает поступающие баги. Наличие единого стандарта, как выглядит баг высокой/средней/низкой степени серьезности, поможет команде во многих отношениях. Назначить кому-то баг — это тоже работа. Высокоэффективная команда может плавнее регулировать качество после увольнений важных сотрудников, передавать какую-то категорию багов новой команде в случае реорганизации, или удалять все баги при удалении функции из приложения.
Можно обойтись без разбора, если команда никогда не реорганизуется (шутка)
Исследование дефектов (Defect Investigation)
Воспроизведение, или repro — важнейшая часть управления багами. Чтобы ускорить процесс, кто-то должен переводить на человеческий язык фразы типа «Я пытался купить билет и не получилось» — на фразы типа «Проблемы с кодировкой нарушили процесс покупки у клиента с неанглийским символом в имени». Аналогично, вопросы «Сколько раз это произошло?» и «Как повлияет на пользователя?» требуют времени и внимания.
Исследование — инженерный подход к бэклогу багов
Адвокат качества — это тестировщик
Полезно иметь людей в команде, внимание которых сфокусировано на качестве конечного продукта. Качество может быть «заботой всех» в Agile/DevOps теории, но оно должно быть «задачей кого-то», и кого-то конкретного. В дискуссии между качеством и скоростью необходимо участие адвоката качества, это важно. Инструменты тестирования, качество тестов, планы тестирования — все это нуждается в адвокатах качества, которые будут приводить свои аргументы в пользу наилучшего пути. Адвокаты качества — это тестировщики. Вот так просто.
Сквозное тестирование
Одна из самых распространенных проблем, с которыми я сталкиваюсь в командах — владение системой. Увеличение сложности архитектуры приводит к тому, что руководство старается не расширять команды. Это вполне рациональная стратегия, но она оставляет пробел вокруг буквально самой важной вещи в приложении — его качества. Которое лучше всего оценить сквозным тестированием.
По моему опыту, средняя dev-команда больше не делает сквозное тестирование, потому что оно слишком сложное. И у них нет специалистов по e2e, то есть тестировщиков.
Кто-нибудь из вас пробовал пользоваться этим приложением?
Но мы Agiled
«Но мы же agile, lean, dynamic, нам это все не нужно». Если присмотритесь, то обнаружите, что все вышеописанное, скорее всего, происходит и в вашей компании, в той или иной мере. А представьте, если бы в любой другой сфере были такие подходы. Автомобильной, финансовой, медицинской. «Мы не занимаемся обеспечением качества» — это просто неприятно слышать.
Неспособность правильно организовать Quality Assurance и слепое следование DevOps приводит к большим проблемам.
Самые нужные сотрудники компании — оказываются ненужными. QA видят проблемы с качеством, решают их, но не получают за это никакого признания и повышения. Когда они сообщают о проблемах с качеством продукта, с ними говорят как с «уставшими, которые просто хотят отдохнуть». QA видят, как раз за разом вознаграждают тех, кто «двигается быстро и ломает устаревшее», а им приходится бегать вокруг и чинить сломанное, и не получать благодарности, а то и вовсе быть уволенными.»
Об авторе и компании: Automation Engineer, компания WWT (27-я частная компания в США в списке Forbes, подрядчик Intel, providing environments to offer cloud services for Intel business groups).
