К примеру, в ходе общения с пользователями аналитик выясняет, что кнопка в программе должна быть зелёная – это требование. Программа должна запускаться за 5 секунд – это требование. Итого мы уже имеем два требования.
Они фиксируются в документах, которые имеют своё название – «спецификация».
Спецификацию ещё могут называть «спецификация требований». Ниже приведена часть спецификации с таблицей требований к программе:
Спецификации, которые составляют аналитики, от компании к компании отличаются, нет чёткого шаблона, которого придерживаются все аналитики мира.
Она может содержать функциональные и нефункциональные требования – это два основных вида требований к программному обеспечению. В чём их отличия?
Функциональные требования – описывают функциональность, предоставляемую программным обеспечением. Они определяют, что должна делать программа. Сюда входят: возможность ввода и редактирования данных в поле программы; возможность очистки полей для ввода данных; возможность сложения чисел и т. д. На рисунке выше как раз отражена спецификация с функциональными требованиями.
Нефункциональные требования – описывают свойства программы, но не её поведение. Они определяют, как должна работать программа. Сюда относятся: удобство использования (к примеру, расположение кнопки или её название); производительность; безопасность и т. д. Ниже приведена спецификация с нефункциональными требованиями:
Основное отличие заключается в том, что функциональные описывают функционал, нефункциональные – свойства и качества системы.
В ходе своей профессиональной деятельности специалисты по тестированию часто сталкиваются с ситуацией, когда в организации отсутствуют чётко задокументированные требования к программе или они являются минимальными и не полностью информативными. В таких случаях специалисты по тестированию вынуждены активно взаимодействовать с аналитиками и программистами, чтобы получить необходимую информацию. Иногда им даже приходится самостоятельно проводить исследование программ, чтобы полноценно провести тестирование. Это требует от специалиста по тестированию гибкости и способности самостоятельно разбираться в функциональности программ.
Собрав информацию о потребностях пользователей и проработав требования, все данные передаются программистам. Они, изучив их, начинают разрабатывать программу, реализовывая то, что зафиксировано в требованиях. В процессе написания кода программисты могут допустить ошибку и прописать неверные данные в коде. К примеру, разрабатывая программу сложения чисел программист в строке, где должно происходить сложение, вместо знака «плюс» прописал знак «минус». Так была допущена ошибка:
После написания кода программы её специальными инструментами «собирают», чтобы она стала полноценной работающей программой, а не набором файлов со строками кода. Собрали, внедрили и начали процесс эксплуатации. В момент использования программы пользователи столкнутся с ситуацией, когда программа работает не так, как ожидалось, когда реальный результат не равен ожидаемому.
Если рассматривать приведённый пример с программой сложения чисел, пользователь ожидает, что, введя два числа и нажав на кнопку сложения, получит результат сложения. Однако его ждёт разочарование, так как программа будет вычитать и выводить результат вычитания, а это означает, что она не сможет выполнять требуемую от неё функцию. Почему? Потому что на этапе разработки допустили ошибку, и пользователь столкнулся с последствиями ранее допущенной ошибки – с дефектом в программе.
Чтобы дефекты не попадали к пользователям, они должны выявляться специалистами по тестированию до передачи программы в эксплуатацию.
