от Тестирования к Обеспечению качества

«Вначале было слово и это слово было два байта»
Старая шутка программистов

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

Создание небольших программ зачастую начинается cо встречи свободного Разработчика и потенциального Заказчика, который не всегда может точно сформулировать, что же он хочет получить, с задачи единственному Разработчику с простым описанием, что хочется видеть в готовой «программе». Это ещё не называется «проект», результат ещё не носит гордое название «продукт», но уже существует Разработчик. Когда Разработчик отдаёт Заказчику результат своего труда он часто уверен, что выполнил все пожелания Заказчика — оговорённые функции работают, ничего лишнего не написано. Но выясняется, что Заказчик имел в виду нечто другое, с программой он обращается не так, как предполагал Разработчик и обнаружил, что в некоторых случаях она делает или не то, что ожидалось или «вообще не работает»!

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

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

Тестирование

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

И когда при использовании продукта дефект проявляется, становится заметным, то пользователь получает сбой в работе. Если же при этом сбой оказывается серьёзным и блокирует работу, его никак не обойти, или из-за него аварийно «падает» продукт, то это уже не сбой а полноценный отказ в работе.

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

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

Тогда в команде появляется Тестировщик — человек, который начинает заниматься тестированием, т. е. на регулярной основе пытается выявить дефекты, занимая сторону Заказчика, при обычном использовании продукта. Количество выявленных дефектов напрямую зависит от того, насколько Тестировщик понимает, что хотел Заказчик получить в результате внедрения продукта; знает, какие задачи продукт должен решать; насколько хорошо Тестировщик знает продукт и как им пользоваться. И от опыта Тестировщика, как он умеет обнаружить тот или иной дефект.

На начальном этапе становления Тестирования каждую новую версию продукта Разработчик отдаёт Тестировщику «просто посмотреть». Общими словами рассказывая об изменениях и реализациях пожеланий Заказчика. И в результате проведённого тестирования выясняется только мнение Тестировщика об общем результате — условно «ок» или «не ок» и о том, что нужно исправить в продукте. Не предъявляя никаких условий, не требуя никаких отчётов.

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

Ведь от Тестирования теперь хочется иметь хотя бы немного определённости, очень хочется чтобы был…

Контроль Качества

Для контроля чего-либо надо научиться измерять это «что-то», а для возможности измерения необходимо:

• по чётким критериям (требованиям) разделить, что является правильным поведением, а что является дефектом, а не просто понимать, что хотел Заказчик;
• зафиксировать версию и окружение продукта, который был отдан в тестирование для того чтобы получить представление, что именно этот экземпляр продукта, этот кандидат на поставку Заказчику прошёл Тестирование;
• создать шаблоны тестовой документации (тест-кейсов, баг-репортов и т. д.), чтобы вся команда работала привычно и быстро не разбираясь каждый раз в формулировках;
• зафиксировать шаги воспроизведения, чтобы точно повторить ошибку;
• зафиксировать все проверки и понять, что с их прохождением действительно проверяются все значимые места программы, насколько «всё ок» действительно «всё»;
• сравнить критерии (требования) и проверки, чтобы понять, все ли критерии Заказчика к продукту удовлетворены.
• и т. п.

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

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

Когда накапливается информация не только об измеримых критериях, но и понимание, что приводит к их изменению, то становится возможным…

Управление Качеством

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

Качество становится измеримым, контролируемым. А то, что можно измерить, этим уже можно управлять. Можно определять необходимый уровень качества очередной версии продукта, поставляемой Заказчику, ограничить объёмы проверок в некоторых случаях, зная, что на конечный результат это не окажет влияние. Документация может определить критичные для Заказчика части продукта, а накопленная статистика подсказать, где отказы возникают редко, где риски проявления дефектов ниже и значит можно уменьшить количество проверок и потратить меньше времени.

Когда проект дорастает до желания команды или явной необходимости считать и сравнивать численные показатели (возможно это становится явным требованием Заказчика) в контроле качества, в проекте начинают внедряться формализованные процессы в разработке, в тестировании, создаваться шаблоны документов и формироваться требования по их заполнению. Для полноты картины на большом проекте необходимо создать большой объём тестовой документации, тест-кейсов — список выполняемых действия для проверки определённого требования.

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

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

Так как чем позже обнаружен дефект, тем больше людей затратило своё время (и деньги!) на создание продукта с дефектом. И тем больше общего времени потрачено зря, так как продукт необходимо возвращать в начало производственной цепочки для исправления или создания заново той части продукта, где обнаружился дефект.

И когда на регулярной основе начинают внедряться попытки повлиять на ошибки до того, когда они проявятся в отказах, начинается…

Обеспечение Качества

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

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

На качество влияет всё! Любые изменения в команде так или иначе отражаются на Качестве!

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

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

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

И обучение аналитиков, разработчиков, тестировщиков; обеспечение обмена информацией внутри команды, создание положительной рабочей атмосферы — всё это меры, направленные на снижение ошибок на каждом этапе работы, а значит — на улучшение Качества продукта.

Обеспечение Качества — процесс непрерывный, непрекращающийся, постоянно совершенствующийся! 🙂