В прошлой статье мы рассматривали аксиомы тестирования чем раньше мы находим какие-либо ошибки (баги) тем дешевле они стоят. Также и с тестирование требований, это самый ранний этап разработки. Это тот этап когда составляется документация и программное обеспечение (ПО) еще не закодировано, а это значит что если мы выявим ошибку в требованиях и исправим её на этом этапе, то цена этого бага в документации будет минимальна.
Требования это документация к ПО в которой описано, как? зачем? почему? для чего? необходимо нам наше ПО, с какой целью это делается, что хотим получить на выходе? Требования тоже можно протестировать.
Обычно составлением требований, документации занимаются аналитики, когда нет аналитиков требования приходят напрямую от заказчиков или же project менеджеры или product owners.
Что может протестировать тестировщик в требованиях
Есть 7 атрибутов (качеств), которые может посмотреть и протестировать тестировщик.
- Полнота. В полной ли мере описаны те функции, которое должно осуществлять наше ПО. Как это проверить? Если вам приходят требования, то вы первым делом составляете чек-лист проверок, которые вы бы сделали на этот функционал и если что-то не хватает вам при составлении чек-листа — это значит, что требования не полные.
- Однозначность. Это значит, что требования должны однозначно трактоваться всеми участниками процесса разработки ПО. В требованиях не должно быть таких слов как, например, “файл должен “быстро” загружаться”. Что значит быстро? Для пользователя это 1 секунда, а для разработчика это 3 секунды. Таких слов как “быстро” “медленно” “качественно” “хорошо” “плохо” не должно быть, должны быть цифры.
- Непротиворечивость. В разных главах требований они не должны противоречить друг другу. Например, на одной странице требований указано, что кнопка на сайте должна быть красного цвета, а на другой странице указано, что кнопка должна быть желтого цвета.
- Необходимость. Требования написаны четко и по делу, не нужно перебарщивать, например, включи свет, включи компьютер, дождись загрузки, зайди в программу.
- Осуществимость. Обычно это проверяет разработчик, когда ему приносят базовое техническое задание (ТЗ) от заказчика, возможно ли это технически осуществить. Бывают и такие ТЗ, которые на данный момент осуществить невозможно, не придумали таких технологий. Необходимо переделать ТЗ с заказчиком.
- Тестируемость. Проверка на то, что данный функционал вообще есть возможность протестировать или покрыть его например автотестами, если в организации принято все покрывать автотестами. Когда разрабатывается новый функционал или доделывается какая-либо фича, нужно проверить что это в принципе возможно протестировать. Второй момент, если у вас все автоматизировано, что это возможно автоматизировать.
- Модифицируемость требований. Когда у нас уже есть готовое ПО и оно работает, нам нужно сделать новый функционал и мы без вреда для всех остальных требований можем что-либо доделать в наших требованиях, чтобы у нас появилась новая фича или новый функционал. ПО постоянно развивается и его нужно постоянно модифицировать.
