Доклад на SQAdays весной 2017 в Москве. Страница доклада http://mtsepkov.org/SelfDet Проблема самоопределения, конструирования своего будущего в современном мире становится все актуальнее, в отличие от мира прошлого, в котором ты определялся всего пару раз, выбирая профессию и создавая семью, да и то это часто делали за тебя родители. А сейчас ты должен делать это регулярно, да еще - в быстро развивающемся мире, что особенно заметно в мире IT, на фоне бурного развития технологий. У меня сформировалась сборка из схем, которые помогают это делать.
Доклад на SQAdays весной 2017 в Москве. Страница доклада http://mtsepkov.org/SelfDet Проблема самоопределения, конструирования своего будущего в современном мире становится все актуальнее, в отличие от мира прошлого, в котором ты определялся всего пару раз, выбирая профессию и создавая семью, да и то это часто делали за тебя родители. А сейчас ты должен делать это регулярно, да еще - в быстро развивающемся мире, что особенно заметно в мире IT, на фоне бурного развития технологий. У меня сформировалась сборка из схем, которые помогают это делать.
Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
QA Fest 2015. Игорь Хрол. Автоматизация тестирования: отбрасываем лишнее и пр...QAFest
Наиболее популярный вид тестирования, применяющийся на проектах - это тестирование чёрного ящика. Когда решается задача автоматизации тестирования, чаще всего это происходит ʺв лобʺ - в точности повторяя действия пользователя. Это наиболее понятный и простой путь. Но к сожалению, этот путь очень сильно ограничен в своей области применения.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
Мы обсудим основные виды тестовой документации, зачем и почему они нужны, кратко поговорим о том почему нужны тест планы и в каком виде. Узнаем для каких задач какую тест документацию стоит выбрать. Поговорим об эффективных принципах и подходах к построению наборов тест-кейсов и чек-листов. Затронем тему отчетности и, конечно же, поговорим о типичных ошибках.
QA Fest 2015. Игорь Хрол. Автоматизация тестирования: отбрасываем лишнее и пр...QAFest
Наиболее популярный вид тестирования, применяющийся на проектах - это тестирование чёрного ящика. Когда решается задача автоматизации тестирования, чаще всего это происходит ʺв лобʺ - в точности повторяя действия пользователя. Это наиболее понятный и простой путь. Но к сожалению, этот путь очень сильно ограничен в своей области применения.
QA Fest 2014. Алексей Лупан. Не тест-кейсы красят тестировщика, а...QAFest
- Цепочка документов, которые принуждают тестировщика создавать тест-кейсы;
- Как жить, когда до тест-кейсов "не хватает дыхания";
- В чем разница между "функцией" и "функциональной возможностью", и что из этого требует внимания тестировщика
7 Способы проведения ретроспектив для анализа и улучшения процессаMagneta AI
Ретроспектива играет большую роль в развитии команд, работающих в Agile проектах. В большинстве случаев, успех проекта зависит от того, насколько команда умеет совместно выявлять проблемы и улучшать свою работу от итерации к итерации.
Мы рассмотрим различные практики проведения ретроспектив, обсудим часто возникающие вопросы в организации работы команды и коллективного принятия решения.
Ольга Лужецька - Exploratory testing: Love it or Leave it?DataArt
Є думка, що exploratory testing - це хаотичний процес, яким важко керувати. Ми розберемось, чи можна організувати exploratory testing так, щоб продукт був крутим та якісним, ризики більш передбачувані, а тестувальники отримували задоволення.
В длительной перспективе ретроспективы – самая важная часть гибких процессов. Но очень часто у команд не получается запустить процесс непрерывного улучшения, либо через некоторое время этот процесс обрывается, когда команда думает, что все проблемы решены. Я расскажу не только теоритическую часть, которая позволит преодолеть эти проблемы, но и дам несколько десятков примеров конкретных практик, которые применяются на эффективных ретроспективах. Доклад рассчитан, как на начинающих ретроспективы, так и практиков гибких методологий.
Как поддерживать и развивать пачку "похожих" проектов. Кластер или конгломера...Ontico
Когда в зоне ответственности находятся несколько "похожих" по реализации и/или функционалу технических решений (сайтов, систем, проектов), волей-неволей возникает желание их унифицировать. Плюсы от такого подхода очевидны: это и экономия ресурсов разработки/тестирования/администрирования, и удобство поддержки, и полноценное общее владение кодом для всей команды разработки. Очевидно, что подобная реформа потребует значительных ресурсов и времени, но мы верим, что это "один раз", и принимаемся отстраивать сложную архитектурную конструкцию, призванную удовлетворить требования всех "объединяемых" продуктов.
Если эти продукты не подвержены изменениям, то рано или поздно все закончится хорошо, и у нас получится чудо-фреймворк. Но обычно все совсем не так. Пока мы прорабатываем классы и строим безупречные схемы взаимосвязей, мир меняется: меняются требования к продукту, новые вызовы рынка и видение менеджмента влекут за собой постоянные изменения функционала. То что было сделано вчера уже не соответствует тому, что хотят сегодня.
Это похоже на возведение песочного замка у самой кромки прибоя. В результате трудный путь превращается в изнуряющее топтание на месте, а имеющееся техническое наследие потихоньку ветшает, разрастается казуальным кодом и забирает все больше сил на поддержку.
Но проблема даже не в этом. Основная проблема в том, что мы видим причину неудач в ошибках проектирования или в несговорчивости менеджмента, не желающего пойти на уступки относительно реализации того или иного функционала. Все проще: я убежден, что ошибка была допущена при выборе пути! Но я не призываю смириться и "тащить" на себе кучу сто раз продублированного кода. Истина, как всегда, где-то посередине.
Мы не будем больше собирать все проекты в один кластер, мы попробуем построить конгломерат!
* оценим перспективы унификации и рассмотрим альтернативы;
* рассмотрим типовые препятствия, и откуда они берутся;
* поговорим о сути изменений, и какие они бывают;
* познакомимся с реальностью на основе моего личного опыта;
* обсудим, что есть "похожесть" проектов и что с этим делать.
2. Кто мы такие?
Олег Грабко
Ведущий тест-менеджер
«Лаборатории Качества»
• В тестировании с 2013
• ТМ на ОЧЕНЬ крупном
проекте, о котором мы
расскажем ☺
• Тестировал 20+ проектов
• Управлял тестированием на
6 проектах
Наталья Руколь
Консультант по тестированию
«Лаборатории Качества»
• В тестировании с 2005
• Евангелист и тренер
• Участвовала в 200+
проектов по тестированию
в роли ТМ, консультанта,
тестировщика
• 2500+ выпускников курсов
3. О чём мы расскажем
• Как мы сделали то, что нам
казалось невозможным
• С какими проблемами мы
столкнулись
• Каким образом мы их
анализировали и решали
• Что нам пока что решить не
удалось
4. О проекте
• Крупный федеральный портал
• Распределённая команда
• 80 разработчиков
• 15 аналитиков
• 56 тестировщиков
• 15 различных менеджеров
• 100+ интегрированных подсистем
• ~70 доработок ежемесячно
5. Наши персонажи
Любые совпадения с реальными людьми случайны, и остаются на совести нашего дизайнера Вики
Семён
Руководитель проекта
• 18 встреч с заказчиком в
день
• 314 звонков на мобильный
• Сжатый бюджет
• Сроки горят
Алевтина
Главный заказчик
• Понимает нужды бизнеса
• Не понимает процесс
разработки
• Не всегда чётко
формулирует свои мысли
8. Проблема 1: Ничего непонятно
• Что именно не
устраивает?
• Какие ожидания от
тестирования?
• В чём заключаются
жалобы?
• Кто именно не доволен?
• Субъективность мнений
12. Проблема 1: Ничего непонятно
Алгоритм анализа
• Итеративные опросы
• Личное общение
• Сбор и анализ статистики
• Формирование публичного списка
проблем
• Индивидуальные профайлы для
ключевых управленцев
13. Проблема 1: Ничего непонятно
Формат проведения опросов
• Разбор каждой
негативной оценки
• Уточнение всех
комментариев
• Уговоры на
заполнение
16. Проблема 1: Ничего непонятно
Результат анализа
• Формирование
конкретного списка
проблем
• Формирование KPI
проекта
=> понятно, с чем
работать дальше!
Шампанское?
17. Проблема 2: Команда большая
• Слишком раздутый бюджет
на тестирование
• Соотношение тестирования
и разработки кажется
неоптимальным
• Хочу меньше
тестировщиков!
18. Проблема 2: Команда большая
• Слишком раздутый бюджет
на тестирование
• Соотношение тестирования
и разработки кажется
неоптимальным
• Хочу меньше
тестировщиков!
• И заодно, чтобы результаты
тестирования стали лучше
19. Проблема 2: Команда тестирования – слишком большая!
Опрос заказчика: зачем уменьшать?
• Почему вы считаете, что
это возможно?
• Насколько сильно вы
хотите сократить
команду?
• Откуда эта потребность?
20. Проблема 2: Команда тестирования – слишком большая!
Начинаем анализ!
• За счёт чего можно
сократить количество
людей на проекте?
• Можем ли мы что-то
делать быстрее?
• Можем ли мы перестать
что-то делать?
21. Проблема 2: Команда тестирования – слишком большая!
Куда уходит время?
• Как распределяется
время?
• На какие задачи
уходит больше всего?
• Все ли из этих задач
полезны?
22. Проблема 2: Команда тестирования – слишком большая!
Куда уходит детство время?
23. Проблема 2: Команда тестирования – слишком большая!
Куда уходит детство время?
24. Проблема 2: Команда тестирования – слишком большая!
Анализ муда и мури
• Приходим в гемба и
наблюдаем за
выполнением
повторяющихся
активностей
• Самых частых
• Самых долгих
• Собираем статистику
для анализа «самого
больного»
25. Проблема 2: Команда тестирования – слишком большая!
Ускорение задач
• Заготовки данных
• Подготовка шаблонов
• Автоматизация не
только тестов
• Подготовка окружений
26. Проблема 2: Команда тестирования – слишком большая!
Анализ лишних задач
• Все ли задачи одинаково
полезны?
• Есть ли что-то, что
относится к бесполезным
задачам?
• Что мы можем сделать,
чтобы часть задач вообще
убрать?
27. Проблема 2: Команда тестирования – слишком большая!
Результат решения
• Рост скорости
• Выброшенные задачи
• Сокращение команды
с 56 до <36 человек
Показатель Было Стало
Валидация 1,33 0,4
Обработка
инцидентов
1,5 0,57
28. Проблема 3: Много реджектов
• Тестировщики тратят время на
заведение НЕ дефектов
• Они отвлекают разработчиков на
анализ НЕ дефектов
• Отмененные дефекты попадают в
отчеты, ухудшая там качество версии
29. Проблема 3: Много реджектов
Начинаем анализ
• Так ли много реджектов заводит
команда тестирования?
• Что такое «много реджектов»?
• Разные ли тестировщики их
заводят?
• Какие основные причины
появления реджектов на проекте?
• Сколько мы «высвободим»
времени, поборов реджекты?
30. Проблема 3: Много реджектов
Собираем статистику
• Сколько дефектов отменили
за отчетный период?
• Кто отменил больше всего
дефектов?
• С какой резолюцией
отменили?
31. Проблема 3: Много реджектов
Анализируем причины
• Опрашиваем авторов наибольшего
количества реджектов
• Анализируем резолюции
• Анализируем переписку под
отмененными дефектами
32. Проблема 3: Много реджектов
Результаты анализа
Сводим статистику причин:
33. Проблема 3: Много реджектов
Результаты анализа
Сводим статистику причин:
34. Проблема 3: Много реджектов
Минимизируем незнание функционала
• Работают с функционалом
лишь лица, которые погружены
в него
• Деление на рабочие группы
• Деление ролей
• Единый свод актуальных
версий ЧТЗ
35. Проблема 3: Много реджектов
Оптимизируем поиск в Jira
• Обучение JQL
• Универсальные шаблоны
запросов
• Ключевое поле «Сценарий»
• Единый стандарт заведения
дефектов
36. Проблема 3: Много реджектов
Результаты решения
• Количество реджектов
сократилось с 5% до 1.8%
• Ежемесячный контроль
границы >3%
• Инструкция проведения
мероприятий в случае
превышения границы
42. Проблема 4: Пропускаем слишком много багов
Комплексная стратегия решения
• Статистика в баг-трекере
• Выбор ТОП-проблем
• Распределение людей по
командам
• Ревью ТД аналитиками
• Обучение ТА и ПриОб
43. Проблема 4: Пропускаем слишком много багов
Копаем частности
• Регулярный разбор
• Выяснение нюансов
• Вебинары с анализом
на всю команду
• Обучение на примере
• Тест-Анализу
• Прикладной области
• Рискам качества
44. Проблема 4: Пропускаем слишком много багов
Достижения
• Снижение числа
пропусков
• Рост доверия
• Ещё много
куда расти!
Было Стало
22-25% 11-17%
45. Проблема 5: «Зависают» дефекты на
валидации
• Стабильно на команде тестирования
висит 300 – 400 дефектов
• Есть дефекты, которые «на
валидации» находятся месяцами
• Затраты на валидацию 1 дефекта
составляют 1 ч. 33 мин. (в среднем)
46. Проблема 5: «Зависают» дефекты на валидации
Начинаем анализ
• Почему так много дефектов
«зависает» на валидации?
• Почему так много времени уходит на
их валидацию?
• Как высвободить время для
валидации, где его взять?
• Мы можем валидировать быстрее?
47. Проблема 5: «Зависают» дефекты на валидации
Ищем причины
• Собираем статистические данные:
на ком, как много, как долго
«висят» баги
• Наблюдаем кто как валидирует
(пошагово), записываем тайминги
• Выясняем, когда тестировщик
берется за валидацию дефектов
48. Проблема 5: «Зависают» дефекты на валидации
Результат анализа
• Нет времени на валидацию
• Не знаем как валидировать –
«забиваем» до релиза
• Сейчас берем валидировать только
простые дефекты
• Долго создаем тестовые данные
• Сложно валидировать чужие дефекты
49. Проблема 5: «Зависают» дефекты на валидации
Внедряем решения
• Jira автоматически формирует
именные списки дефектов на
валидацию
• Jira делает «просроченным» дефекты,
висящему на валидации более суток
• Валидируют дефекты только те, кто их
завел (авторы)
50. Проблема 5: «Зависают» дефекты на валидации
Внедряем решения
• Кураторы планируют работы команды
и выделяют на валидацию время
• Распространили в команде шаблоны
запросов для создания тестовых
данных
• Распространили лучшие практики
коллег (напр. скрипты)
• Внедрено SLA
51. Проблема 5: «Зависают» дефекты на валидации
Достижения
• Улучшение показателей
• Повышение гарантий достоверности за
счёт валидации авторами
Показатель Было Стало
Дефектов на
валидации
350+ <70
Сроки
обработки
10 7,5
рабочих часов