« Я тестер ! »

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


ИПТ

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

Что такое?

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

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

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

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

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

Как?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


Текст сообщения и комментарии...

Не совсем про тестирование, но очень понравилось:

"For true success ask yourself these four questions: Why? Why not? Why not me? Why not now?"

"Для настоящего успеха задайте себе следующие четыре вопроса: Почему? Почему бы и нет? Почему не я? Почему не сейчас? "

Текст сообщения и комментарии...

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


1) Нам не требуется такого уровня тестирования.
2) Это стоит до{хрена} кучу денег.
3) Слишком долго будете копаться.
4) Тестирование никогда «не завершится полностью».
5) Мы никогда не знаем, сколько времени уйдет на тестирование.
6) Слишком академично, мы же не NASA.
7) А его собственно и в плане то не было.
8) Тестирование сильно тормозит выход продукта.
9) Кастомер просто весь в нетерпении, а ваши тестеры тормозят процесс.
10) Тестирование выставляет нас идиотами.
11) А какой толк вообще от тестирования?.
12) Пока тестеры нароют все баги – рынок ушагает от нас.
13) Да и вообще всем пофигу на эти баги.
14) А собственно тестирование вообще не дает ответа ни на какой вопрос.
15) Разрабы сами все протестят.
16) Не надо ломать систему, и так работает не очень.
17) Пользователь сам найдет баг и мы все пропатчим.
18) Ну нет у нас времени, чтобы написать требования.
19) И вообще, тестеры никогда не находят самые нужные баги.
20) Тестирование все равно никогда не найдет всех багов.
Текст сообщения и комментарии...