Николай Москаленко «Как разработчику находить максимум багов за минимум времени»

Поговорим о том, почему разработчику следует тестировать свое приложение до того, как за дело возьмутся тестировщики. Разберем технику тестирования, адаптированную специально для разработчиков. Рассмотрим, как с помощью нее можно быстро проверить свой код и найти в нем дефекты. Определим, какие тесты следует писать в первую очередь, и как сэкономить время, не проверяя 100500 лишних комбинаций в тестовых сценариях. Также поговорим об инструментах и практиках, позволяющих повысить читаемость автотестов на JavaScript и упростить их поддержку в дальнейшем.

Transcript

1. Как разработчику находить максимум багов за минимум времени? Николай Москаленко
2. Проблема Каждый баг, допущенный разработчиком, порождает дополнительные итерации взаимодействия между членами команды.
3. Каждый баг порождает дополнительные итерации взаимодействия между разработчиком и тестировщиком Разработчик Тестировщик баг-репорт фича с багами исправление бага вопросы по баг-репорту ответы на вопросы по баг-репорту баг исправлен не полностью
4. Каждый баг, допущенный разработчиком, не зависимо от его критичности дополнительно утилизирует ресурсы команды, а также увеличивает время доставки продукта до прода.
5. Решение Разработчику следует тестировать свой код до того, как за дело возьмется тестировщик.
6. У разработчиков и тестировщиков разные цели тестирования
7. Тестировщик в тестировании Цель - найти баги до того, как их найдут пользователи. Важно качество багов!
8. Разработчик в тестировании Цель - найти баги до того, как их найдут тестировщики. Важно количество багов! Но почему?
9. Разработчик: “Я не могу тратить много времени на тестирование, к тому же я не умею тестировать.”
10. Сколько времени разработчик готов потратить на тестирование? 15 минут? Час? Два? Не вопрос! Давайте отталкиваться от того количества времени, которым вы располагаете!
11. Научиться тестировать можно за 30 минут Ликбез по тестированию для разработчиков
12. Как разработчику следует понимать, что такое тестирование? Это эксплуатация программного обеспечения с целью нахождения дефектов.
13. В чем разница между мышлением тестировщика и разработчика? Разработчик может посмотреть исходный код, ведь чаще всего он его и писал. “Зачем я буду это тестировать, если я вижу, что в коде все ОК?” Тестировщик любое ПО воспринимает, как черный ящик. Он выполняет в приложении набор сценариев и сравнивает ожидаемый результат с фактическим. “По умолчанию все работает НЕКОРРЕКТНО, пока я не удостоверюсь в обратном” Наша задача - найти баланс между этими двумя подходами.
14. Что такое баг? Это несоответствие фактического результата работы программного обеспечения ожидаемому.
15. Как тестировать быстро и находить много багов? Писать юнит-тесты? Интеграционные? End-to-end? Тестировать вручную?...
16. Как тестировать быстро и находить много багов? Писать юнит-тесты? Интеграционные? End-to-end? Тестировать вручную?...
17. Это не важно! Вид тестирования - это всего лишь инструмент поиска багов. Ключ к быстрому нахождению багов - определять “правильные” тестовые сценарии. Как тестировать быстро и находить много багов? Писать юнит-тесты? Интеграционные? End-to-end? Тестировать вручную?
18. Какие тестовые сценарии “правильные” для разработчика? Это тест-кейсы, которые: 1. находят баги 2. их можно быстро написать и выполнить 3. поддаются автоматизации Поговорим об этом более подробно на примере приложения.
19. Пример приложения
20. Разработчик: “У меня нет времени проверять 100500 комбинаций. Пусть это делает тестировщик”
21. Разработчик, используй подход S.C.A.R.E. и пиши только те тест-кейсы, которые вероятнее всего найдут баги за минимальное время.
22. S Spots C Common scenarios A Alternative scenarios R Ranking E Equivalence
23. S spots Определяем места в приложении, где наибольшая вероятность появления багов с помощью экспертной оценки и разделения функционала на блоки. Используем экспертную/статистическую оценку вероятности нахождения бага. По моему опыту, ТОП 3 мест с наибольшим кол-вом багов - это: 1. обработка пользовательского ввода 2. взаимодействие с внешними интеграционными точками 3. бизнес-логика (условия, расчеты) В нашем случае это будут: валидатор, взаимодействие с бэк-системой.
24. C common scenarios Выделяем основные сценарии, т.е. сценарии наиболее часто используемые со стороны пользователей. Например, в большинстве случаев, пользователи будут вводить свой существующий логин. Чаще всего встречается логин из 8-12 латинских символов в нижнем регистре. Составляем список тест-кейсов на основные сценарии: • Ввод логина стандартной длины с использованием наиболее типичных комбинаций символов • Обработка ответа от бэк-системы, в случае, если пользователь найден • Работа UI в самом часто используемом браузере и разрешении экрана
25. A alternative scenarios Выделяем альтернативные сценарии, т.е. сценарии которые будет выполнять меньшая часть пользователей, а также сценарии, провоцирующие систему на ошибку. Например, указание несуществующего логина, а также логина нестандартной длины или с редкой комбинацией символов. Также помним, что бэк-система может вернуть сообщение в некорректном формате. Составляем список тест-кейсов на альтернативные сценарии: • Ввод логина нестандартной длины с использованием редких комбинаций символов • Обработка ответа от бэк-системы, в случае, если пользователь НЕ найден • Обработка некорректного ответа от бэк-системы • Работа UI в альтернативных браузерах и нестандартных разрешениях экрана
26. R ranking Ранжируем получившиеся тест-кейсы. Сортируем их по вероятности нахождения бага, функционалу, трудоемкости выполнения/написания. В результате из всего списка отбираем ТОП N тест-кейсов, которые: • с наибольшей вероятностью найдут баги • затрагивают разные блоки функционала • наименее трудоемкие для выполнения/написания • наиболее приоритетные
27. E equivalence Это одно или несколько значений тестовых данных, к обработки которых программное обеспечение применяет одинаковую логику. Разбиваем тесты на классы эквивалентности с сокращением их числа, но с сохранением покрытия требований. За счет этого отсеивается огромное количество значений тестовых данных, использовать которые бессмысленно. Пример комбинации нескольких классов эквивалентности в одном тесте: символы латинского алфавита в нижнем и верхнем регистре с цифрами, тире и нижним подчеркиванием длиной 32 символа.
28. Разработчик: “А есть ли способ написать 50 тестов, но при этом потратить времени, как если бы я написал 10 тестов?”
29. BDD подход с использованием библиотеки jest-cucumber
30. Feature-файл с таблицей параметров тестовые данные
31. Реализация теста с помощью jest-cucumber
32. Feature-файл, где есть взаимодействие с UI
33. Реализация теста с помощью jest-cucumber
34. Демо
35. Разработчик: “Есть ли способ выполнить тест, если бэк-система не возвращает необходимые данные/недоступна”
36. Используйте заглушки! “Про это многие знают, но мало кто применяет на практике”
37. Заглушки в юнит-тестах с помощью Jest
38. Заглушить внешнюю точку интеграции - это просто (пример будет изменен под приложение)
39. Демо
40. Итог • Всегда тестируйте свой код перед тем, как отдать его тестировщику. • Для выявления тестовых сценариев, находящих баги за короткое время используйте метод S.C.A.R.E. • Не забывайте использовать заглушки в интеграционных и юнит-тестах - это не сложно. • Попробуйте писать юнит тесты с помощью Gherkin
41. https://github.com/AToutLeMonde/js-testing-sample Ссылка на репозиторий