Справедливости ради, стоит отметить, что российские реалии обеспечения качества в целом, далеки от западных, где под этим термином подразумевается обеспечение качества процессов компании, ведущих в конечном итоге к максимизации удовлетворенности клиента, и относится это понятие не только к IT сфере, а к бизнесу в общем его смысле. Данные стандарты предоставляются несколькими организациями, в частности ISO и IEEE
Многие знают чем занимаются программисты и довольно ясно себе представляют их обязанности и ответственность.
Российское представление обеспечения качества в IT компаниях сводится к тестированию программного обеспечения, и скорее всего, именно навыки позволяющие успешно работать в этом направлении, работодатель будет требовать у соискателя. О навыках речь пойдет позже, а сейчас давайте окунемся в среду IT компании и посмотри изнутри на её процессы и на область, занимаемую в данных процессах QA департаментом.
Усредненная структура компании, занимающейся разработкой программного обеспечения, выглядит следующим образом:
Маркетинговая служба. Занимается исследованием рынков, требований потенциальных заказчиков и расчетом соответствующих рыночных рисков. После перечисленных исследований, отдел подготавливает соответствующую документацию, в котором общими словами и требованиями, описывает продукт, требующий разработки и внедрения на рынок. Данная документация носит название MRD, т.е. Market Requirement Document
Служба документации. Занимается подготовкой документации различных видов, начиная от руководств по продукту, заканчивая конкретизацией документа MRD, называемого PRD — Product Requirement Document.
Служба разработки. Занимается непосредственно разработкой архитектуры приложения и его кода. Ядро компании и, часто, самый многочисленный отдел в ней. На основе PRD разрабатывается т.н. "дизайн-спецификация", описывающая общие принципы имплементации каждой выделенной части продукта.
Служба тестирования. Отдел, о котором пойдет речь в данной статье. Занимается проверкой корректности различных частей продукта на каждой стадии его разработки. В маленьких компаниях, численностью до 15 человек, выделять специальный отдел тестирования не имеет особого смысла, т.к. подобные команды разрабатывают малобюджетные, высокооборачиваемые продукты, и могут позволить себе быстрое тестирования средствами самих разработчиков. В случае, когда компания разрабатывает большое количество продуктов, либо продукт один, но масштабный, без отдельного департамента по тестированию не обойтись
Прежде чем вплотную подойти к особенностям профессии инженера по тестированию, необходимо ознакомиться со средой его обитания. С ключевыми терминами, с целями и задачами, а также со сложившимися стереотипами, заложниками которых, многим инженерам приходится становиться в силу начальной стадии развития данного направления в России. Основными "друзьями" специалиста в рассматриваемой области являются "баги", "тесткейсы", "бактрэкинговые системы", а также "инструменты автоматизации". Баг (Bug-жук) — ошибка, отклонение работы приложения от ожидаемого. Легенда появления этого термина говорит о том, что некие американские инженеры, разбирающиеся с поломкой электронного утсройства, обнаружили, что виной всему стал мотылек, застрявший между контактами. Дальнейшее развитие QA-индустрии согласилось с лаконичностью и информативностью термина, в наши дни прочно засевшего в сленге IT-специалистов. Чтобы как-то формализовать подход к тестированию, структурировать его, зафиксировать степень покрытия и получить базу, на которую можно ссылаться при предъявлении претензий свзанных с появлением багов, тестировщики пользуются т.н. тесткейсами. Тесткейс (Test Case — тестовый случай) представляет собой формализацию юзкейса (use case — последовательность шагов, рассматриваемая в рамках стандартного использования приложения) с целью зафиксировать отклонение или неотклонение результата от ожидаемого. Количество тесткейсов на один продукт может исчисляться сотнями и даже тысячами. Каждый такой случай покрывает определенный процент функциональности приложения, а итог в идеале должен стремиться к 100%. Для того, чтобы собрать статистику, зафиксировать ошибки и провести их от стадии открытия до стадии исправления и закрытия, инженеры по тестированию (строго говоря, не только они — данный инструмент является ядром взаимодействия между отделами) пользуются т.н. бактрекинговыми системами (Bug Tracking — отслеживание багов). Такие системы, часто представляют собой сервера с веб-интерфейсом, имеющие широчайшие возможности по структуризации контента. В общих чертах процесс использования данных систем сводится к следующей последовательности:
Инженер по тестированию, выполняя тестовые мероприятия (будь то выполнение тесткейсов, либо просто "игра" с тестируемым приложением) обнаруживает поведение, отличное от ожидаемого.
Обнаружив баг, инженер заносит информаци о нём в багтрекинговую систему. Система присваевает ему статус "New".
Далее процесc зависит от используемой системы, а так же от её настройки. Т.к. ошибка, занесенная в систему, должна переместится в чью-либо зону ответственности, необходимо определить пользователя, на которого ошибка будет переведена (assigned). Этот процесс может проходить как автоматически (в результате анализа системой входной информации об ошибке) так и вручную (при просмотре списка ожидающих багов менеджером проекта, например)
Запись об ошибке передается программисту для исправления (to be fixed). Программист принимает решение, которое может обернуться как минимум четырьмя исходами: согласиться с тем, что данное поведение приложения ошибочно и исправить его; не согласиться с тем, что это ошибка, и отправить запись обратно в отдел тестирования со статусом "Not A Bug" при этом обосновав своё решение; отправить ошибку обратно в отдел тестирования со статусом "Can Not Reproduce" при невозможности воспроизвести данный результат на своей копии приложения; отправить запрос дополнительной информации, вовлеченному пользователю (Info request).
После того, как баг приходит обратно в отдел тестирования, инженеру необходимо провести верификацию его текущего статуса. В случае исправления ошибки, тестировщику необходимо как минимум пройти описанный тесткейс и убедиться что на новой версии приложения, результат описанных действий равен ожидаемому. В случае статуса "Not A Bug" необходимо либо согласиться с этим (получив консультации заинтересованных лиц), либо не согласиться и отправить ошибку обратно разработчикам. При верификации статуса "Can Not Reproduce", необходимо убедиться, что проблема всё ещё существует, а также в том, что шаги её достижения были описаны верно.
После верификации баг отправляется менеджеру отдела тестирования в статусе "To Be Closed". Менеджер принимает решение о финальном закрытии или незакрытии данной ошибки
Описанный процесс в теории тестирования называется жизненным циклом бага. Весь жизненный цикл ошибки отражается в багтрэкинговых системах, в последствие позволяющий накопить статистику по ошибкам, провести их анализ и сделать соответствующие выводы. Стоит также отметить, что при занесении бага в систему отслеживания жизненного цикла, одним из свойств новой записи становится приоритет данного бага, который может измениться в процессе эволюционирования этой записи. Стандартно выделяют четыре приоритета: Low, Medium, High и Critical. Имея перед собой статистику по текущему проекту, можно определить критерий выпуска релиза. Обычно, обязательным критерием является отсутствие багов с приоритетами Critical и High на момент сдачи проекта. Отношение к остальным багам сугубо индивидуально для каждой компании. Такие ошибки могут исправляться как внутри текущего релиза, так и в следующих версиях продукта, если того требует рыночная ситуация.
В каждой компании существует свой подход и свои традиции тестировани, продиктованные структурой продукта, взглядами руководства, имеющимися в наличии техническими средствами и т.д. Тем не менее, можно выделить общую часть в той или иной степени, Читать далее →