Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
•
0 likes•4,937 views
Слайды с доклада 14.11.2014 на SQA-Days 16 (Санкт-Петербург) Видео доступно тут: https://vimeo.com/116772234
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
Similar to Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании (20)
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
- 1. No-Test-Cases Избавьтесь от тест-кейсов в ручном тестировании Alexei Vinogradov
- 2. Alexei Vinogradov IT-Kонсультант тестирование, управление тестированием, автоматизация в тестировании, коучинг email: alexei@vinogradov-it.de skype: alexejv twitter: @i_vino https://www.softwerkskammer.org/groups/testing
- 4. Что такое тест-кейс? • предусловие • шаги/действия • ожидаемый результат • постусловие • [тестовые данные]
- 5. Что такое тест-кейс? • ISTQB („тестовый сценарий“): Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. (IEEE 829-2008)
- 6. Тест-кейсы: зачем? • документация и покрытие • повторяемость • универсальные „верификаторы“ („checkers“) • подготовка к автоматизации • приёмочное тестирование (acceptance) • „сертификация“ (сompliance) • отчеты и аудит
- 7. Тест-кейсы: недостатки • время (долго) • стоимость (дорого)
- 8. Тест-кейсы: недостатки • отладка • сопровождение (maintenance)
- 9. Тест-кейсы: недостатки • читабельность для программистов и бизнеса (readability)
- 10. No-Test-Cases • „No-Test-Case“ („тест-идея“) - краткое описание атомарной проверки функции или свойства ПО, которую может провести квалифицированный тестировщик. • Метод: „No-Test-Case тестирование“, „Тестирование с тест-идеями“
- 11. No-Test-Cases (тест-идеи) • атомарная проверка • не означает, что проверка тривиальна • может содержать несколько тестовых данных • атомарная в вашем контексте
- 12. Простой пример • Сложение двух чисел показывает их сумму • Сложение положительного и отрицательного числа показывает их сумму • Сложение двух дробей показывает их сумму • (-) Сложение букв не должно быть возможным (-) негативные тесты
- 13. Как писать и управлять • так же как тест-кейсы, те же инструменты • классы эквивалентности, граничные значения (НО без конкретных тестовых данных) • сохраняем в системе управления • связываем с требованиями • используем мета-данные • структурируем и группируем
- 14. Как писать из требований • часто тест-идея - это 100% копия требования • прямой правильный путь • граничные и редкие случаями • негативные случаи
- 15. No-Test-Cases: пример Req-1. В роли „Пользователь“ я хочу фильтровать и сортировать список заказов
- 16. No-Test-Cases документация покрытие повторяемость универсальный „чекер“ подготовка к автоматиз. улучшилась! не хуже так же тестировщик* помогает автом-рам
- 17. No-Test-Cases приёмочное тестирование „сертификация“ отчеты и аудит по-разному нельзя так же
- 18. No-Test-Cases: плюсы ⭐️ время (быстрее) ⭐️ стоимость (дешевле)
- 19. No-Test-Cases: плюсы ⭐️ нет отладки ⭐️ меньше сопровождения
- 20. No-Test-Cases: плюсы ⭐️интереснее выполнять
- 21. No-Test-Cases: плюсы ⭐️ читаемость для программистов и бизнеса
- 22. No-Test-Cases: потери • шаги для отчетов об ошибках
- 23. No-Test-Cases ./. исследовательское тестирование • две разные вещи Исследовательское No-Test-Cases без форм. требований чаще с требованиями иногда без сохранения кейсов в системе управления кейсами нужен готовый продукт продукт необязателен
- 24. No-Test-Cases ./. тестирование чеклистами • что такое „тестирование чеклистами"?! чеклисты: тест-идеи для однотипных приложений вне системы управления кейсами много схожего
- 25. No-Test-Cases Советы ⭐️⭐️⭐️ Начинайте как можно раньше! ⭐️⭐️⭐️ Показывайте программистам до, во время и после этапа разработки!
- 26. No-Test-Cases: итог • эффективно ускоряют фазу тест-дизайна • увеличивают пользу от фазы выполнения тестов, используя главную ценность тестировщика - его мозг • применимы для широкого спектра проектов
- 27. Важно! ⭐️⭐️⭐️ Не бывает „best practices“, бывают „good practices“ в контексте!
- 28. И последнее ⭐️⭐️⭐️ Всегда помните: обеспечение качества лежит в зоне ответственности всей команды! Photo: Sekhar, India ©
- 29. Где еще читать? пример из этой презентации: http://bit.ly/no-test-case-example Алексей Лупан - вебинары о практике тест-кейсов https://www.youtube.com/watch?v=KDYbomPXXl8 https://www.youtube.com/watch?v=mHhy1YftRCw Eric Jacobson - статья „Не давайте тест-кейсы салагам“: http://www.testthisblog.com/2012/04/dont-give-test-cases-to-n00bs.html
- 30. Слайды пример из этой презентации: http://bit.ly/no-test-case-example Алексей Лупан - вебинары о практике тест-кейсов https://www.youtube.com/watch?v=KDYbomPXXl8 https://www.youtube.com/watch?v=mHhy1YftRCw Eric Jacobson - статья „Не давайте тест-кейсы салагам“: http://www.testthisblog.com/2012/04/dont-give-test-cases-to-n00bs.html
- 31. The End. Вопросы? skype: alexejv email: alexei@vinogradov-it.de twitter: @i_vino
Editor's Notes
- Пару слов о себе. Я участвую в реализации IT проектов в немецкой промышленности с конца прошлого века. Начинал я в разработке и осознанно тестированием начал заниматься примерно 10 лет назад, с 2009-ого года с удовольствием выбрал тестирование своей основной профессией. Странный логотип в углу - это „Softwerkskammer“ немецкое сообщество вдохновленных айтишников, мероприятия которого я регулярно посещаю. Как вы заметили, я не указал, в какой фирме я работаю. Дело в том, что последние 7 лет я занимаюсь бизнесом по взаимновыгодному обмену своего времени на регулярные банковские переводы заинтересованных предприятий. Итак, это было вступление, начнем!
- Тут часть списка фирм, которые приняли мое предложение. Я не могу сказать, что везде я научился хорошему, но повидал достаточно :-). На данный момент я обмениваю время на деньги с немецкой авиадиспетчерской службой DFS.
- Вопрос в зал. Что такое тест-кейс. Давайте, не определение пока что, а ответ на вопрос, из чего состоит тест-кейс? Я буду записывать, что уже сказали.
- Теперь усложним. Кто знает определение тест-кейса по ISTQB? Наизусть? Предлагаю логопедам включить данное определение в набор особенно садистских скороговорок.
- Мотивация для тест кейсов. Зачем они вообще нужны? „чекер“, а не „тестировщик“ (!) - „человек с улицы“ „сертификация“ - соответствие законам и прочим нормам „аудит“ - возможность сопоставления, кто именно, когда, и как выполнял тест-кейс.
- Следующий шаг. Что вас особенно раздражает в тест-кейсах?
- Следующий шаг. Что вас особенно раздражает в тест-кейсах?
- Следующий шаг. Что вас особенно раздражает в тест-кейсах?
- квалифицированный тестировщик -специалист в приложении, в области применения Сперва история о том, как я дошел до такой жизни. Так вот, в одном из проектов, я собирался писать тест-кейсы для определенного модуля средних размеров. Задание такое было. От тест-менеджера. Ну и не вспомню сейчас почему, но я начал с того, что начал писать по каждому требованию короткие идеи для тест-кейсов в заголовке, с мыслью написать шаги, ожидаемые результаты и прочие тестовые данные чуть попозже. Как обычно в таких случаях, возникали какие-то вопросы, которые я решал с аналитиками и бизнесом пользуясь именно этими короткими описаниями, и этого было вполне достаточно. Потом, к слову, я шаги и все остальное дописал, но осадок уже остался :-). Круче было в следующих двух проектах, в которых я был в роли тест-менеджмера и дедлайны абсолютно не оставляли шансов успеть написать все шаги к тест-кейсам, поэтому я „не без угрызений совести“ принял решение писать больше идей, пренебрегая шагами. В результате, после окончания проекта, да, я не тормоз, я порефлексировал и пришел к выводу, что во всех трёх проектах шаги, ожидаемые результаты и прочее были просто не нужны. Итак к определению. „Тестировщик“ - не верификатор ( или „чекер“).
- Атомарная проверка - проверка ровно одной функции/свойства, зависит от контекста. Не означает, что проверка тривиальна, для некоторых проверок необходима аналитическая работа или глубокое знание предметной области. („Маршрут должен быть оптимальный с точки зрения общих расходов (расходы на л./км, временные расходы)“, „Маршрут не должен включать поездки через экологические зоны 3 и 4“). Некоторые проверки могут требовать множество тестовых данных. („Плата за вход по возрасту: 0-3 - 0€, 4-16 - 5 €, 17+ 8€“) Атомарной является проверка, которая кажется вам атомарной 😃 Нет строгих правил атомарности - зависит от контекста проекта, задания. Не атомарная: „там где присутствует И в описании“ - разделите на несколько.
- в целом те же принципы как и с тест-кейсами, те же инструменты для управления (HP ALM, TestRail, Sitechco, TestLink) классы эквивалентности, граничные значения и т.п., но не указывать конкретные тестовые данные сохраняем в базе для повторного использования связываем с требованиями (в инструментах) в меру используем мета-данные (автор, дата, область, важность и т.д.) структурируем и группируем Структура и группы: у вас будет много, очень много идей
- часто тест-идея - это 100% копия требования начинаем с прямого правильного пути дополняем граничными и редкими случаями негативные случаи
- Сопровождение т.е. устойчивость к изменениям интерфейса
- Наши французские коллеги за тестированием Интереснее выполнять - может быть найдено больше проблем.
- Сопровождение т.е. устойчивость к изменениям интерфейса
- В отчетах об ошибке не можем скопировать шаги, и просто написать „см. 6-ой шаг тест-кейса“. Экономия на том, что мы шаги пишем только при ошибке, оставляя за собой гибкость сокращения пути к воспроизведению.
- No-Test-Cases могут быть созданы из письменных формализованных требований. Исследовательское тестирование - как правило без. No-Test-Cases могут управляться любым инструментом, который управляет „обычными“ тест-кейсами (TestCase Management Tool). И это тоже хорошая практика! No-Test-Cases могут быть созданы еще до начала разработки!
- Опрос: 1. кто слышал про тестирование чеклистами? 2. кто уверен, что точно знает что такое?
- … но не для всех!
- Не бывает „best practices“, бывают „good practices“ в конкретной ситуации.