« Я тестер ! »

Возможно ли построить идеальный процесс тестирования?

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


ИПТ

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

Что такое?

Идеальный процесс тестирования для меня – это процесс который позволяет решать поставленную задачу максимально эффективно, а так же создает комфортные условия для этого. Идеальный процесс, когда «лучше уже и не надо!»
Хотя само понятие ИПТ достаточно не однозначно, потому что каждый читатель может выдвинуть свои критерии идеальности процесса.

ИПТ не существует

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

ИПТ существует

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

Как?

Создание ИПТ сопряжено с набором следующих действий, которые следует повторять в течении проекта:

I. Описать то место в проекте, времени и команде, в котором вы находитесь;

II. Идентифицировать проблемные места
     1. идти от проблемы
     2. с точки зрения цели:

• удобный для достижения цели
• предсказуемый результат
• понятный объем работ

III. Приоритизировать проблемы
     1 решать по одной из каждой выделенной области в единицу времени
     2 параллельное решение из несмежных областей

IV. Внести изменения
     1 мотивация команды
     2 обратная связь
     3 довести изменение до конца

V. Проанализировать результат

Несколько примеров

Пример первый.

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

- частое обращение ПМа за информацией о состоянии задач, расчетным временем их исполнения -
введено и применяется сразу практически всей командой: обновление статусов задач в багтрэккере, выставление перед началом и изменение estimations в процессе работы над большими задачами.Убедившись в достаточной верности данных – ПМ реже задает свои вопросы.

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

Пример – второй.

Крупная оффшорная компания. Выделенный центр разработки для одного западного информационного агентства составом в Х человек, из которых 30-40 человек – группа тестировщиков.

- стремясь улучшить процесс для всей группы, изменения вносят на всех, проверяя на одной из групп.
Изменения успешные для группы из 5-7 тестировщиков валяться на группе из 2-х человек, т.к. они работают с другим типом ПО, у них свой «подкрученный» процесс тестирования.

Заключение
Подводя итог выше сказанному, следует отметить следующие моменты:
- стремиться к ИПТ необходимо – он существует и достижим;
- движение стоит начинать от проблемы;
- ...

В дополнение хочу показать карту памяти, которую я использовал для подготовки этого сообщения:


Спасибо mindmeister за сервис.

Из-под пера Maksim Grinevich

Тэги: конференция, мысли, опыт, решение

7 ответов, оставьте свой...:

1. LeshaL отметил: 29 октября 2010 г. в 18:46  

   Как тестировщик, не могу не обратить внимание: "проеблемные"

2. Maksim Grinevich отметил: 29 октября 2010 г. в 18:51  

   Спасибо, исправил.

3. Unknown отметил: 8 ноября 2010 г. в 07:32  

   в отсУСТвие строгих и фОМализованных требований...

4. Maksim Grinevich отметил: 8 ноября 2010 г. в 10:54  

   все исправил.. всем спасибо! :)

5. Александр Селяев отметил: 8 ноября 2010 г. в 12:20  

   Максим, а не почитать ли тебе Цель, Цель-2. Там как раз описано, что идеальных процессов нет - процесс совершенстования он, зараза, постоянный.

6. Maksim Grinevich отметил: 9 ноября 2010 г. в 10:10  

   Александр,
   
   Цели уже читаю ;)
   
   Но здесь я написал, что нет смысла строить едальный процесс как таковой, но идеальный с точки зрения определенных условий (время, команда, проект) путем итераций построить можно - рано или поздно придя к ситуации, когда улучшать дальше можно но не нужно

7. Александр Селяев отметил: 9 ноября 2010 г. в 12:48  

   >едальный
   Извини не мог удержаться чтобы не сделать замечание )))
   
   >>придя к ситуации, когда улучшать дальше можно но не нужно
   ты на какой странице Цели то? ;) Дочитаешь до конца напомни - подискутируем ))

Отправить комментарий