QA — грамотно

Тезисы

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

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

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

Что такое качество

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

Тестировщик не отвечает за качество программного продукта

Дочь попросила меня проверить ее домашнюю работу по алгебре. Проверив работу, я обнаружил несколько ошибок, причем достаточно определенно указал, где и почему они допущены. Дочь забрала свою работу, а на следующий день сообщила: «Папа, я из-за тебя получила тройку». Оказалось, что накануне дочь поленилась и не исправила ошибки, на которые я ей вчера вечером указал. А сегодня она попыталась переложить ответственность на человека, указавшего на ошибки, за то, что она их не исправила.

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

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

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

Однако именно менеджер проекта, а не команда и не тестировщики, единолично несет ответственность за качество продукта, потому что ключевые проектные решения принимает только он, в том числе и решения делегировать какие-то из своих полномочий.

За что отвечает тестировщик

Очевидно, что если тестировщик не отвечает за качество, но в проекте его услуги востребованы, то он отвечает за что-то другое.

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

•       Какова качественная и количественная оценка текущего состояния продукта с точки зрения его соответствия требованиям?

•       Сможет ли проектная команда поставить продукт в срок и в надлежащем качестве, если сохранятся существующие тенденции обнаружения и исправления дефектов?

•       Какие корректирующие меры рекомендуется предпринять, если прогноз неблагоприятный?

Хороший тестировщик в любой момент может дать заинтересованным лицам проекта ответ, по крайней мере, на первые два вопроса.

Причины заблуждений

Причина первая – сложившаяся практика смешивать понятия тестирования программного обеспечения (software testing) и обеспечения его качества (quality assurance). Такое наблюдается сплошь и рядом не только в России, более того, вся эта путаница пришла к нам из-за рубежа вместе с термином quality assurance («обеспечение качества»).

Чей воспаленный мозг впервые посетила идея называть тестировщиков специалистами по обеспечению качества, уже, наверное, вряд ли удастся установить. Более того, понятно, что именоваться специалистом по обеспечению качества может некоторым, особенно начинающим, показаться престижнее, чем тестировщиком программного обеспечения.

Кто такие инженер по обеспечению качества и менеджер по обеспечению качества — тема для отдельного разговора. Здесь отмечу только, что специалисты по обеспечению качества отвечают за контроль следования процессам разработки ПО, а не за качество программного продукта

По-прежнему сайты работодателей и кадровых агентств пестрят объявлениями о поиске QA-инженеров и QA-менеджеров, в перечне обязанностей которых перечислены обязанности типичного тестировщика и типичного тест-менеджера. Это очевидное свидетельство того, что у работодателей сформировались неверные ожидания, связанные с тестировщиками, которых они громко и  с видимым удовольствием величают специалистами по обеспечению качества. Поэтому скептицизм, с которым тестировщики-профессионалы относятся к таким объявлениям, вполне оправдан.

На самом деле, как мы уже выяснили, тестировщики не отвечают за качество, поскольку обычно не могут с организационной точки зрения повлиять на принятие решений по качеству продукта.

Кроме того, как отмечает в заметке с говорящим названием “Testers: Get Out of the Quality Assurance Business” — в своем блоге [1] Майкл Болтон (Michael Bolton), тестировщики не занимаются программированием и не могут вносить в код изменений, непосредственно улучшая качество программного кода. Комментируя деятельность тестировщиков, М.Болтон пишет, что это не обеспечение качества (quality assurance), а содействие качеству (quality assistance).

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

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

Вместо заключения

За что отвечает тестировщик (группа тестирования) – это ключевой вопрос, на который необходимо знать ответ всем заинтересованным лицам проекта, потому что от его правильного понимания зависит успех проекта. Если ожидания заинтересованных лиц совпадают с целями группы тестирования, взаимодействие тестировщиков и разработчиков идет гладко, без серьезных конфликтов, а руководители разного уровня получают своевременную информацию о состоянии проекта и знают, что с ней делать.

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

————————

Тезисы и слайды считаются ознакомительным материалом, и не могут являться объектом придирок любого рода.

Автор может в любой момент заменить (или снять) свою презентацию или другими материалами, или слайдкастом.