Ольга Лужецька - Exploratory testing: Love it or Leave it?
•Download as PPTX, PDF•
0 likes•261 views
Є думка, що exploratory testing - це хаотичний процес, яким важко керувати. Ми розберемось, чи можна організувати exploratory testing так, щоб продукт був крутим та якісним, ризики більш передбачувані, а тестувальники отримували задоволення.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Ольга Лужецька - Exploratory testing: Love it or Leave it?
Similar to Ольга Лужецька - Exploratory testing: Love it or Leave it? (20)
More from DataArt
More from DataArt (20)
Ольга Лужецька - Exploratory testing: Love it or Leave it?
- 2. New York USA London UK Munich Germany Zug Switzerland Exploratory Testing: Love it or Leave it?
- 3. About Me Olga Luzhetskaya DataArt Odessa • Project Manager, Senior QA Engineer • In love with IT since 2011 • Mentor and IT School tutor • Professional Scrum Master • ISTQB CTFL, ISTQB CTAL-TM 3
- 4. Introduction to Exploratory Testing
- 5. Exploratory Testing – What’s it All About? • Знакомство с приложением • Дизайн тестов • Тестирование 5
- 6. One More Way to Think of it James Bach: ”Exploratory Testing is Like Puzzle” • Рассмотреть картинку целиком – оценить объем работы • Выбрать стратегию и тактику • Покрыть тестами – деталями паззла 6
- 7. How About Motivation? Adam Howard, Assurity Courses, 2014 7 День 1 Exploratory testing День 2: Тест-кейсы День 3: Exploratory testing
- 8. «Survivorship Bias» - «Ошибка выжившего» • Поиск общих шаблонов среди «выживших». • Но ведь не менее важная информация осталась среди «погибших»! Что делать? • Спрашиваем: «А что, если?» • Рассматриваем вопрос со всех сторон 8
- 9. What if We Are Agile? • Находит дефекты, пропущенные другими видами тестирования • Коммуникация в команде помогает найти больше разных багов • Тесты дают полезную и неожиданную информацию о продукте • Принцип «working software over comprehensive documentation» • Полезный и более быстрый фидбэк. 9
- 11. Get it Classified • Вспоминаем прошлые баги и проблемы • Анализируем проблемы (root cause analysis) • Определяем возможные узкие места • Генерация идей по тестированию 11
- 12. Create Your Test Charter Explore (target) With (resources) To discover (information) 12
- 13. Test Charter Examples Explore input fields with JavaScript and SQL injection attacks to discover security vulnerabilities Explore catalog features with 100+ products to discover problems with browsing and searching 13
- 14. Time Box • Ограниченное время • Не меньше 90 минут • Не прерывать исследователя 14
- 15. Review Results • Оцениваем найденные дефекты • Чему мы научились в ходе тестирования? • Анализируем покрытие 15
- 16. Finalize it Beautifully • Пишем выводы и отчеты • Сверяемся с задачами Test Charter • Нужно ли дополнительное тестирование? • Обновляем традиционные кейсы 16
- 17. Okay. Give me tips and tricks!
- 18. Like Sherlock Найти и проверить: • Участки приложения, не охваченные тест-кейсами • Участки кода, не покрытые юнит-тестами • Участки, которые игнорируются (сложные, непопулярные, старые, неинтересные • Non-defaults 18
- 19. Exploratory Testing Tours • The Guidebook Tour • The Museum Tour • The Couch Potato Tour • The Supermodel Tour • The Obsessive-Compulsive Tour 19
- 20. Set Your Own Mission Например: • Решить, готов ли продукт к релизу • Найти хотя бы 1 баг • Найти больше всех багов 20
- 21. Two Heads Are Better • Проверять друг друга • Генерировать идеи • Разделять задачи • Вместе проходить сложные участки 21
- 22. What About Documentation? • Тестовое покрытие – какие области покрыты и насколько полно • Риски - определить основные и проверить, какие покрыты • Выполнение тестов – записать свои действия, чтобы можно было повторить • Вопросы, проблемы – все, с чем потребуется разбираться дополнительно 22
- 23. It Can not be That Simple, Can it?
- 24. Exploratory Challenges • Изучать приложение • Воспроизводить ошибку • Решать, какие инструменты использовать • Выбирать лучшие идеи для тестирования • Писать хорошие отчеты • Записывать все шаги во время тестирования • Определить, когда заканчивать тестирование 24
- 25. And One More – Patterns From Nothing Лжепаттерны • Придуманная зависимость мешает повторить баг • Попытки подтверждения шаблона уводят в сторону от основной задачи 25
- 26. That Seems to be a Risky Deal!
- 27. Defining Risks • Как человек может пострадать, понести ущерб, раздражиться? • Как может снизиться стоимость нашего продукта в его глазах? 27
- 28. Acceptable Risks Допустимые риски: • участки, которые не работают вовсе, • участки, которые работают неправильно, • участки, о которых мы ничего не знаем Мы можем принять эти риски ради быстрого релиза или другой цели. 28
- 29. Non-Acceptable Risks Недопустимые риски: • то, что должно работать наверняка и в чем мы должны быть уверены. • пользователь должен получить минимальную, но работающую функциональность. 29
- 30. How to Manage Them? • Управляем допустимыми рисками • Снижаем недопустимые риски 30
- 31. And Finally -
- 32. Ready to love it? • Exploratory testing помогает победить ограничения тест-кейсов • Улучшает качество тест-кейсов • Заставляет команду постоянно учиться • Опытные инженеры используют все знания • Новички находят баги свежим взглядом • Best practice – сочетание exploratory и scripted testing 32
- 33. Thank you! Olga Luzhetskaya Project Manager, Senior QA Engineer DataArt Olga.Luzhetskaya@gmail.com https://www.linkedin.com/in/luzhetska/
Editor's Notes
- 1 день - Попросили сразу приступить к тестированию - exploratory 2 день – рассказали про тест кейсы, выдали готовые, попросили писать – печаль 3 день – вернулись обратно к exploratory – все ок Exploratory testing нет равных, если нужно замотивировать скучающего коллегу или заинтересовать новичка Тестирование по готовым кейсам – механическая работа Не требует креативности Не позволяет тестировщику раскрыться
- Впервые она была зарегистрирована в США, во время Второй Мировой войны. Решив укрепить самолеты, тем самым уменьшив число потерь, изначально приняли логичное, на первый взгляд, но неправильное решение: у вернувшихся самолетов больше всего пробоин было на крыльях и хвосте, их и решили укреплять. Вмешался статистик Абрахам Вальд, объяснив, что крылья и хвост — сильные места, ведь самолеты, подбитые в эти зоны, вернулись на базу, в отличие от самолетов, получивших пробоины в других местах.
- Target: Что тестируем? Resources: С помощью чего тестируем? Information: Что нам нужно обнаружить? Target: What are you exploring? It could be a feature, a requirement, or a module. Resources: What resources will you bring with you? Resources can be anything: a tool, a data set, a technique, a configuration, or perhaps an interdependent feature. Information: What kind of information are you hoping to find? Are you characterizing the security, performance, reliability, capability, usability or some other aspect of the system? Are you looking for consistency of design or violations of a standard?
- Target: What are you exploring? It could be a feature, a requirement, or a module. Resources: What resources will you bring with you? Resources can be anything: a tool, a data set, a technique, a configuration, or perhaps an interdependent feature. Information: What kind of information are you hoping to find? Are you characterizing the security, performance, reliability, capability, usability or some other aspect of the system? Are you looking for consistency of design or violations of a standard?
- https://msdn.microsoft.com/en-us/library/jj620911(v=vs.120).aspx#bkmk_tours
- Однажды был проведен эксперимент с людьми и крысами. В совершенно произвольном порядке загоралась либо зеленая, либо красная лампочка, причем зеленая случайным образом загоралась в 75% случаев. За угаданный цвет крысы получали награду. Они быстро поняли, что зеленая загорается чаще и всегда выбирали ее, выигрывая в 75% случаев. Люди искали зависимости и выигрывали в 65% случаев.
- дополнительные сценарии, места, куда по статистике «почти никто не тыкает» (0,1 % пользователей, например), работа в непопулярных браузерах и т.д.
- Если мы делаем фичу, которая должна помочь пользователю перейти через овраг и в итоге выпускаем половину моста — это не годится, потому что не решает проблему пользователя. Такой эксперимент всегда покажет отрицательный результат, это относится к нашим недопустимым рискам. А если мы натянем через овраг канат с веревками по бокам — то перейти на другую сторону будет уже возможно, а значит, проблема пользователя может быть решена.