Станислав Ким. Учебный центр ИТ Uransoft. Как стать TRUE-тестировщиком #4
0 likes967 views
Документ описывает важные аспекты спецификации программных требований (SRS) для разработки программного обеспечения, включая необходимую корректность, недвусмысленность, полноту, непротиворечивость, проверяемость, трассируемость и понимаемость требований. Каждое требование должно быть проверяемым, а процесс его создания включает анализ, оценку и решение задач, связанных с ошибками и несоответствиями. Также упоминаются курсы обучения по Java и тестированию, предлагаемые учебным центром Урансофт.
![Корректность
Вопрос: На сколько требование
корректно или кто-то допустил ошибку
при написании требования?
Пример: Для стирания последнего знака
используется клавиша [←] (клавиша со
стрелкой)
Описание: Ошибка в требовании.
Правильно будет: «Для стирания
последнего знака используется
клавиша [Backspace] (клавиша со
стрелкой и надписью Backspace)»](https://image.slidesharecdn.com/presentationkimuransoftcommon-140407044407-phpapp02/85/Uransoft-TRUE-4-6-320.jpg)
Станислав Ким. Учебный центр ИТ Uransoft. Как стать TRUE-тестировщиком #4
- 1. Учебный центр ИТ УРАНСОФТ Учим, устраиваем, развиваем!
- 2. Тестирование требований Software requirements specification, SRS Программные требования – Software Requirements – свойства программного обеспечения, которые должны быть надлежащим образом представлены в нём для решения конкретных практических задач. Данная область знаний касается вопросов извлечения (сбора), анализа, специфицирования и утверждения требований.
- 3. SRS по К. Вигерсу
- 4. Пример
- 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. Понимаемость Могут ли все участники процесса понять, что требуется от системы по описанию требования? Пример: Калькулятор должен уметь выделять и начислять НДС.
- 19. Деление на НОЛЬ
- 20. Деление на НОЛЬ
- 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 Станислав КИМ