• Главная
  • О сайте
  • Архив

Normal testing

From the programmer's worst friend

Feeds:
Записи
Комментарии
« Майкл Болтон — Два ехидных глаза смотрят в будущее тестирования
Вячеслав Панкратов: Как договариваться о раннем релизе с командой разработки (мастер-класс) »

Михаил Павлов: Отвечает ли тестировщик за качество?

19.11.2010 Автор: Alexei Lupan

Тезисы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

————————

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

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

Ваша оценка:

Поделиться ссылкой:

  • Tweet
  • по электронной почте
  • Печать

Понравилось это:

Нравится Загрузка...

Похожее

Опубликовано в Конференции, Презентации | Отмечено Михаил Павлов, SQA Days 8 | 4 комментария

комментария 4

  1. на 09.12.2010 в 09:21 Alexey.Chumagin

    Действительно хороший доклад. Рекомендую к прочтению молодым тестировщикам.

    НравитсяНравится


  2. на 02.12.2010 в 20:57 mikhail.pavlov

    to Fantom4eg: пообщаться можно. Левая часть вадреса гуглопочты — мой ник.
    Алексей, большое спасибо за пиар:)

    НравитсяНравится


    • на 02.12.2010 в 21:23 Алексей Лупан

      Пиару пиар!

      НравитсяНравится


  3. на 27.11.2010 в 18:49 Fantom4eg

    К сожалению пропустил доклад. Было бы очень интересно послушать и пообщаться по этому поводу. Наконец-то я нашел что-то внятное и простое. Может я смогу с помощью этого доклада объяснить руководству смысл бытия. А то у нас в компании все как написано — лавры команде, шишки — тестировщикам.

    Спасибо Михаилу за доклад и тебе, Лёша, за то что оперативненько выложил. 😉

    НравитсяНравится



Обсуждение закрыто.

  • Aut bene

    Спiвпрацювальник по підготувальні тестувальників.

    Автор [глоссария] терминологии тестирования (english).

    Неоднократный докладчик [SQA Days], [QA Fest] и других конференций по тестированию ПО.

    Неспешный езжун на «[Волга ГАЗ-21]» 1965 года выпуска.

    Игрун чего-то похожего на тяжелый блюз [на классической гитаре].

    И так [далее].

  • Присоединиться к ещё 1 338 подписчикам

  • Follow Normal testing on WordPress.com
  • Залежи

  • Темы

    • Без рубрики (6)
    • Документация (18)
      • Тест-план (2)
    • Изображения (148)
      • Видео (48)
      • Комиксы (20)
      • Скриншоты (48)
      • Фотографии (46)
    • Инструменты (53)
      • Debian (13)
      • Макросы (1)
      • Трекеры (15)
        • Баг-трекер (8)
        • Тест-трекер (5)
      • LibreOffice (4)
    • Книги (19)
    • Конференции (137)
      • Подкасты (12)
      • Презентации (50)
        • Слайдкасты (10)
      • Семинары (18)
    • Обзоры (1)
    • Постановка мозгов (245)
      • Банальное (168)
        • Не смешно (47)
        • Неприятно (14)
        • Печали (15)
        • Радости (57)
        • Смешно (35)
      • В гостях у психиатра (45)
        • Поросенок v2.0 (3)
        • Странности (12)
        • Удивительные баги (17)
      • Level 80 (2)
    • Соображения (206)
      • Балабольник (10)
      • Гипотезы (11)
      • Озарения (55)
      • Откровения (88)
    • Статьи (23)
      • Интервью (6)
      • Опросы (1)
      • Переводы (11)
    • Управляторское (56)
      • Agile (13)
      • Программисты (23)
      • Рекрутинг (8)
    • Учеба в бою (83)
      • Тренировка (13)
      • Фишки (28)
      • Читерство (9)
    • Testing like… (79)
      • Acceptance testing (5)
      • Business Driven Testing (2)
      • Context-driven testing (2)
      • Defect-based Test Design Technique (1)
      • Автоматизация (37)
        • Performance Testing (5)
      • Рецессионное тестирование (1)
      • Юзероиммитатор (15)
      • Exploratory testing (9)
      • тест-дизайн (8)
      • State Transition testing (1)
      • Unit testing (1)
      • Usability testing (2)
    • To Do (12)
      • Анонсы (7)
  • Тэги

    Calc Excel James Bach Jira Mantis SQA Days SQA Days 7 SQA Days 8 SQA Days 10 Александр Александров Александр Орлов Алексей Баранцев Наталья Руколь Хватит тупить Юля Нечаева
  • Самое читаемое

    • Тестируем поля логин/пароль
    • Группирование данных в Excel
    • Priority & Severity на пальцах обезъянок
    • Как в Excel отображать символ валюты перед цифрами
    • План тестирования должен быть внятным, четким, небольшим
    • Что такое перформанс-тестирование
    • Разница между ошибкой (багом) и дефектом (тоже багом)
    • Ссылки в Confluence. Mazafaka
    • Основные положения тестирования
    • Резюме тестировщика должно быть
  • Комментарии

    • Alexei Lupan к записи Сетап для преподавания в сети
    • Дмитрий к записи Сетап для преподавания в сети
    • Сетап для преподавания в сети | Normal testing к записи Оценка времени на тестирование: неочевидные надводные камни
    • Мария к записи Выделить вкладку страницы в фокусе в Firefox
    • Alexei Lupan к записи Савин, Фолкнер и Нгуен…
    • Тимур Исхаков к записи Савин, Фолкнер и Нгуен…
    • Alexei Lupan к записи Кагбэ собеседования в паблике
  • Блоги о тестировании

    • 1) Блоги тестировщиков на software-testing.ru
    • Про тестинг
    • Selenium IDE — rulezzz!
  • Профессиональное

    • Удобный софт
    • Управление тестированием
    • IT Crowd wikiquotes
    • Testing History

На платформе WordPress.com.

WPThemes.


loading Отмена
Сообщение не было отправлено — проверьте адреса электронной почты!
Проверка по электронной почте не удалась, попробуйте еще раз
К сожалению, ваш блог не может делиться ссылками на записи по электронной почте.
Политика конфиденциальности и использования файлов сookie: Этот сайт использует файлы cookie. Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.
Дополнительную информацию, в том числе об управлении файлами cookie, можно найти здесь: Политика использования файлов cookie
%d такие блоггеры, как: