Доклад Михаила Павлова на конференции SQA Days-8 19-20 ноября 2010, Санкт-Петербург

1. Отвечает ли тестировщик за
качество
Михаил Павлов
Центр качества
Luxoft

2. Немного о себе
 1987-1988, 1993-2000 ИГЭУ (ассистент, старший преподаватель,
доцент)
 1989-1992 МГУ (аспирант кафедры алгоритмических языков
факультета ВМиК)
 2000-2004 Luxoft (старший тестировщик, ведущий тестировщик)
 2004-2006 Росбанк (заместитель начальника отдела системной
архитектуры и управления проектами)
 2006-2009 Auriga (Руководитель группы SEPG / Директор
тренинг-центра)
 C 2009 - Luxoft (менеджер по качеству Центра качества)
 Кандидат физико-математических наук, доцент

3. Опыт работы
 15 лет работы в области тестирования и обеспечения качества
(аспирантура МГУ, Luxoft, Росбанк, Auriga)
 5 лет в области управления качеством (Luxoft, Auriga)
 Опыт cертификации ISO 9001:2008 (Luxoft), CMM, CMMI (Luxoft,
Auriga)
 Опыт внедрения процессов в рамках модели CMMI (Luxoft,
Auriga)
 Сертификат внутреннего аудитора систем менеджмента
качества ISO 9001:2008 (2009)
 Сертификат обучения Introduction to Capability Maturity Model
Integration v. 1.2 от Anywhere 24 (2010)

4. Что такое качество
 ISO9001:2008
 Качество - степень, с которой
совокупность собственных характеристик
выполняет требования
 ГОСТ 15467-79
 Качество - совокупность свойств,
обусловливающих ее пригодность
удовлетворять определенные
потребности в соответствии с ее
назначением
 Практика разработки заказного ПО
 Качество – степень соответствия
требованиям (заказчика)

5. Типичная картина - 1
 Объявление на Software-testing.ru

6. Типичная картина - 2
 На один из блогов по тестированию

7. Типичная картина - 3
 Из кейса «Опять 25» (happy-pm.com):
 М: Разработчики буквально пару минут назад сообщили мне, что завтра к
обеду будет готов билд, в котором будут исправлены все пять оставшихся
критичных багов, восемь второго приоритета и еще куча мелких. Всего 27
штук!
 Т: Мда… они молодцы, конечно. Они сами что-нибудь потестили? Билд хотя
бы собирается нормально?
 М: Конечно собирается. И юнит-тесты прошли все, хоть их и немного.
 Т: … да еще и старых.
 М: Ну да, старых, но это же все время, ты же в курсе. Каждый из них,
конечно же, проверил все пофикшенные баги у себя локально, куда ж без
этого. И все было нормально. Но чтоб узнать, как оно все вместе работает,
вы нам и нужны. Так ведь? У них на это просто никогда не будет времени,
да и не их это задача. Вы же должны обеспечить качество продукта.
 Т: Хорошо, я могу протестировать продукт, но как обеспечить его качество
и качество их чудо-кода… я не знаю.

8. Почему тестировщик не может
отвечать за качество ПО
 Тестировщик не может обеспечивать качество работы
других участников проекта
 Тестировщик не вносит изменения в код
 Тестировщик, как правило, не может организационно
повлиять на решения об исправлении ошибок
 Тестировщик не управляет ресурсами проекта
 Тестировщик не управляет бюджетом проекта
 И как следствие, тестировщик не отвечает за качество
ПО

9. Кто отвечает за качество ПО
 В проекте – менеджер проекта
 В подразделении разработчиков – руководитель
подразделения
 На уровне компании – первое лицо компании
 В их руках ресурсы, бюджет, право на принятие решений

10. За что отвечает тестировщик
 Тестировщик предоставляет информационный сервис группе
разработки о текущем состоянии (качестве) программного
продукта.
 Качество сервиса характеризуется следующими признаками:
 Объективность
 Полнота
 Эффективность
 Своевременность
 и т.д.
 Сервис не предполагает ответственности за действия его
потребителей, противоречащие предоставленной информации

11. Три главных вопроса
тестировщику - 1
 Какова качественная и количественная оценка
текущего состояния продукта с точки зрения его
соответствия требованиям (заказчика)?
 Какова готовность ли продукт к выпуску?
 Сколько и каких дефектов в нем
обнаружено/исправлено/осталось исправить?
 Каково покрытие ПО выполненными тестами?
 И т.д.

12. Три главных вопроса
тестировщику - 2
 Сможет ли проектная команда поставить продукт
в срок и в надлежащем качестве, если сохранятся
существующие тенденции обнаружения и
исправления дефектов?
 Сходятся ли кривые обнаружения новых дефектов и
исправления уже найденных?

13. Три главных вопроса
тестировщику - 3
 Какие корректирующие меры рекомендуется
предпринять, если прогноз неблагоприятный?
 Уменьшение объема поставляемой функциональности
 проведение дополнительных раундов тестирования
 эскалация проблемы на уровень руководства
(заказчика)
 И т.д.

14. Причины заблуждений - 1
 Тестирование ПО ≠ Обеспечение качества ПО
 Обеспечение качества – это обеспечение гарантий
того, что информационная система и процессы ее
жизненного цикла соответствуют заданным
требованиям и утвержденным планам (ГОСТ
34.601-90)
 Тестировщик (after Cem Kaner and Michael Bolton)
не занимается обеспечением качества; он
помогает его обеспечить (quality assistance)

15. Причины заблуждений - 2
 Готовность некоторых (начинающих)
тестировщиков отвечать за качество продукта, а
не за качество своей работы
 Неспособность решить поставленную перед собой
задачу, разочарование в профессии
 Желание некоторых менеджеров проектов
сделать тестировщиков своими подельниками
 Успех разделяет вся проектная команда, неудачи
проекта стараются свалить на тестировщиков
 Искреннее заблуждение некоторых топ-
менеджеров в том, что тестировщики способны
обеспечить качество
 Нереалистичные ожидания от тестирования,
неверные оргвыводы

16. Выводы
 Место тестировщиков в проекте – объективная оценка
качества ПО (УЦ Люксофт)
 Необходимое условие успеха проекта – одинаковое
понимание всеми заинтересованными лицами сферы
ответственности тестировщиков
 Взаимные ожидания заинтересованных лиц должны быть
согласованы