Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Полезные "фишки" для построения успешного процесса тестирования

Наталья Руколь - доклад на SQA Days, 2-3 декабря 2011, Москва

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

Полезные "фишки" для построения успешного процесса тестирования

  1. 1. Фишки правильных тест-менеджеров Слайды с буковками и разбор примеров будут по адресу http://natalyarukol.ru/
  2. 2. Утро правильноготест-менеджера
  3. 3. Утро правильноготест-менеджера
  4. 4. Утро правильноготест-менеджера
  5. 5. Утро обычноготест-менеджера
  6. 6. Утро обычноготест-менеджера
  7. 7. Утро обычноготест-менеджера
  8. 8. Почемупропустили багу??! %#@&!
  9. 9. Реакция обычного тест-менеджера 1. Ищет отмазку для Почему руководства пропустил и багу??! 2. Ищет виноватого и %#@&! даѐт ему в глаз 3. Наводит шухер 4. Сам перепроверяет 5. Заводит баг 6. Проверяет что баг исправлен
  10. 10. Реакция просветлённого тест-менеджера 1.Анализирует Почему пропустил причину пропуска и багу??! %#@&! 2.Ищет решение для исправления 3.Корректирует процесс так, чтобы это больше не повторялось
  11. 11. Как проанализировать причину пропуска? Почему пропустили багу? Не было времени на проверку Почему не было времени? Задержали предыдущую задачу Почему задержали предыдущую? Не было вовремя необходимого оборудования Почему не было оборудования? Тест-менеджер забыл его вовремя заказать Почему забыл заказать? На проекте не ведѐтся планирование «железа»
  12. 12. Как проанализировать причину пропуска?Причина ДействиеМы не знали, что какая-то • Анализ продуктаопция, настройка, условие • Анализ кода (white box и code coverage)влияют на работу • Согласование тестов с разработчиками и аналитикамиНе учли комбинацию • Анализ зависимостейвзаимозависимых • PairwiseпараметровБаг появился за несколько • Повысить регулярность regressionсборок до релиза, не • Автоматизацияуспели протестировать • Совместная с разработчиками приоритезация тестовТест был отброшен / • Составление ментальной модели пользователяотложен из-за низкого • Выяснение «Как используется наш продукт вприоритета боевых условиях?»Человеческий фактор, баг • Донести ответственность до сотрудниковпросто пропустили • Узнать причину (квалификация / мотивация) и работать над решением корня проблемы
  13. 13. Опятьдубликат!#${%%#!&!
  14. 14. Реакция обычного тест-менеджера Ты почему опять завёл дубликат??! Сколько можно учить пользоваться поиском? %#@&!
  15. 15. Реакция просветлённого тест-менеджераУсловие ДействиеМаленькая команда, • Настроить отправку писем по каждому новомупростой продукт дефекту всей команде • Ввести теги, компоненты, области ПО в баг- трекере – всѐ для удобства поиска • Шаблон заголовка дефекта для удобства нахожденияБольшая команда, • Назначить ответственных модераторов за каждуюсложный продукт область функционала • Ввести премодерацию дефектов, так чтобы все баги по одной области проходили через одного человекаМного подпроектов • Ответственные по проектам с премодерацией
  16. 16. Ничего непонимаю, что они имели в виду в этом баге??? #${%%#!&!
  17. 17. Реакция обычного тест-менеджера Ты почему опять завёл баг через одно место??! Сколько можно говорить что их надо заводить правильно? %#@&!
  18. 18. Реакция просветлённого тест-менеджераУсловие ДействиеПростой продукт, • Совместный разбор спорных, сложных дефектовмаленькая командаСложный продукт • Анализ причин, влияющих на баги: настроек и параметров • Проведение внутренних тренингов по локализации багов и по архитектуре продукта • Шаблоны дефектов, правила «что должно быть в баге обязательно» • Наставники по заведению дефектовБольшая команда • Оценки в баг-трекере (проставляются разработчиком в момент исправления) • Анализ оценок, слабых мест, что нужно улучшать • Внедрение роли «дефектный контроллѐр» 
  19. 19. Продукт выпущен. Багов нет. Пользователи не довольны.
  20. 20. Реакция обычного тест-менеджера 1.А при чѐм тут тестировщики? 2.Не, ну правда, мы тут совсем не при чѐм!
  21. 21. Реакция просветлённого тест-менеджера1. Анализ причин 2. Учѐт результатов анализа • С • Тестирование требований аналитиком, внедрен • Обсуждение улучшений с цем, РМ’ом проектной командой • Самостоятельно – • Переход тестирования в через QC анкетирование, набл юдение, опросники
  22. 22. Любая проблема должна бытьпроанализирована и решена. Навсегда.
  23. 23. Главные отличия между ОТМ и ПТМ
  24. 24. Рабочий день обычного тест-менеджера У меня очень много дел! Отстаньте все от меня!
  25. 25. Рабочий день просветлённого тест-менеджера1. Ежедневный анализ: что важно, а что нет?2. Какие текущие приоритеты?3. Что из моих задач можно делегировать?
  26. 26. Реактивность – реакции на внешние воздействия
  27. 27. Проактивность – самостоятельное принятие решений, управление
  28. 28. Выводы для ПТМ1. По каждой проблеме – анализ причин и превентивные меры2. По каждой цели – выработка метрик для своевременных изменений3. Каждый день – вопрос: что нужно улучшить сегодня, чтобы не было проблем завтра?

    Be the first to comment

    Login to see the comments

Наталья Руколь - доклад на SQA Days, 2-3 декабря 2011, Москва

Views

Total views

1,922

On Slideshare

0

From embeds

0

Number of embeds

739

Actions

Downloads

64

Shares

0

Comments

0

Likes

0

×