Работаем над качеством или Плоды CodeFest 2013

Работаем над качеством или Плоды CodeFest 2013

Аватар пользователя Вячеслав, Руководитель отдела качества
Вячеслав, Руководитель отдела качества
05 июня 2013

В этом году мне впервые удалось побывать на CodeFest. Мероприятие значительное, масштабное и вызвало кучу эмоций! Завсегдатаи говорили, что CodeFest уже не тот, что с докладчиками в этом году подкачали. Не могу высказать свое мнение по этому поводу, не с чем сравнивать, однако те доклады, на которых побывал я, мне понравились. Основное внимание я уделил секции QA, об одном из докладов которой и пойдет речь.

«Делаем прозрачными сроки тестирования методом черного ящика» Алексей Петров, директор по качеству, Мегаплан.

Информация будет полезна не только тестировщикам, но также разработчикам и менеджерам.

И так, как же выглядит планирование разработки:

  1. 90% времени мы закладываем на разработку
  2. 5% на тестирование
  3. 5% на выкатку релиза

Что же происходит на самом деле:

  1. 90% разработка
  2. 25% тестирование
  3. 20% багфиксинг
  4. 10% выкатка релиза

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

Как обычно выглядит тестирование со стороны — это черный ящик, где сидят странные люди, делающие кучу шагов, для того, чтобы повторить одну ошибку, непонятно что перед этим курившие. Но на самом деле ребята из Мегаплана добились такого прогресса, что они и потестировать успевают, и у них ещё время поиграть остается. В этом им помогает четкое планирование тестирования, фиксация трудозатрат, на основе которых выявляется фокус-фактор. Также необходимо приоритезировать активности. Ведь от менеджеров часто поступают срочные задачи, которые требуют немедленного вмешательства, что в свою очередь мешает срокам тестирования других проектов. Тогда нужно добиваться от менеджера четкого понимания ситуации — если я протестирую его задачу сейчас, то задача Васи будет протестирована только через 1,5 дня. И в этот момент необходимо знать, согласится на это Вася или нет.

Существует несколько факторов, влияющих на оценку тестирования:

  1. Сложность. Все зависит от того, что вы будете проверять — формочку с двумя кнопками или целый модуль.
  2. Разработка тестовой документации.
  3. Объем тестовых данных, который необходимо создать, чтобы протестировать необходимый функционал.
  4. Прогон тестов.
  5. Баг-репорты.
  6. Команда, которая разрабатывает.
  7. Решение оперативных вопросов. Планерки и т.д.
  8. Уровень интеграции с предыдущими релизами. Необходимо ли проверить систему полностью после доработки или ограничиться текущей функциональностью.

Данная оценка должна со временем перейти на уровень подсознания. Это дает вам возможность понять объем работ, необходимый для выполнения. Кроме того, организация работы построена так, что время списывается, только если работа закончена. Если же по задаче была проделана работа, но она не завершена, то в задачу списывается время, оставшееся до её завершения. Это позволяет к концу рабочего дня всегда видеть актуальную оценку оставшейся работы.

Основной особенностью является учет фокус-фактора при оценке задач. Высчитывается он по следующему принципу: мы делим реально затраченное время задачи на планируемое. Допустим, мы оценили первый раз выполнение задачи в 3 часа, а выполнили за 6 часов, таким образом, фокус-фактор у нас будет равен 2. При оценке следующей задачи мы должны будем учитывать фокус-фактор и умножать на него планируемое время. Он является динамическим и от задачи к задаче должна происходить корректировка. Это достигается следующим образом: если у нас после выполнения другой задачи фокус-фактор будет равен 0,5, то мы должны 2 умножить на 0,5 и получить актуальный фокус-фактор для оценки следующих задач. Ребята из Мегаплана добились практически точной оценки задач, и фокус-фактор у них колеблется в пределах 0,9 — 1,1.

Кроме того, для эффективной работы необходимо разграничить активности. В команде каждый тестировщик занимается своим делом, кто-то тестирует web-часть, кто-то desktop, кто-то настраивает сервера и пишет автотесты. Необходимо составить весь список активностей и отобразить в виде таблицы. Таким образом, можно узнать, сколько свободного времени есть у команды и насколько каждый загружен. Оставшееся командное время корректируется с учетом фокус-фактора. В дальнейшем, оперируя этими данными перед менеджерами и руководством, можно гораздо быстрее доказать свою позицию о необходимости привлечения в команду людей или смещении сроков релиза из-за недостаточного времени для тестирования. Необходимо так же использовать приоритезацию задач, как пример, с помощью матрицы Эйзенхауэра. Она подразумевает деление задач на важные и неважные, срочные и несрочные. Без такой приоритезации не будет возможным правильно организовать работу отдела качества.

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