Тестирование программного обеспечения. Основы

Жизненный цикл программы

Как любая сущность в мире, программы появляются на свет, «живут» определённое время и «умирают», и на протяжении этого периода проходят различные стадии своего существования.

Идея. Появление программы начинается с неё. Есть заинтересованное лицо или группа лиц, которые в определённый период времени понимают: нужна программа, которая будет помогать им решать определённые задачи. В момент появления идеи и принятия решения о её создании начинается «жизнь» любой программы.

Анализ. На данном этапе определяются нужды и ожидания пользователей будущей программы и собираются их пожелания. По мере того, как выясняются потребности, они преобразуются в требования, которым должна удовлетворять новая программа. Они чётко, структурировано и формализовано фиксируются в документе. О требованиях поговорим в следующих главах.

Проектирование. На этапе анализа определяется, что должна делать будущая программа; определяется, как она будет выполнять свои задачи и какие функции необходимо заложить. Именно на данном этапе определяется структура программы, базы данных, как программа будет взаимодействовать с другими программами, как будет выглядеть интерфейс и прочие моменты.

Разработка. На этом этапе происходит написание кода, создание файлов данных и разработка баз данных.

Тестирование. В этот период проводятся исследования и испытания программы. Данный этап тесно связан с разработкой, так как в процессе разработки идёт постоянное тестирование.

Внедрение. Происходит ввод программы в эксплуатацию и передача её пользователям.

Сопровождение. Программа поддерживается и обновляется, чтобы оставаться актуальной и исправно работающей.

Устаревание. На этом этапе программа выводится из эксплуатации из-за устаревания или замены на более новую версию. Прекращается сопровождение и разработка, завершается «жизнь» программы.

Рассмотрим все описанные этапы на примере строительства. Изначально у человека появляется идея постройки дома. Через определённое время он начинает проводить анализ и задаваться вопросами: «сколько комнат должно быть в доме», «нужна ванна или душевая кабинка», «какой фундамент выбрать», «сколько должно быть этажей», а также он спрашивает о потребностях свою семью. Это и есть период анализа, сбора требований и пожеланий. Организованный человек все пожелания фиксирует на бумаге, и у него появятся зафиксированные требования к дому. После анализа человек идёт к архитекторам, чтобы они разработали ему индивидуальный проект под его требования. Архитекторы начинают проектирование дома, коммуникаций, придомовой территории. Дальше человек получает на руки всю проектную документацию и направляется к строителям, начинается разработка дома – строительство. Затем он принимает дом и проводит тестирование: крутит краны, топает по полу, изучая прочность, проверяет систему отопления, кондиционирования. Если всё удовлетворяет, он въезжает, и этап переезда – это внедрение. Далее уже идёт эксплуатация – период проживания. Если строители дали на дом гарантию или на платной основе готовы постоянно поддерживать его в хорошем состоянии, в случае поломки чего-либо, человек обращается в организацию, строившую дом, и они исправляют проблему, а возможно что-то совершенствуют – это сопровождение. Через много лет дом станет непригодным для проживания – тогда его выведут из эксплуатации и снесут; на этом этапе завершается жизнь дома – этап устаревания.

Теперь возьмём пример операционной системы. В далёкие времена у кого-то появилась идея создания операционной системы Windows. Вдохновлённый ею человек начал проводить анализ существующих программ на рынке и собирать техническую информацию. Накопив необходимые данные стало понятно – нужно создавать. После началось проектирование операционной системы – продумывалось, из каких программ она будет состоять, как программы будут между собой взаимодействовать, как будет выглядеть интерфейс операционной системы. Пройдя этап проектирования, началась разработка – написание кода операционной системы. Создав первую версию, программисты с коллегами начали тестирование работы операционной системы и её компонентов. Убедившись, что операционная система работает, провели внедрение – передали пользователям и научили их работать с операционной системой. Люди пользовались операционной системой, обнаруживали ошибки и сообщали создателям. Те, в свою очередь их исправляли и обновляли операционную систему. Это этап сопровождения. Создатели выпустили новую версию, а затем ещё одну. Первую версию вывели из эксплуатации, так как произошло устаревание, её больше не поддерживали. Так и закончилась жизнь первой версии операционной системы. Это применимо ко всем существующим программам.

Описанные стадии жизни программы и есть её жизненный цикл, состоящий из этапов:

При этом, пока не произошло вывода из эксплуатации (устаревания), процесс цикличен, т. е. все этапы кроме «Устаревания» многократно повторяются.

Жизненный цикл программы – период времени, который начинается с момента принятия решения о необходимости создания программы и заканчивается в момент её полного изъятия из эксплуатации.

Требования к программе

Мы с вами получили представление о жизненном цикле программ. В процессе его рассмотрения мы затронули такое понятие как «требования». Рассмотрим, что они из себя представляют, для чего нужны и откуда берутся.

Чтобы разработать программу, необходимо понять, что пользователь хочет получить от неё, какие нужды хочет закрыть. На основании полученной информации аналитики начинают подробнее разбирать потребности пользователей и фиксировать, как должна работать программа, что должна делать, с какими программами должна взаимодействовать, а также прописывают многие другие аспекты на основании постоянного общения с пользователями и выявления их потребностей и желаний. Все данные фиксируются в виде требований к программе. Из озвученного выведем определение, что такое «требование к программе».

Требование к программе – это структурированное описание определённых свойств программы (поведения, внешнего вида, качества и т. д.), которые должны отвечать потребностям пользователя. Требования могут представляться в виде документа или набора документов.

К примеру, в ходе общения с пользователями аналитик выясняет, что кнопка в программе должна быть зелёная – это требование. Программа должна запускаться за 5 секунд – это требование. Итого мы уже имеем два требования.

Они фиксируются в документах, которые имеют своё название – «спецификация».

Спецификация – документ, исчерпывающе, однозначно и доступно описывающий требования, дизайн, поведение и иные характеристики программы, которую требуется разработать.

Спецификацию ещё могут называть «спецификация требований». Ниже приведена часть спецификации с таблицей требований к программе:

Спецификации, которые составляют аналитики, от компании к компании отличаются, нет чёткого шаблона, которого придерживаются все аналитики мира.

Она может содержать функциональные и нефункциональные требования – это два основных вида требований к программному обеспечению. В чём их отличия?

Функциональные требования – описывают функциональность, предоставляемую программным обеспечением. Они определяют, что должна делать программа. Сюда входят: возможность ввода и редактирования данных в поле программы; возможность очистки полей для ввода данных; возможность сложения чисел и т. д. На рисунке выше как раз отражена спецификация с функциональными требованиями.

Нефункциональные требования – описывают свойства программы, но не её поведение. Они определяют, как должна работать программа. Сюда относятся: удобство использования (к примеру, расположение кнопки или её название); производительность; безопасность и т. д. Ниже приведена спецификация с нефункциональными требованиями:

Основное отличие заключается в том, что функциональные описывают функционал, нефункциональные – свойства и качества системы.

В ходе своей профессиональной деятельности специалисты по тестированию часто сталкиваются с ситуацией, когда в организации отсутствуют чётко задокументированные требования к программе или они являются минимальными и не полностью информативными. В таких случаях специалисты по тестированию вынуждены активно взаимодействовать с аналитиками и программистами, чтобы получить необходимую информацию. Иногда им даже приходится самостоятельно проводить исследование программ, чтобы полноценно провести тестирование. Это требует от специалиста по тестированию гибкости и способности самостоятельно разбираться в функциональности программ.

Дефект, ошибка и отказ

Собрав информацию о потребностях пользователей и проработав требования, все данные передаются программистам. Они, изучив их, начинают разрабатывать программу, реализовывая то, что зафиксировано в требованиях. В процессе написания кода программисты могут допустить ошибку и прописать неверные данные в коде. К примеру, разрабатывая программу сложения чисел программист в строке, где должно происходить сложение, вместо знака «плюс» прописал знак «минус». Так была допущена ошибка:

Ошибка – действие человека, которое приводит к неправильному результату.

После написания кода программы её специальными инструментами «собирают», чтобы она стала полноценной работающей программой, а не набором файлов со строками кода. Собрали, внедрили и начали процесс эксплуатации. В момент использования программы пользователи столкнутся с ситуацией, когда программа работает не так, как ожидалось, когда реальный результат не равен ожидаемому.

Если рассматривать приведённый пример с программой сложения чисел, пользователь ожидает, что, введя два числа и нажав на кнопку сложения, получит результат сложения. Однако его ждёт разочарование, так как программа будет вычитать и выводить результат вычитания, а это означает, что она не сможет выполнять требуемую от неё функцию. Почему? Потому что на этапе разработки допустили ошибку, и пользователь столкнулся с последствиями ранее допущенной ошибки – с дефектом в программе.

Дефект – изъян в программе, который может привести к невозможности выполнить требуемую функцию.

Чтобы дефекты не попадали к пользователям, они должны выявляться специалистами по тестированию до передачи программы в эксплуатацию.

В ходе работы программы дефекты могут привести к отказу. Пример: программист, создавая программу, не добавил в код проверку, запрещающую программе складывать текст с числами. В этом случае появится дефект, который приведёт к отказу программы, и она попытается аварийно завершить свою работу:

Отказ – нарушение работоспособности программы, при котором она перестаёт выполнять целиком или частично свои функции.

В итоге получаем следующую последовательность: допущенная программистом в коде ошибка приводит к появлению в программе дефекта, и при работе он может повлечь отказ программы. В свою очередь отказ может привести к большим финансовым потерям компании или к катастрофе, если речь идёт об атомных реакторах или самолётах. Всё зависит от информационной системы, в которой произошёл отказ.

Дефекты могут появляться не только из-за допущенных в коде программ ошибок, но и из-за ошибок в настройках. К примеру, у нас есть требования, что в интернет-магазине заказы могу оплачивать все категории покупателей. Настраивая интернет-магазин, специалист по невнимательности указал, что оплачивать заказы могут только пользователи, которые не вошли в систему (анонимные пользователи). В этом случае не смогут оплачивать заказы те, кто вошли в систему (авторизованные пользователи). В итоге допущенная в настройках ошибка привела к появлению дефекта (невозможно выполнить требуемую функцию) и отказу системы (программа перестаёт выполнять свои функции) при оплате заказов авторизованными пользователями.

Критичность и приоритет

Мы определили следующее: чтобы дефекты не попадали к пользователям, они должны выявляться специалистами по тестированию до передачи программы в эксплуатацию. Если на ранних этапах дефекты не обнаружатся и попадут с программой к пользователям, то они будут оказывать влияние на работу самих пользователей. К примеру, бухгалтер на неработающем программном калькуляторе не может складывать числа, а это влияет на его труд. Он работает медленно, так как ему надо просчитать множество значений столбиком на листочке. Если бухгалтер вовремя не заполнит и не отправит отчёт в контролирующий орган, тот выставит штраф организации за несвоевременное предоставление отчётов, и организация понесёт финансовые потери.

Ещё пример. Разрабатывая калькулятор, допустили ошибку и вместо знака «плюс» на кнопке отображается буква «П». Бухгалтер, немного изучив программу, понял: по этой кнопке происходит сложение чисел, вовремя заполнил отчёты и сдал их в контролирующий органы. Во время работы он чувствовал неудобство, поскольку приходилось постоянно помнить, что означает буква «П» на кнопке калькулятора, но это не оказало критичного влияния на его работу и на организацию в целом.

Мы видим, что дефекты оказывают разное влияние на программу и пользователей. Одни дефекты незначительны и не доставляют особых проблем, а другие полностью блокируют работу. Всё зависит от степени критичности дефекта – её ещё называют «серьёзностью дефекта».

Критичность – важность воздействия конкретного дефекта на функционирование и возможность использования программы.

У дефектов есть пять уровней критичности:

– блокирующий;

– критический;

– значительный;

– незначительный;

– тривиальный.

Блокирующий – дефект полностью блокирует выполнение функционала программы, и нет никакого способа его обойти.

Рассмотрим блокирующий дефект на примере программы для сложения чисел. В ней есть кнопка «Сложить», однако она заблокирована, и введя числа для сложения мы не можем их никак сложить. У нас нет возможности обойти этот дефект и каким-либо образом запустить функцию сложения в программе.

Критический – дефект блокирует выполнение функционала программы, но есть альтернативный путь для его обхода.

Рассмотрим критический дефект на примере. В программе есть кнопка «Сложить», однако она заблокирована, и введя числа для сложения мы не можем их сложить с помощью данной кнопки. Но у нас есть возможность обойти данный дефект: необходимо после ввода чисел установить курсор мыши на любое поле для ввода числа и нажать кнопку «Enter» на клавиатуре, и программа произведёт сложение.

Значительный – дефект, указывающий на некорректную работу функционала программы. Проявляется не тем, что функция не работает, а тем, что она работает неправильно.

Рассмотрим значительный дефект на том же примере программы для сложения чисел. Кнопка «Сложить» работает: мы вводим числа в поля для ввода и нажимаем на неё. Программа складывает числа и выводит результат сложения, однако при этом программа перестаёт отвечать на действия пользователя на определённое время (зависает). Через минуту программа снова начинает отвечать на действия пользователя. И так происходит после каждого сложения.

Незначительный – дефект, не относящийся к функциональности программы, очевидная проблема пользовательского интерфейса.

Пример незначительного дефекта. У программы есть кнопка, при нажатии на которую в программе очищаются все поля. В требованиях прописано, что кнопка должна именоваться «Очистить». При разработке программы указали некорректную надпись «Пусто» у кнопки. Она продолжает выполнять свою функцию, но название неверное – не соответствует требованиям.

Незначительная критичность указывается у тех дефектов, которые относятся к удобству использования программы или к интерфейсу программы.

Тривиальный – дефект, не затрагивающий функциональность программы, а также оказывающий минимальное влияние на общее качество работы программы.

Обычно тривиальные дефекты – это грамматические ошибки в интерфейсе программы или в сопроводительной документации к программе, а также дефекты сторонних библиотек или сервисов, не относящихся к самой программе. Часто они трудно отличимы от дефектов незначительной критичности.

Пример тривиального дефекта. Есть библиотека^[7] стороннего программиста, в которой прописано: если хочешь получить картинку с природой, то запроси картинку, передав библиотеке слово «природа», картинку с небом – «небо», и так далее. Разрабатывая программу сложения чисел мы решили, что будет замечательно, если интерфейс (фон) программы сделать не одноцветным, а использовать какое-либо изображение, к примеру – изображение неба. Мы это реализовали. Теперь, когда мы запускаем программу, она подключается к библиотеке стороннего программиста и запрашивает у неё картинку неба, передавая библиотеке слово «небо». Однако библиотека возвращает картинку с природой, и мы видим оформление программы с фоном природы. Это явная ошибка в сторонней библиотеке, а не нашей программы. Но так как наша программа использует в своей работе эту стороннюю библиотеку, мы заводим дефект для нашего программиста, чтобы он исправил дефект, связанный с внешним оформлением нашей программы.

Для корректного определения критичности дефектов специалисты по тестированию должны в деталях знать функциональность тестируемой программы и особенности её работы. Это один из признаков, который характеризует хороших тестировщиков.

Кроме критичности у дефектов есть приоритет. В процессе разработки программы специалисты по тестированию находят множество дефектов и каждому присваивают критичность. Через определённое время набирается несколько десятков дефектов, которые необходимо устранять с помощью правки программного кода программистом. Он готов устранять дефекты, однако не может одновременно исправлять все. В этот момент ответственные специалисты собираются для определения порядка исправления дефектов. То есть занимаются приоритизацией^[8]. Она помогает определить, какие дефекты нужно устранить в первую очередь. Когда специалисты приоритизируют дефекты, они присваивают им определённый приоритет.

Приоритет – степень важности, присваиваемая объекту, которая указывает на очерёдность устранения дефекта или очерёдность выполнения задачи.

Обратите внимание: приоритет есть не только у дефектов, но и у задач^[9] (заявок на изменение). Приоритеты у дефектов сообщают нам, в какой очерёдности необходимо устранять дефекты. Приоритеты у задач сообщают, в какой очерёдности необходимо выполнять задачи. Ещё важный момент: в отличие от критичности, приоритет есть и у дефектов, и у задач. Критичность же есть только у дефектов.

У приоритета существует три уровня:

– высокий;

– средний;

– низкий.

В ряде компаний могут вводить дополнительные уровни.

Высокий – требуется устранить или выполнить в первую очередь.

Средний – требуется устранить или выполнить во вторую очередь, когда нет дефектов и задач с высоким приоритетом.

Низкий – требуется устранить или выполнить в последнюю очередь, когда все дефекты и задачи с более высокими приоритетами уже выполнены.

Указание критичности и приоритета является важной частью процесса разработки и тестирования, так как данные атрибуты однозначно классифицируют дефекты по степени их влияния на систему и очерёдность их исправления:

Не во всех организациях используют одновременно два атрибута, чаще всего только приоритет, который логически объединяет оба атрибута, однако это некорректно.

Зачем нужны оба атрибута? Допустим, есть программа, и в ней нашли два дефекта.

Дефект № 1 – не работает функциональность формирования годового отчёта для бухгалтера, которым он должен будет воспользоваться в начале следующего года. Дефект по критичности «блокирующий».

Дефект № 2 – на главной странице сайта есть логотип, в котором имеется опечатка, буквы «к» и «ё» заменили на «т» и «е», и название компании «Клён» читается как «Тлен». Дефект по критичности «тривиальный».

Дефект № 2 может сильно подорвать доверие пользователей к компании и продукции, которую они предлагают, что в свою очередь может повлиять на продажи организации и прибыль. Это зависит от компании и её места на рынке. Дефект № 1 блокирующий, но функционалом не будут пользоваться ещё более полугода, так как сейчас, допустим, лето. В связи с вышесказанным, руководители установят дефекту № 2 высокий приоритет на устранение, а дефекту № 1 средний. Первым будет устраняться дефект № 2.

Приоритеты постоянно пересматриваются, так как они зависят от многих факторов. К примеру, если наступит начало года и отчётный период, а дефект № 1 не позволяет бухгалтерам создавать и отправлять отчёты, то приоритеты у дефектов будут изменены. Дефект № 1 получит высокий приоритет на устранение, а дефект № 2 – средний.