Наиболее дешевый способ разработки - это тот, где артефакты за ОДНУ итерацию попадают в использование к клиенту. Без 10+ итераций доработок из-за найденных ошибок. В докладе мы рассмотрим набирающий популярность на западе подход shift left testing. Его цель - предотвращение возникновения ошибок, а не привычный для многих поиск уже сделанных ошибок в ПО. Тестирование со сдвигом влево предполагает, что тестирование и разработка работают в тандеме и, как следует из названия, тестирование переносится на самые ранние этапы разработки. - Вы узнаете зачем нужно тестировать требования и документацию. А также рассмотрим какие инженерные практики помогают сделать это частью культуры в команде. (code review, pull request, spec by example, bdd, atdd) - Рассмотрим какие виды автоматизированных тестов и когда нужно писать, дабы уменьшить количество ручных тестов на поздних этапах разработки продукта. (tdd, bdd, atdd, компонентные и интеграционные тесты) - Разберем как изменяются совместные командные активности и функциональные обязанности каждого члена команды. (Планирование, грумминг, ретроспектива, демо, dsm, составление тестовой стратегии, планирование тестирования). - Вспомним почему так важно проектировать тестовую модель с использованием практик тест-дизайна, а не полагаться только на исследовательское тестирование. Вспомним тестирование потока управления, циклов, потоков данных. Рассмотрим на практических примерах, почему разработчикам необходимо осваивать навыки тест-дизайна. - В завершение рассмотрим один из способов подсчета test coverage и чем оно отличается от code coverage. В качестве примера нарисуем граф требований и проверим покрытие тестовой модели. Весь доклад будет рассмотрен на примере тестирования очень простого приложения, состоящего из одного микросервиса, БД и WEB-странички. Shift left testing лежит в основе методологий Agile и DevOps.

1. SHIFT LEFT TESTING
FOUNDER QADOJO & COACH AT ALFA BANK
АСЕЕВА-НГУЕН АНАСТАСИЯ

2. Обо мне
Создатель QA сообществ в Telegram
@qa_ru, @qa_jobs и @qaevents
Тренер agile testing,
эксперт в инженерных практиках
В QA c 2012 года, в IT с 2007 года
Спикер на QAFest2016
и XPDays2016, TestCon2017,
TestCon2018, SQADays2017,
AgileDays2018, DUMP2018, Delex
Chatter

3. travieso.me
@travieso_nastya
Обо мне

10. Нулевая
терпимость
к багам

11. Release
Cost to
fix a bug
CONCEPT DESIGNREQUIREMENTS DEVELOPMENT TESTING RELEASE/MAINTENANCE

12. Каким образом
"сдвиг влево"
уменьшает затраты?

13. Меньше багов -
меньше стоимость
разработки

14. Release
Cost to
fix a bug
CONCEPT DESIGNREQUIREMENTS DEVELOPMENT TESTING RELEASE/MAINTENANCE

15. Release
Cost to
fix a bug
CONCEPT DESIGNREQUIREMENTS DEVELOPMENT TESTING RELEASE/MAINTENANCE
Стоимость бага

16. Затраты на исправление бага
1. Обработка звонков в колл-центр
2. Обработка звонков в отдел технической поддержки
3. Передача бага на исправление
4. Погружение новой команды в контекст для исправления
бага
5. Исправление бага
6. Установка новой (исправленной) версии продукта
7. Исправление репутационных рисков
8. Коммуникации со СМИ
9. Судебные процессы

17. Затраты на исправление бага
Недополученная прибыль - ресурсы, которые можно было
потратить на реализацию фичи - потратили на
исправление бага

18. Исправлять баги
дорого

19. Наиболее дешевый способ
разработки - если
жизненный цикл артефакта
длится
не более 1 итерации

21. ТЕСТИРОВАНИЕ ЧАСТЬ
ПРОИЗВОДСТВА

22. Э. Дэминг ("Выход из кризиса"), 1984г

23. Release
Cost to
fix a bug
CONCEPT DESIGNREQUIREMENTS DEVELOPMENT
TESTING
RELEASE/MAINTENANCE

25. Не экономьте
на исправлении дефектов -
предотвращайте их

26. МИНИМИЗИРУЕТ РИСКИ
СО СРОКАМИ В AGILE

27. ПРЕДОТВРАЩАТЬ ОШИБКИ
ВЫПУСТИТЬ РЕЛИЗ В СРОК
УСКОРИТЬ РАЗРАБОТКУ
ВЫЯВИТЬ СКРЫТЫЕ ТРЕБОВАНИЯ

28. SHIFT LEFT TESTING

29. NOOOOOOO!

30. Spec by Example
TDD
ATDD
BDD

32. ПОИСК БАГОВ
ПРЕДОТВРАЩЕНИЕ
БАГОВ
БОЛЬШЕ ЧЕМ
МЫ ЦЕНИМ:

33. ТЕСТИРОВАНИЕ
В КОНЦЕ
ТЕСТИРОВАНИЕ
В ПРОЦЕССЕ
БОЛЬШЕ ЧЕМ
МЫ ЦЕНИМ:

34. ОТВЕТСТВЕННОСТЬ
ТЕСТИРОВЩИКА
КОМАНДНУЮ
ОТВЕТСТВЕННОСТЬ
ЗА КАЧЕСТВО
БОЛЬШЕ ЧЕМ
МЫ ЦЕНИМ:

35. ПРОВЕРКИ
ПО СКРИПТАМ
ТЕСТИРОВАНИЕ
ПОНИМАНИЯ ПРОДУКТА
БОЛЬШЕ ЧЕМ
МЫ ЦЕНИМ:

38. Shift Left Testing
помогает приблизиться к
1й итерации для достижения
качественного продукта

39. MEOWLE =>
СЕРВИС ДЛЯ
ПОИСКА ИМЕНИ
КОТИКУ

40. Пользовательские истории
Я как пользователь хочу найти различные варианты
имен по буквосочетанию
Я как пользователь сервиса могу добавить свой
вариант имени, если такого имени еще не существует
Я как пользователь хочу видеть поисковую выдачу
сгруппированную по заглавным буквам
Я как пользователь хочу видеть количество
результатов поисковой выдачи
Я как пользователь хочу видеть количество
результатов поисковой выдачи в каждой группе

41. Введите текст для поиска
Найти!

42. иголка
группа имен 1
группа имен 2
имя 1 имя 2 имя 3
имя 1

43. иголка
Ничего не нашли :(
Добавить!

45. 120 минут
- цена ручного тестирования
в chrome/opera/mozilla/safari

46. 14 часов ~ 840 минут
- цена тестирования после написания кода

47. БАГИ...

48. Если в строке поиска ввести составное имя с пробелом между
символом и именем - поиск ничего не найдет. Например: - Alp.
Если ввести символ и буквы без пробела в поисковую выдачу
попадут результаты, которые не должны попадать. Например: -Alp
Точное соответсвие из БД в виде составного имени из трех слов
не находит. Пример запроса: "Eliana-Eliyana-Eliauna"
На поисковый запрос "1" выдается некорректный результат
Неправильно обрабатывается поисковый запрос из двух слов, если
в имени более 2 х слов без символ

49. При отправке пустого поискового запроса - выдается страница со
всеми именами. Отсутствует какая-либо валидация.
Если добавляешь имя с маленькой буквы, то потом в поисковую
выдачу оно попадает тоже с маленькой буквы.
Пару рах словили ситуацию, что needle не передался как параметр
в поисковую строку (^^ программист забыл поправить)
UX-замечания: отсутствуют ховер-подсветки и сообщения-подсказки
для UI-компонент

50. РЕКОМЕНДАЦИИ
ПО-УЛУЧШЕНИЮ

51. УЛУЧШАЕМСЯ...
Если в запросе есть в начале есть цифры, то их нужно обрезать
Сохранять с обрезанием пробелов до и после поискового запроса
Имена не могут начинаться с символов. Обрезать символы в начале
и в конце имени при сохранении в базу данных.
При добавлении нового имени в базу данных с маленькой буквы, на
страницу поисковой выдачи имя должно возвращаться с большой
буквы.

52. "УМЕНЬШАЕМ КОЛИЧЕСТВО РУЧНОГО ТЕСТИРОВАНИЯ -
ТЕСТИРУЕМ СРАЗУ В КОДЕ"
1-Й СДВИГ ВЛЕВО
Release
CONCEPT DESIGNREQUIREMENTS RELEASE/MAINTENANCEDEVELOPMENT TESTING

53. UI workflow
/results
/no-results
/index

54. Architecture
browser UI API DB
renders PUG
to HTML
search
add

55. UI component 1
input : needle button : submit

56. UI component 2
title : группы names : array count : имён

57. /no-results/results/index
UI components usage
component 1
component 1 component 1
component 2
component 2
...

58. обработчик
searchName()
Поиск клички по подстроке
groupAndSortNames()
POST /api/search
{ needle }
{groups[{names}]}
NeDB

59. обработчик
createNewName()
Добавление новой клички
POST /api/add
{ name }
{ name }
NeDB

60. Выбранные инструменты
PUG JS JEST
CODECEPTJS

61. КВАДРАНТЫ ТЕСТИРОВАНИЯ

62. Q2
Q1 Q4
Q3
Направляющиеразработку
Критикующиепродукт
Бизнес-ориентированные
Технологичные
•Интеграционные тесты
•Модульные тесты
•Компонентные тесты
•Тесты сетевого
подключения
•Исследовательское
тестирование
•Системная интеграция
•Юзабилити-тестирование
•Приемочное тестирование
• WorkFlow
•Нагрузочное тестирование
•Тестирование
производительности
•Тестирование безопасности
•Тестирование доступности
ПРЕДОТВРАЩАЮТ
ПОЯВЛЕНИЕ
БАГОВ
ДО И ВО ВРЕМЯ
КОДИРОВАНИЯ
• Acceptance тесты
• Функциональные тесты
• Примеры
• A/B тесты
• UX тестирование
• Тестирование прототипов

63. ПИРАМИДА АВТОМАТИЗАЦИИ
ТЕСТИРОВАНИЯ В AGILE

64. ПРИ
ТРАДИЦИОННОМ
ТЕСТИРОВАНИИ

65. ПИРАМИДА ПРИ
SHIFT LEFT TESTING

66. ТЕСТИРОВАНИЕ
ПРОИЗВОДИТЕЛЬНОСТИ

67. ТЕСТИРОВАНИЕ
БЕЗОПАСНОСТИ

69. РАСПРЕДЕЛЕНИЕ ПО $ И КОМАНДЕ
UI TESTS
QA & ANALYST
WORKFLOW TESTS
DEVELOPERS & QA
INTEGRATION TESTS
DEVELOPERS & QA
COMPONENT TESTS (BUSINESS LOGIC)
DEVELOPERS
UNIT TESTS
DEVELOPERS
Затраты Время

70. С
С
ВСЕГО 34 ТЕСТА, ВЫПОЛНЯЮТСЯ ЗА 5 СЕКУНД
РАСПРЕДЕЛЕНИЕ ТЕСТОВ ПО ПИРАМИДЕ
E2E TESTS
2 Т
INTEGRATION TESTS
10 Т
UNIT TESTS
20 Т
UI TESTS
2 Т
browser
UI
API
DB

71. SPEC BY EXAMPLE
SBE

72. SCOPE РАБОТ
КЛЮЧЕВЫЕ ПРИМЕРЫ
ЖИВАЯ
ДОКУМЕНТАЦИЯ
ЦЕЛЬ ПРОДУКТА
ОЖИДАЕМЫЙ ЭФФЕКТ
СПЕЦИФИКАЦИЯ ПРИМЕРАМИ
ИСПОЛНЯЕМАЯ
СПЕЦИФИКАЦИЯ

73. ‣ Given-When-Then
‣ Таблицы
вход-выход (сравнивают
ожидаемый результат)
скрипты (для длинных
процессов-предусловий)
таблицы запросов (для
работы с массивами)
‣ Ключевые слова
Форматы
примеров

76. ВНЕЗАПНО...
Разработчик сделал поиск
по ID, а не по name в BD
Выяснила, что необходимо
экранировать regex в
поисковом запросе

77. НЕПОНЯТНО НАСКОЛЬКО МАЛЕНЬКИМИ ДОЛЖНЫ БЫТЬ
ТЕСТЫ
ПИШУТСЯ ТЕСТЫ, КОТОРЫЕ ПЫТАЮТСЯ "ПОДОЙТИ"
ПОД УЖЕ СОЗДАННОЕ ПРИЛОЖЕНИЕ
КОГДА НЕ ПОНЯТНО КАК ТЕСТИРОВАТЬ - ПРОЩЕ
ВООБЩЕ НЕ ПИСАТЬ ТЕСТ
ЕСЛИ ТЕСТ СЛОМАЛСЯ - ПЫТАЮТСЯ ПОЧИНИТЬ ТЕСТ,
А НЕ ПРИЛОЖЕНИЕ
МИНУСЫ

78. ПЛЮСЫ
Уменьшили количество
ручного тестирования
Сократили петлю обратной
связи для обнаружения бага
"Живая" документация
Рефакторинг системы

79. УМЕНЬШАЕМ ПЕТЛЮ ОБРАТНОЙ СВЯЗИ -
ПРИЕМКУ ДЕЛАЕМ НА ЛОКАЛЬНОЙ СТАНЦИИ РАЗРАБОТЧИКА"
1.1-Й СДВИГ ВЛЕВО
Release
CONCEPT DESIGNREQUIREMENTS RELEASE/MAINTENANCE≠≈ TESTING

80. РАЗРАБОТЧИК - ТЕСТИРОВЩИК
ПАРНЫЕ СЕССИИ

81. 1.Составьте список задач,
выполнить которые необходимо
перед работой в паре
Изучите верхнеуровную
архитектуру продукта
Изучить основы работы с
IDE , с которой работают
в вашей команде
2.Используйте свои сильные
стороны в парной сессии
Подготовка!

82. Станция для парной сессии
- залог успеха

84. Чтоб запустить эту практику -
покажи успешный пример ее
использования
Истории из беклога -
«обычная» работа
разработчика.
Написание и выполнение
исследовательских миссий по
разработанным историям
Получи поддержку для
проведения парных сессий
Задайте цель для парной сессии
Будье
храбрыми!

85. Договоритесь о формате
парной сессии
>>>
Практика
парных
сессий

88. Договоритесь о формате
парной сессии
Используйте псевдокод для
тестов
>>>
Практика
парных
сессий

89. REPEAT
OUTPUT 'What is the best subject you take?'
INPUT user inputs the best subject they take
STORE the user's input in the answer variable
IF answer = 'Computer Science' THEN
OUTPUT 'Of course it is!'
ELSE
OUTPUT 'Try again!'
UNTIL answer = 'Computer Science'
ПСЕВДОКОД

90. ПСЕВДОКОД

91. Договоритесь о формате
парной сессии
Используйте псевдокод для
тестов
Практика
парных
сессий
Делитесь пониманием!
Будьте как QA - задавайте
вопросы!
Разные пути для добавления
ценности

93. Делайте перерывы!

94. Создавайте доверительные отношения!

95. Завершение парной сессии
Проведите мини-ретро внутри пары
Расскажите на dsm о результатах

96. 2-Й СДВИГ ВЛЕВО
Release
CONCEPT DESIGNREQUIREMENTS RELEASE/MAINTENANCEDEVELOPMENT TESTING
"УМЕНЬШАЕМ КОЛИЧЕСТВО РУЧНОГО ТЕСТИРОВАНИЯ -
ТЕСТИРУЕМ ДО НАПИСАНИЯ КОДА"

97. TDD + ATDD

98. AcceptanceTDD
DeveloperTDD
Add new
acceptance test
Run
the acceptance tests
Make
a little change
Run
the acceptance tests
Add new
developer test
Run
the developer tests
Make
a little change
Run
the developer tests

100. Как водитель с загоревшейся лампочкой бензина я хочу быстро найти
ближайшую хорошую заправку, чтобы заправиться качественным бензином.
Критерии приемки:
1.Как водитель с загоревшейся лампочкой я могу просмотреть все
ближайшие заправки.
2.Как … я могу выбрать заправки подходящих мне брендов АЗС.
3.Как … я могу видеть ближайшие заправки выбраннах брендов списком.
4.Как … я могу видеть ближайшие заправки выбранных на карте.
Обработка ошибок:
1. При выключенной геолокации пользователя необходимо дать ему
информацию о том, где ее включить.
Примеры истории с критериями

101. Абстрактные
Добросовестные
Сплоченные
Независимые
Понятные
Не дублируемые
Зеленые
Принципы
тест-дизайна
приемочных
критериев

102. Как выбрать фреймворк
1. Записать примеры в разных форматах на одну историю.
2. Собрать фидбек от "трех"
3. Выбрать формат для формализации примеров
4. В зависимости от выбранного формата - выбрать
инструмент для автоматизации спецификаций (и
используемого ЯП в команде)

104. КАК НЕ ДОПУСКАЮТСЯ
ДЕФЕКТЫ?

105. Fix defects
Feature
with
examples
User
story
High level
AT
Expand
tests
Automate
tests
Code & execute
tests
Exploratory
testing
Accept
story
Other
testing
Explore
examples

106. 3-Й СДВИГ ВЛЕВО
Release
CONCEPT DESIGNREQUIREMENTS RELEASE/MAINTENANCEDEVELOPMENT TESTING
"ИЗБАВЛЯЕМСЯ ОТ РУЧНОГО ТЕСТИРОВАНИЯ -
ТЕСТИРУЕМ ДО НАПИСАНИЯ КОДА"

107. BDD

112. 4-Й СДВИГ ВЛЕВО
"СОЗДАЕМ ТО, ЧТО НУЖНО КЛИЕНТУ -
А/B ТЕСТИРОВАНИЕ, ТЕСТИРОВАНИЕ КОНЦЕПТА"
Release
CONCEPT DESIGNREQUIREMENTS RELEASE/MAINTENANCEDEVELOPMENT TESTING

114. 1.Выпишите ВСЕ тестовые активности
на общую доску с задачами в вашем
спринте.
2.Уберите стадию тест. Вывешивайте
задачу в WIP, только когда кто-то
над ней работает
3.Тесты должны находиться в
легкодоступном для команды месте
4.Код с автотестами должен
находиться в репозитории продукта
5.Встройте проверки на качество в
CI/CD
ЧТО СДЕЛАТЬ
ВПЕРВУЮ
ОЧЕРЕДЬ?

115. Каждый член команды
несет равную
ответственность
за качество продукта

116. ‣ Изменение майндсета
‣ Высокий уровень совместной
командной работы
‣ Тщательно спланируйте и
договоритесь с командой о шагах
внедрения стратегии тестирования
‣ Встройте QA в процесс разработки
‣ Побудите разработчиков писать тесты
на свой код
‣ Создайте механизм непрерывной
обратной связи: CI/CD, тесты в коде
‣ Парные сессии "тестировщик-
разработчик"
‣ Регулярно проводите аудиты процесса
с ретро для команды
Гайд
внедрения
SLT

117. SLT - это смена мышления
и обмен навыками
тестирования
со всеми членами команды.

118. А НА ДЕСЕРТ ...

119. Тестовые активности
• КОМАНДНЫЕ ВСТРЕЧИ И

120. ТЕСТОВЫЕ АКТИВНОСТИ
КОМАНДНЫЕ ВСТРЕЧИ И

121. Исследование продукта
(Product Discovery)
✓ ТЕСТИРОВЩИК УЧАСТВУЕТ в создании
story map
✓ Помогает бизнесу определить
приемочные критерии для каждого
уровня в story map

122. Планирование релиза
(Release Planning)
КОМАНДА:
✓ Формирует пирамиду автоматизации тестирования
✓ Выбирают инструмент для автоматизации
✓ Договариваются о том, какие виды тесты им
необходимо выполнять для создания
качественного продукта
✓ Договариваются о том, кто какие тесты пишут
✓ Определение DOD(критериев готовности) для
релиза
✓ Выбирают метрики качества
✓ Обсуждают риски и критичные сценарии
✓ Договариваются о ревью тестовой модели

123. ТЕСТОВЫЕ АКТИВНОСТИПланирование спринта
✓ Описать приемочные критерии для истории
✓ Описать Workflow тесты
✓ Провалидировать приемочные критерии для задач в
истории
✓ Совместно определить зависимости и
задокументировать их
✓ Обсудить набор интеграционных тестов
✓ Оценка задач с учетом тестовых активностей

124. ТЕСТОВЫЕ АКТИВНОСТИ
PBR
✓ Обсудить истории с применением подхода
"силы трех"
✓ Использовать модель с квадрантами для
планирования всех видов тестов
✓ Помочь PO определиться с желаемым
поведением системы с помощью вопросов,
рассматривающих крайние случаи

125. ТЕСТОВЫЕ АКТИВНОСТИ
Ф
Спринт
✓ Парные сессии "разработчик-тестировщик"
✓ Разработка всех тестов на всех уровнях
✓ Автоматизация приемочных критериев
✓ Исследовательское тестирование
✓ Совместное написание и разработка
приемочных тестов (бизнес +разработка)
✓ UI-автоматизация
✓ Тестирование производительности
✓ Ревью тестовой модели каждым членом команды

126. ТЕСТОВЫЕ АКТИВНОСТИ
DSM
✓ Вырабатываются правила реагирования на
дефект
✓ На dsm команда следит за тем, чтобы не было
«покрывательства» на невыполненную задачу
✓ Этап ревью тестовой модели каждым членом
команды визуализирован

127. ТЕСТОВЫЕ АКТИВНОСТИ
Обзор спринта
✓ Показать демо
✓ Убедиться что доставили бизнес-
ценность и клиенту это нужно
✓ Собрать обратной связи
✓ Идентифицировать проблемы тестирования
и подумайте о способах их устранения

128. ТЕСТОВЫЕ АКТИВНОСТИ
Ретроспектива
✓ Обсудить результаты парных сессий и
исследовательского тестирования
✓ Проверить метрик качества
✓ Составить Action plan по улучшению
качества продукта