Историю со сравнением QA (quality assurance), QC (quality control) и месте в них тестирования к настоящему времени уже достаточно подробно обсудили, и вроде бы всем уже все понятно. Если нужно освежить контекст, то вот у «Лаборатории качества» об этом неплохо написано, почитайте.
В общем, (и как обычно без доказательств и скучных ссылок на стандарты) обеспечение качества представляет из себя набор мероприятий и практик, направленных, разумеется, на повышение качества (продукта). Условно можно разбить все QA-активности на две части: процессную, куда входит настройка процессов разработки, определение критериев, найм, обучение и безжалостное увольнение сотрудников и тому подобное; и практическую. Практическая часть заключается в адаптации и подборе подходящих существующих инструментов и подходов, помогающих влиять на качество. Для серьезного влияния на процессы и организацию нужны определенные полномочия, которых, как правило, у тестировщиков нет; так что оставим это специально обученным QA-менеджерам, и пусть они рисуют свои формочки и воркфлоу в JIRA, а вот некоторые практики вполне реально попробовать внедрить самим на уровне команды.
Немного качественных (и не требующих доказательств) аксиом перед тем, как переходить к конкретным примерам.
- Основным источником ошибок и низкого качества программных продуктов является отнюдь не низкая мотивация исполнителей, квалификация менеджеров или отсталость применяемых инструментов. Плохие коммуникации могут быть источником самых серьезных проблем в разработке, и на эту тему существует достаточно много книг и анекдотов. Следовательно, одна из важнейших целей в процессе обеспечения качества — улучшение этих коммуникаций.
- Сдвиг Влево, непонятно откуда появившееся недавно модное название для известного всем графика зависимости стоимости исправления ошибки от фазы разработки. Давно известно, что стоимость исправления ошибок растет по мере продвижения по пути «техническое задание — готовый продукт — удовлетворенный заказчик». И хотя книжке с этим графиком невероятно много лет, за это время реальность сильно изменилась, и с конкретными участками графика можно поспорить, основная идея не особенно устарела; поэтому следует стремиться все действия по обнаружению и устранению дефектов «смещать влево», то есть делать раньше
- Хороший баг — вовремя найденный баг, отличный баг — баг, которого нет. Отсюда, например, упорная тяга многих менеджеров к тестированию требований, которое, якобы, помогает устранить некоторые ошибки еще до того, как они появятся в коде, собранном по этим требованиям. На самом деле, конечно, не всегда, но. Лучше предотвратить появление одной ошибки, чем найти и исправить десяток.
Короче говоря, конкретную практику можно считать полезной, если она помогает коммуникациям и раннему обнаружению проблем, и вредной, если помогает не очень .
Еще одно необходимое отступление. Как известно, серебряных пуль не бывает, и одно только внедрение утренних совещаний в узком кругу не сделает из вас agile команду. Это в полной мере относится и к приводимым здесь практикам — все они требуют адаптации, экспериментов и нет никакой гарантии, что конкретный инструмент будет работать в конкретной команде. Нужно пробовать, и смотреть на результаты.
Следует также отметить, что если вы занимаетесь автоматизированным тестированием, то являетесь, по сути, командой разработки внутри команды разработки (или рядом с ней). Это значит, что как минимум часть описываемых ниже практик можно достаточно безопасно применить сначала на тестовом коде и на тестировщиках.
Вот неполный список того, что можно попробовать:
- системы контроля версий
- база знаний
- информационная панель и точка входа
- автоматизация и непрерывная интеграция
- code review
- статическое тестирование
- модульное тестирование и измерение покрытия
- приемочное тестирование
- итерационные ретроспективы
- (дополняется)
Контроль версий
Звучит смешно, но еще какое-то время назад вполне можно было встретить проекты, где код хранился на сетевом диске, изменения приносили из дома на дискетах флешках, а сливались они по принципу «кто первый пришел». Теперь-то, конечно, все иначе, гитом никого не удивить, а хранить с историей изменений предпочитают вообще все, включая конфигурацию, черновики, чужие библиотеки и документы. Если вы так еще не делаете, самое время начать. Выбор конкретных решений сейчас не так уж и велик, поскольку использование cvs или subversion будет неоднозначно воспринято окружающими, так что остается что-то распределенное и бесплатное (git, mercurial) или более комплексное (gitlab).
Проектная база знаний
Наверное, самая простая и в то же время самая полезная практика. Суть в том, чтобы собрать разрозненную информацию по проекту в одном месте с хорошим доступом и работающим поиском. Улучшает коммуникации, экономит время, собирает вместе кусочки полезной информации, которые иначе нужно каждый раз спрашивать неизвестно у кого. Так что еще и избавляет от человеческого фактора в какой-то мере.
Кандидаты на попадание в базу:
- адреса используемых серверов и пароли к ним
- версии инструментов, сред разработки и ссылки на дистрибутивы
- ссылки на используемую инфраструктуру разработки — сервера контроля версий, сборки, тестирования и так далее
- инструкции по настройке окружений для разработки и тестирования
- куда обратиться за помощью: где получить новый пароль к vpn, заказать виртуалку, пропатчить kde и так далее
- к кому обратиться за экспертизой: кто хорошо разбирается в архитектуре, сетях, алгоритмах, современном искусстве, базах данных и в продукте вообще.
Для базы знаний хорошо подходит любой удобный вики-движок. Confluence, если у вас есть деньги, mediawiki — если хочется чтобы было как в Википедии. Вообще вариантов довольно много, при выборе нужно, в основном, чтобы проект не был совсем заброшен, поддерживал хорошее форматирование (заголовки, блоки кода, ссылки, таблицы), и сделан без применения экзотичных технологий, так чтобы его мог поддерживать кто-то из команды.
Такие проекты обычно легко запустить, но довольно сложно поддерживать; так что очень повезет, если у вас окажутся два человека, а точнее Роли: писатель, который может вначале сесть и набросать основное содержание, и садовник, чья задача — регулярно проходить по страницам и подстригать их, убирая устаревшую информацию и добавляя новую.
Информационная панель
Когда используется много инструментов, разработчику и тестировщику бывает сложно с утра получить общую картину происходящего: что у нас со сборкой, как прошли тесты, что сегодня тестируем и так далее. Частично эту проблему решает база знаний, куда можно поместить ссылки на все нужные страницы, но неплохим дополнением к этому может быть специальная статусная страница (dashboard), где компактно отображается вся важная информация, и с визита на которую, собственно, можно начать день. Многие существующие инструменты позволяют выбрать нужную часть данных и встроить её в подходящем формате на другую страницу, так что реализация такой панели — дело техники. Еще её можно вывести на ближайший телевизор и окружить разноцветными лампочками, чтобы все вокруг восторгались.
Автоматизация сборки
Как правило, это первая вещь, которую надо сделать, когда проблемы с контролем версий уже решены. Инструменты непрерывной интеграции — это достаточно продвинутые менеджеры задач, умеющие запускать по расписанию процессы, инструменты, и собирать результаты их работы в наглядном виде, поэтому в первую очередь с их помощью делают:
- ежедневную сборку в заведомо контролируемой («чистой») среде
- развертывание собранного продукта
- запуск тестов
- сбор отчетов
Некоторые идут дальше и добавляют, например, сборку по появлению изменений в коде, параллельную сборку нескольких веток (версий), развертывание на продуктовом окружении. Важно понимать, что инструмент автоматизации здесь — не более чем менеджер задач. Поэтому, во-первых, до автоматизации продукт уже должен хорошо собираться. В идеальном варианте — собираться одной командой в командной строке. Во-вторых, после автоматизации должна остаться возможность сборки вручную. Богатые возможности современных инструментов иногда подталкивают к тому, что туда переносится не запуск сборки, а сама сборка, и она становится такой сложной, что воспроизвести её руками уже невозможно. Не надо так.
В результате автоматизации мы избавляемся от человеческого фактора, получаем предсказуемое расписание (свежая сборка каждое утро!), экономию времени (прогон тестов, пока все спят). Еще одна полезная функция инструментов автоматизации — сбор статистики и хранение истории, в результате чего можно получить для сравнения сборку недельной давности, а также видеть не только конкретные результаты (вроде падающих тестов), но и аномалии — если время выполнения сборки или прогона необычно увеличилось в пару раз, это может говорить о возникновении каких-то проблем.
Инструментом выбора сейчас является Jenkins, но можно поставить, например, cruisecontrol и посмотреть, как деды собирали.
Code review
Суть code review сводится к тому, что перед публикацией изменений в коде в систему контроля версий, автор изменений представляет их на суд остальных членов команды, на котором они и высказывают автору все, что об этом изменении думают. Это очень общее описание. На самом деле варьироваться может почти все. Не только код, а и любые изменения в документах, дизайне, конфигурации могут проходить через ревью. Ревью может делаться до публикации изменений в общий код, или после неё. Успешное прохождение ревью может быть необходимым условием для попадания изменений в общий код, а может и не быть. Все эти детали нужно отлаживать в конкретных условиях конкретного проекта.
Поговаривают, что хорошо организованные инспекции кода позволяют отловить 2/3 возможных ошибок еще до попадания их в сборку. Возможно, это и так, но основная цель — повысить общее владение кодом и упростить поддержку в дальнейшем.
Важно отметить следующее. Коллективная инспекция — это мероприятие, затрагивающее эмоции: мало кто любит принимать критику, много кому нравится критиковать. Неудачно построенный процесс может серьезно подорвать командный дух, поэтому при его внедрении следует придерживаться некоторых правил:
- процесс желательно максимально формализовать. Комментарии — только по делу. Ревьюерам стоит воздерживаться от субьективных высказываний типа «что это вообще за ерунда» или «я бы тут лучше итератор воткнул». Должны быть понятные процедуры входа и выхода, правила оформления, внесения исправлений по результатам.
- за исключением некоторых ситуаций (например — мы пишем контроллер АЭС и все изменения сразу идут в реактор), ревью не должно блокировать попадание изменений в код. Тут сложная аргументация, но, как минимум, с каждым днем залежавшиеся локально изменения все сложнее интегрировать в общий код
- участвовать по мере сил должна вся команда, не стоит допускать ситуации, когда все изменения проходят только через самого важного или опытного (но это не значит, что он должен вообще самоустраниться)
- в то же время, имеет смысл ограничивать число участников конкретного ревью — чтобы не затягивать процесс и чтобы избежать споров
- стоит ввести ограничение по времени. Нет смысла рецензировать код, который к этому моменту уже несколько раз переписали
- в целом, code review должно быть не повинностью, а полезной и интересной задачей
(продолжение следует)