Тут дуже дискусійне питання.
По суті, значення в серидині діапазону, які не входять до граничних значень- також окремий класс еквівалентності який треба перевіряти. Тому роблять 5 перевірок, а не 6 :)
P.S. Приклад підібраний не дуже вдало.
Якщо взяти наприклад дисконтну систему, де дається більша знижка після певної суми покупки, то це краще б проілюструвало ідею автора
З технікою все добре, якщо її застововувати з гаричними значеннями. Оатсанній приклад не корректний, тому що автор пропонує робити повне тестування, яке не можливе. Це одна із аксіом тестування. І якщо таких розмірів не 13 а 1300? Навіть якщо знаєш як воно реалізовано, то робити 1300 перевірок не еффективно.
Замість висновку: техніки тест дизайну не панацея, але вони дають змогу обрати потрібні тести.
P.S. Згідно ISTQB, описаны техніки — це Black Box. Якщо хочете брати до уваги внутрішню структуру — пишіть про White Box
Добрий день,
так, щодо туру по джирі — згоден на 100%. Також має сенс показати як працює тест менеджмент система (головне щоб вона була:) )
Щодо написання тест сценаріїв замовником: є досвід коли замовник хотів це робити для деяких компонентів і доволі успішно робив.
Отличная статья!
Статья определённо полезна и место для Exploratory однозначно должно быть в SDLC. Вопрос в том что этот подход работает только в комбинации с другими: теми же тест кейсами/чек листами и с привлечением конечных пользователей (особенно для редких доменов).
По этой теме есть интересная книга «Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design» by James A. Whittaker
P.S. Никто не мешает завести тикет в Jira для «Exploratory Testing»
Спасибо за отзыв!
Спасибо за отзыв!
Спасибо за отзыв!
Дякую за поради. Цікаво було почитати. Ще б хотів додати 1 важливий омомент: треба зрозуміти навіщо/що робить застосунок почати з основних сценаріїв його роботи