Справедливости ради, стоит отметить, что российские реалии обеспечения качества в целом, далеки от западных, где под этим термином подразумевается обеспечение качества процессов компании, ведущих в конечном итоге к максимизации удовлетворенности клиента, и относится это понятие не только к 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 на момент сдачи проекта. Отношение к остальным багам сугубо индивидуально для каждой компании. Такие ошибки могут исправляться как внутри текущего релиза, так и в следующих версиях продукта, если того требует рыночная ситуация.

В каждой компании существует свой подход и свои традиции тестировани, продиктованные структурой продукта, взглядами руководства, имеющимися в наличии техническими средствами и т.д. Тем не менее, можно выделить общую часть в той или иной степени, отраженную в подходе каждой конкретной фирмы. Так, любое тестирование должно базироваться на некотором эталоне, отклонения от которого формально можно считать ошибкой и ссылаться на этот эталон при занесении багов в систему контроля. В качестве эталона, часто, выступает техническая спецификация, отражающая детализированные требования заказчика спроектированные на объективные возможности отдела разработки. Тестирование может начинаться, и в теории должно, со стадии появления документа PRD. Тестовые инженеры должны проводить документацию на предмет верификации поверхностной логики с целью отловить ошибки в концепции на ранних стадиях. Известно, и подтверждено на практике, что стоимость ошибки нелинейно увеличивается в зависимости от времени её обнаружения. В качестве примера (по методу бытовых аналогов) можно рассмотреть ситуацию когда Вы строите карточный домик — чем выше домик, тем с большим риском обвала Вы вытаскиваете карты из нижних уровней.
После этого, тестирование проводится на стадии имплементации. Производится тестирование готовых модулей либо с привлечнием тестирования кода, либо, если позволяет продукт, тестировать, используя некий внешний интерфейс. По мере разработки кода тестируется совместимость новых модулей со старыми. Под конец проводится полное тестирование продукта. При разработке новой версии кода, проводится регрессионное тестирование. Регрессионное тестирование часто строится на тех же тесткейсах, которые использовались для тестирования предыдущих версий. Основной сложностью и источником ответственности инженера отдела тестирования является решение о степени детализации рассмотрения тестируемого приложения. Опытный QA-инженер ценен в частности тем, что может легко найти золотую середину между времнем работы и её качеством. Эта зависимость имеет определяющее значение в работе отдела.

Занятность в тестировании имеет как преимущества, так и недостатки. Труд инженера по тестированию в среднем ценится меньше программистского труда. С другой стороны тестирощики имеют более широкий спектр областей в которых они компетентны. Чаще всего программисты имеют жесткую специализацию (базы данных, 3д-графика, пользовательские интерфейсы и т.д.). Инженер-тестировщик же может без особых проблем в адаптации применять свои знания и навыки практически в любой сфере. Кроме того, представитель этой профессии, по прошествии определенного времени и по мере накопления определенного багажа знаний и опыта, может заняться обеспечением качества корпоративных процессов как таковых. Кроме того, занятость в QA процессах тренирует в человеке качества, полезные не только в работе, но и в быту. Быстрое определение потенциальных проблем, способов их разрешения, критический взгляд на вещи и интуитивное определение слабых мест, а так же последствий их влияния, поможет практически в любой сфере человеческой деятельности, будь то управление финансами, развтитие предпрития, оптимизация налогов или выбор машины в салоне или сковородки в магазине.
А о подходах и методиках, используемых в тестировании, я расскажу в следующих статьях. Спасибо и удачи!