ݺߣ

ݺߣShare a Scribd company logo

Станислав Ким. Учебный центр ИТ Uransoft. Как стать TRUE-тестировщиком #4

•
•
uransoft
uransoft
Convert to study guideBETA

Transform any presentation into a summarized study guide, highlighting the most important points and key insights.

1 of 22
Download to read offline
Учебный центр ИТ УРАНСОФТ Учим, устраиваем, развиваем!
Тестирование требований Software requirements specification, SRS Программные требования – Software Requirements – свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований.
SRS по К. Вигерсу
Пример
Требования к требованиям  Корректность  Недвусмысленность  Полнота набора требований  Непротиворечивость набора требований  Проверяемость (тестопригодность)  Трассируемость  Понимаемость
Корректность Вопрос: На сколько требование корректно или кто-то допустил ошибку при написании требования? Пример: Для стирания последнего знака используется клавиша [←] (клавиша со стрелкой) Описание: Ошибка в требовании. Правильно будет: «Для стирания последнего знака используется клавиша [Backspace] (клавиша со стрелкой и надписью Backspace)»
Корректность Как находить?  Знание предметной области,  Трассировка требования вверх (бизнес-требования), трассировка требований вниз (низкоуровневые требования — дизайн, макеты, детальное описание реализации). Поиск ошибок и нестыковок.  «Peer review» – оценка «коллегами» – теми, кто занимается той же самой работой.
Недвусмысленность Могут ли 2 различных человека понять требование по-разному? Пример: Сколько будет 2+2х2? 6 или 8? Описание: Отработка понятия «Подитог», как в случае (2+2)х2 или соблюдение «порядка выполнения мат. действий»
Недвусмысленность
Недвусмысленность Как находить?  Проверять «ветвистость» требований: если есть условия или исключения — проверять, чтобы они все были описаны и не было «неописанных дыр»,  Избегать ветвлений или форматировать их в таблицы вариантов.  «Peer review» – оценка коллегами.
Полнота требований Насколько полным является набор требований? Если есть секция в SRS, определяющая функциональность модуля, то вся ли функциональность этого модуля покрыта требованиями? Нет ли дыр?
Полнота требований Как находить?  WBS требований сверху вниз,  Все классы пользователей,  Проверка пограничных значений,  Повторы требований при продолжении сбора,  Выход за рамки проекта,  Низкий приоритет требования.
Непротиворечивость набора Поиск требований, которые противоречат друг другу: 1. Это может быть очевидным, когда 2 требования явно говорят противоположные вещи, 2. но может быть и скрытым, где противоречивость не очевидна на первый взгляд.
Непротиворечивость набора Как тестировать?  Обращать внимания на общие формулировки в требованиях.  Делить на категории и ревьювить их направленно на предмет противоречий.  Выделять все требования, трассирующиеся на одно верхнеуровневое требование и анализировать такие наборы.
Проверяемость Один из основных и самых важных критериев для тестировщиков. Возможно ли проверить это требование и убедиться, что оно выполняется? Пример: в случае возникновения критической ошибки калькулятор должен перезагрузиться. Пример 2: информация на экране должна отображаться в понятном пользователю виде
Проверяемость Как тестировать?  «Как я буду это проверять?». Детально анализировать, и, возможно, вносить правки в требование (уточнения, ограничения)  Выявлять общие формулировки, требующие перебора неопределенного числа вариантов для проверки выполнения требования. (переформулировать требование или добавить список условий в SRS или более низкоуровневые документы.)
Трассируемость Любое требование проходит путь от бизнес-идеи до деталей реализации. Это может быть 3 уровня требований (product requirements, software requirements, detailed design document), может быть и больше. Трассируемость — это связь с требованием выше и требованием ниже. Кроме того трассируемость требования (функции) в различных документах.
Понимаемость Могут ли все участники процесса понять, что требуется от системы по описанию требования? Пример: Калькулятор должен уметь выделять и начислять НДС.
Деление на НОЛЬ
Деление на НОЛЬ
Курсы Урансофт (JAVA-01) Введение в Java (JAVA-02) Основы языка и web-разработки на Java (SQA-01) Основы тестирования ПО (SQA-02) Введение в профессию тестировщика (SA-01) Системный анализ в разработке ПО (SRS-01) Сбор требований к ПО
Спасибо! Вопросы? +7 (812) 309-78-59, 438-16-88 Станислав КИМ

More Related Content

Станислав Ким. Учебный центр ИТ Uransoft. Как стать TRUE-тестировщиком #4

  • 1. Учебный центр ИТ УРАНСОФТ Учим, устраиваем, развиваем!
  • 2. Тестирование требований Software requirements specification, SRS Программные требования – Software Requirements – свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований.
  • 3. SRS по К. Вигерсу
  • 5. Требования к требованиям  Корректность  Недвусмысленность  Полнота набора требований  Непротиворечивость набора требований  Проверяемость (тестопригодность)  Трассируемость  Понимаемость
  • 6. Корректность Вопрос: На сколько требование корректно или кто-то допустил ошибку при написании требования? Пример: Для стирания последнего знака используется клавиша [←] (клавиша со стрелкой) Описание: Ошибка в требовании. Правильно будет: «Для стирания последнего знака используется клавиша [Backspace] (клавиша со стрелкой и надписью Backspace)»
  • 7. Корректность Как находить?  Знание предметной области,  Трассировка требования вверх (бизнес-требования), трассировка требований вниз (низкоуровневые требования — дизайн, макеты, детальное описание реализации). Поиск ошибок и нестыковок.  «Peer review» – оценка «коллегами» – теми, кто занимается той же самой работой.
  • 8. Недвусмысленность Могут ли 2 различных человека понять требование по-разному? Пример: Сколько будет 2+2х2? 6 или 8? Описание: Отработка понятия «Подитог», как в случае (2+2)х2 или соблюдение «порядка выполнения мат. действий»
  • 10. Недвусмысленность Как находить?  Проверять «ветвистость» требований: если есть условия или исключения — проверять, чтобы они все были описаны и не было «неописанных дыр»,  Избегать ветвлений или форматировать их в таблицы вариантов.  «Peer review» – оценка коллегами.
  • 11. Полнота требований Насколько полным является набор требований? Если есть секция в SRS, определяющая функциональность модуля, то вся ли функциональность этого модуля покрыта требованиями? Нет ли дыр?
  • 12. Полнота требований Как находить?  WBS требований сверху вниз,  Все классы пользователей,  Проверка пограничных значений,  Повторы требований при продолжении сбора,  Выход за рамки проекта,  Низкий приоритет требования.
  • 13. Непротиворечивость набора Поиск требований, которые противоречат друг другу: 1. Это может быть очевидным, когда 2 требования явно говорят противоположные вещи, 2. но может быть и скрытым, где противоречивость не очевидна на первый взгляд.
  • 14. Непротиворечивость набора Как тестировать?  Обращать внимания на общие формулировки в требованиях.  Делить на категории и ревьювить их направленно на предмет противоречий.  Выделять все требования, трассирующиеся на одно верхнеуровневое требование и анализировать такие наборы.
  • 15. Проверяемость Один из основных и самых важных критериев для тестировщиков. Возможно ли проверить это требование и убедиться, что оно выполняется? Пример: в случае возникновения критической ошибки калькулятор должен перезагрузиться. Пример 2: информация на экране должна отображаться в понятном пользователю виде
  • 16. Проверяемость Как тестировать?  «Как я буду это проверять?». Детально анализировать, и, возможно, вносить правки в требование (уточнения, ограничения)  Выявлять общие формулировки, требующие перебора неопределенного числа вариантов для проверки выполнения требования. (переформулировать требование или добавить список условий в SRS или более низкоуровневые документы.)
  • 17. Трассируемость Любое требование проходит путь от бизнес-идеи до деталей реализации. Это может быть 3 уровня требований (product requirements, software requirements, detailed design document), может быть и больше. Трассируемость — это связь с требованием выше и требованием ниже. Кроме того трассируемость требования (функции) в различных документах.
  • 18. Понимаемость Могут ли все участники процесса понять, что требуется от системы по описанию требования? Пример: Калькулятор должен уметь выделять и начислять НДС.
  • 21. Курсы Урансофт (JAVA-01) Введение в Java (JAVA-02) Основы языка и web-разработки на Java (SQA-01) Основы тестирования ПО (SQA-02) Введение в профессию тестировщика (SA-01) Системный анализ в разработке ПО (SRS-01) Сбор требований к ПО
  • 22. Спасибо! Вопросы? +7 (812) 309-78-59, 438-16-88 Станислав КИМ