Downloaded 18 times
![Что такое тест-кейс?
• предусловие
• шаги/действия
• ожидаемый результат
• постусловие
• [тестовые данные]](https://image.slidesharecdn.com/no-test-caseexample-141102145159-conversion-gate02/85/No-Tests-Cases-4-320.jpg)
Uploaded byDeutsche Post
Метод No-Tests-Cases: избавьтесь от тест-кейсов в тестировании
Документ рассматривает подход к тестированию без использования традиционных тест-кейсов, предлагая концепцию "тест-идей" как альтернативу. Этот метод ускоряет процесс тест-дизайна, снижает затраты и улучшает читаемость, при этом подчеркивается, что обеспечение качества является коллективной ответственностью команды. В документе указаны преимущества и недостатки обоих подходов, а также приведены примеры и рекомендации по их применению.
More Related Content
![[Sqa days]risk driven testing](https://cdn.slidesharecdn.com/ss_thumbnails/sqadaysriskdriventesting-101120014814-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Метод 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
- #3 Пару слов о себе. Я участвую в реализации IT проектов в немецкой промышленности с конца прошлого века. Начинал я в разработке и осознанно тестированием начал заниматься примерно 10 лет назад, с 2009-ого года с удовольствием выбрал тестирование своей основной профессией. Странный логотип в углу - это „Softwerkskammer“ немецкое сообщество вдохновленных айтишников, мероприятия которого я регулярно посещаю. Как вы заметили, я не указал, в какой фирме я работаю. Дело в том, что последние 7 лет я занимаюсь бизнесом по взаимновыгодному обмену своего времени на регулярные банковские переводы заинтересованных предприятий. Итак, это было вступление, начнем!
- #4 Тут часть списка фирм, которые приняли мое предложение. Я не могу сказать, что везде я научился хорошему, но повидал достаточно :-). На данный момент я обмениваю время на деньги с немецкой авиадиспетчерской службой DFS.
- #5 Вопрос в зал. Что такое тест-кейс. Давайте, не определение пока что, а ответ на вопрос, из чего состоит тест-кейс? Я буду записывать, что уже сказали.
- #6 Теперь усложним. Кто знает определение тест-кейса по ISTQB? Наизусть? Предлагаю логопедам включить данное определение в набор особенно садистских скороговорок.
- #7 Мотивация для тест кейсов. Зачем они вообще нужны? „чекер“, а не „тестировщик“ (!) - „человек с улицы“ „сертификация“ - соответствие законам и прочим нормам „аудит“ - возможность сопоставления, кто именно, когда, и как выполнял тест-кейс.
- #8 Следующий шаг. Что вас особенно раздражает в тест-кейсах?
- #9 Следующий шаг. Что вас особенно раздражает в тест-кейсах?
- #10 Следующий шаг. Что вас особенно раздражает в тест-кейсах?
- #11 квалифицированный тестировщик -специалист в приложении, в области применения Сперва история о том, как я дошел до такой жизни. Так вот, в одном из проектов, я собирался писать тест-кейсы для определенного модуля средних размеров. Задание такое было. От тест-менеджера. Ну и не вспомню сейчас почему, но я начал с того, что начал писать по каждому требованию короткие идеи для тест-кейсов в заголовке, с мыслью написать шаги, ожидаемые результаты и прочие тестовые данные чуть попозже. Как обычно в таких случаях, возникали какие-то вопросы, которые я решал с аналитиками и бизнесом пользуясь именно этими короткими описаниями, и этого было вполне достаточно. Потом, к слову, я шаги и все остальное дописал, но осадок уже остался :-). Круче было в следующих двух проектах, в которых я был в роли тест-менеджмера и дедлайны абсолютно не оставляли шансов успеть написать все шаги к тест-кейсам, поэтому я „не без угрызений совести“ принял решение писать больше идей, пренебрегая шагами. В результате, после окончания проекта, да, я не тормоз, я порефлексировал и пришел к выводу, что во всех трёх проектах шаги, ожидаемые результаты и прочее были просто не нужны. Итак к определению. „Тестировщик“ - не верификатор ( или „чекер“).
- #12 Атомарная проверка - проверка ровно одной функции/свойства, зависит от контекста. Не означает, что проверка тривиальна, для некоторых проверок необходима аналитическая работа или глубокое знание предметной области. („Маршрут должен быть оптимальный с точки зрения общих расходов (расходы на л./км, временные расходы)“, „Маршрут не должен включать поездки через экологические зоны 3 и 4“). Некоторые проверки могут требовать множество тестовых данных. („Плата за вход по возрасту: 0-3 - 0€, 4-16 - 5 €, 17+ 8€“) Атомарной является проверка, которая кажется вам атомарной 😃 Нет строгих правил атомарности - зависит от контекста проекта, задания. Не атомарная: „там где присутствует И в описании“ - разделите на несколько.
- #14 в целом те же принципы как и с тест-кейсами, те же инструменты для управления (HP ALM, TestRail, Sitechco, TestLink) классы эквивалентности, граничные значения и т.п., но не указывать конкретные тестовые данные сохраняем в базе для повторного использования связываем с требованиями (в инструментах) в меру используем мета-данные (автор, дата, область, важность и т.д.) структурируем и группируем Структура и группы: у вас будет много, очень много идей
- #15 часто тест-идея - это 100% копия требования начинаем с прямого правильного пути дополняем граничными и редкими случаями негативные случаи
- #20 Сопровождение т.е. устойчивость к изменениям интерфейса
- #21 Наши французские коллеги за тестированием Интереснее выполнять - может быть найдено больше проблем.
- #22 Сопровождение т.е. устойчивость к изменениям интерфейса
- #23 В отчетах об ошибке не можем скопировать шаги, и просто написать „см. 6-ой шаг тест-кейса“. Экономия на том, что мы шаги пишем только при ошибке, оставляя за собой гибкость сокращения пути к воспроизведению.
- #24 No-Test-Cases могут быть созданы из письменных формализованных требований. Исследовательское тестирование - как правило без. No-Test-Cases могут управляться любым инструментом, который управляет „обычными“ тест-кейсами (TestCase Management Tool). И это тоже хорошая практика! No-Test-Cases могут быть созданы еще до начала разработки!
- #25 Опрос: 1. кто слышал про тестирование чеклистами? 2. кто уверен, что точно знает что такое?
- #27 … но не для всех!
- #28 Не бывает „best practices“, бывают „good practices“ в конкретной ситуации.