Дефект – изъян в программе, который может привести к невозможности выполнить требуемую функцию.
Чтобы дефекты не попадали к пользователям, они должны выявляться специалистами по тестированию до передачи программы в эксплуатацию.
В ходе работы программы дефекты могут привести к отказу. Пример: программист, создавая программу, не добавил в код проверку, запрещающую программе складывать текст с числами. В этом случае появится дефект, который приведёт к отказу программы, и она попытается аварийно завершить свою работу:
Отказ – нарушение работоспособности программы, при котором она перестаёт выполнять целиком или частично свои функции.
В итоге получаем следующую последовательность: допущенная программистом в коде ошибка приводит к появлению в программе дефекта, и при работе он может повлечь отказ программы. В свою очередь отказ может привести к большим финансовым потерям компании или к катастрофе, если речь идёт об атомных реакторах или самолётах. Всё зависит от информационной системы, в которой произошёл отказ.
Дефекты могут появляться не только из-за допущенных в коде программ ошибок, но и из-за ошибок в настройках. К примеру, у нас есть требования, что в интернет-магазине заказы могу оплачивать все категории покупателей. Настраивая интернет-магазин, специалист по невнимательности указал, что оплачивать заказы могут только пользователи, которые не вошли в систему (анонимные пользователи). В этом случае не смогут оплачивать заказы те, кто вошли в систему (авторизованные пользователи). В итоге допущенная в настройках ошибка привела к появлению дефекта (невозможно выполнить требуемую функцию) и отказу системы (программа перестаёт выполнять свои функции) при оплате заказов авторизованными пользователями.
Критичность и приоритет
Мы определили следующее: чтобы дефекты не попадали к пользователям, они должны выявляться специалистами по тестированию до передачи программы в эксплуатацию. Если на ранних этапах дефекты не обнаружатся и попадут с программой к пользователям, то они будут оказывать влияние на работу самих пользователей. К примеру, бухгалтер на неработающем программном калькуляторе не может складывать числа, а это влияет на его труд. Он работает медленно, так как ему надо просчитать множество значений столбиком на листочке. Если бухгалтер вовремя не заполнит и не отправит отчёт в контролирующий орган, тот выставит штраф организации за несвоевременное предоставление отчётов, и организация понесёт финансовые потери.
Ещё пример. Разрабатывая калькулятор, допустили ошибку и вместо знака «плюс» на кнопке отображается буква «П». Бухгалтер, немного изучив программу, понял: по этой кнопке происходит сложение чисел, вовремя заполнил отчёты и сдал их в контролирующий органы. Во время работы он чувствовал неудобство, поскольку приходилось постоянно помнить, что означает буква «П» на кнопке калькулятора, но это не оказало критичного влияния на его работу и на организацию в целом.
Мы видим, что дефекты оказывают разное влияние на программу и пользователей. Одни дефекты незначительны и не доставляют особых проблем, а другие полностью блокируют работу. Всё зависит от степени критичности дефекта – её ещё называют «серьёзностью дефекта».
Критичность – важность воздействия конкретного дефекта на функционирование и возможность использования программы.
У дефектов есть пять уровней критичности:
– блокирующий;
– критический;
– значительный;
– незначительный;
– тривиальный.
Блокирующий – дефект полностью блокирует выполнение функционала программы, и нет никакого способа его обойти.
Рассмотрим блокирующий дефект на примере программы для сложения чисел. В ней есть кнопка «Сложить», однако она заблокирована, и введя числа для сложения мы не можем их никак сложить. У нас нет возможности обойти этот дефект и каким-либо образом запустить функцию сложения в программе.
Критический – дефект блокирует выполнение функционала программы, но есть альтернативный путь для его обхода.
Рассмотрим критический дефект на примере. В программе есть кнопка «Сложить», однако она заблокирована, и введя числа для сложения мы не можем их сложить с помощью данной кнопки. Но у нас есть возможность обойти данный дефект: необходимо после ввода чисел установить курсор мыши на любое поле для ввода числа и нажать кнопку «Enter» на клавиатуре, и программа произведёт сложение.
Значительный – дефект, указывающий на некорректную работу функционала программы. Проявляется не тем, что функция не работает, а тем, что она работает неправильно.
Рассмотрим значительный дефект на том же примере программы для сложения чисел. Кнопка «Сложить» работает: мы вводим числа в поля для ввода и нажимаем на неё. Программа складывает числа и выводит результат сложения, однако при этом программа перестаёт отвечать на действия пользователя на определённое время (зависает). Через минуту программа снова начинает отвечать на действия пользователя. И так происходит после каждого сложения.
Незначительный – дефект, не относящийся к функциональности программы, очевидная проблема пользовательского интерфейса.
Пример незначительного дефекта. У программы есть кнопка, при нажатии на которую в программе очищаются все поля. В требованиях прописано, что кнопка должна именоваться «Очистить». При разработке программы указали некорректную надпись «Пусто» у кнопки. Она продолжает выполнять свою функцию, но название неверное – не соответствует требованиям.
Незначительная критичность указывается у тех дефектов, которые относятся к удобству использования программы или к интерфейсу программы.
Тривиальный – дефект, не затрагивающий функциональность программы, а также оказывающий минимальное влияние на общее качество работы программы.
Обычно тривиальные дефекты – это грамматические ошибки в интерфейсе программы или в сопроводительной документации к программе, а также дефекты сторонних библиотек или сервисов, не относящихся к самой программе. Часто они трудно отличимы от дефектов незначительной критичности.
Пример тривиального дефекта. Есть библиотека[7 - Программная библиотека – это набор готовых частей программного кода, которые могут использоваться для создания других программ.] стороннего программиста, в которой прописано: если хочешь получить картинку с природой, то запроси картинку, передав библиотеке слово «природа», картинку с небом – «небо», и так далее. Разрабатывая программу сложения чисел мы решили, что будет замечательно, если интерфейс (фон) программы сделать не одноцветным, а использовать какое-либо изображение, к примеру – изображение неба. Мы это реализовали. Теперь, когда мы запускаем программу, она подключается к библиотеке стороннего программиста и запрашивает у неё картинку неба, передавая библиотеке слово «небо». Однако библиотека возвращает картинку с природой, и мы видим оформление программы с фоном природы. Это явная ошибка в сторонней библиотеке, а не нашей программы. Но так как наша программа использует в своей работе эту стороннюю библиотеку, мы заводим дефект для нашего программиста, чтобы он исправил дефект, связанный с внешним оформлением нашей программы.
Для корректного определения критичности дефектов специалисты по тестированию должны в деталях знать функциональность тестируемой программы и особенности её работы. Это один из признаков, который характеризует хороших тестировщиков.
Кроме критичности у дефектов есть приоритет. В процессе разработки программы специалисты по тестированию находят множество дефектов и каждому присваивают критичность. Через определённое время набирается несколько десятков дефектов, которые необходимо устранять с помощью правки программного кода программистом. Он готов устранять дефекты, однако не может одновременно исправлять все. В этот момент ответственные специалисты собираются для определения порядка исправления дефектов. То есть занимаются приоритизацией[8 - Приоритизация – это процесс определения того, что является важным и должно быть выполнено первым, а что менее важно и может быть выполнено позже.]. Она помогает определить, какие дефекты нужно устранить в первую очередь. Когда специалисты приоритизируют дефекты, они присваивают им определённый приоритет.
Приоритет – степень важности, присваиваемая объекту, которая указывает на очерёдность устранения дефекта или очерёдность выполнения задачи.
Обратите внимание: приоритет есть не только у дефектов, но и у задач[9 - Задача, заявка на изменение (ЗнИ) – это запрос, который предлагает внести изменения в программу. Он может быть создан как внутри организации, так и внешними пользователями. Он фиксируется и оценивается командой, которая разрабатывает программу. Запрос проходит процесс оценки и утверждения, прежде чем быть включённым в планы на реализацию.] (заявок на изменение). Приоритеты у дефектов сообщают нам, в какой очерёдности необходимо устранять дефекты. Приоритеты у задач сообщают, в какой очерёдности необходимо выполнять задачи. Ещё важный момент: в отличие от критичности, приоритет есть и у дефектов, и у задач. Критичность же есть только у дефектов.
У приоритета существует три уровня:
– высокий;
– средний;
– низкий.
В ряде компаний могут вводить дополнительные уровни.
Высокий – требуется устранить или выполнить в первую очередь.
Средний – требуется устранить или выполнить во вторую очередь, когда нет дефектов и задач с высоким приоритетом.
Низкий – требуется устранить или выполнить в последнюю очередь, когда все дефекты и задачи с более высокими приоритетами уже выполнены.
Указание критичности и приоритета является важной частью процесса разработки и тестирования, так как данные атрибуты однозначно классифицируют дефекты по степени их влияния на систему и очерёдность их исправления:
Не во всех организациях используют одновременно два атрибута, чаще всего только приоритет, который логически объединяет оба атрибута, однако это некорректно.
Зачем нужны оба атрибута? Допустим, есть программа, и в ней нашли два дефекта.
Дефект № 1 – не работает функциональность формирования годового отчёта для бухгалтера, которым он должен будет воспользоваться в начале следующего года. Дефект по критичности «блокирующий».
Дефект № 2 – на главной странице сайта есть логотип, в котором имеется опечатка, буквы «к» и «ё» заменили на «т» и «е», и название компании «Клён» читается как «Тлен». Дефект по критичности «тривиальный».
Дефект № 2 может сильно подорвать доверие пользователей к компании и продукции, которую они предлагают, что в свою очередь может повлиять на продажи организации и прибыль. Это зависит от компании и её места на рынке. Дефект № 1 блокирующий, но функционалом не будут пользоваться ещё более полугода, так как сейчас, допустим, лето. В связи с вышесказанным, руководители установят дефекту № 2 высокий приоритет на устранение, а дефекту № 1 средний. Первым будет устраняться дефект № 2.
Приоритеты постоянно пересматриваются, так как они зависят от многих факторов. К примеру, если наступит начало года и отчётный период, а дефект № 1 не позволяет бухгалтерам создавать и отправлять отчёты, то приоритеты у дефектов будут изменены. Дефект № 1 получит высокий приоритет на устранение, а дефект № 2 – средний.
Что такое тестирование
Мы познакомились со специалистами по тестированию и с деятельностью, которой они занимаются. Также изучили, что из себя представляют программы и информационные системы. Настал момент рассмотреть подробнее, что же такое тестирование.
В современном мире программы являются неотъемлемой частью нашей жизни. Они применяются во многих сферах: программы для бизнеса; персональные приложения и игры; программы и микропрограммы в технике (например, телевизоры, стиральные машины). В своей повседневности вы постоянно сталкиваетесь с программами определённого рода.
Мы уже знаем, что программы, работающие некорректно, могут привести к проблемам – потеря времени, денег, деловой репутации, а также могут стать причиной травм и даже смерти. Скорее всего кто-то из вас имел опыт использования программ, которые работали не так, как ожидалось.
Специалисты по тестированию минимизируют риски, выявляя ошибки в программах. Однако это не единственная цель их работы и тестирования в целом. В чём тогда заключается цель тестирования? Она заложена в самом его определении. Рассмотрим ряд существующих неполных и неточных определений тестирования:
– Тестирование ПО – это процесс поиска ошибок в программе. Здесь подразумевается, что мы целенаправленно стараемся найти в программе максимальное количество ошибок.
– Тестирование ПО – это процесс проверки, который гарантирует, что программа работает безошибочно. Здесь имеется в виду, что мы не ищем ошибки, а проводим ряд проверок, чтобы убедиться, что требуемые нам операции отработали без ошибок.
– Тестирование ПО – это процесс, который направлен на подтверждение соответствия программы требованиям, поставленным заказчиком[10 - Заказчик – лицо, заинтересованное в разработке программы для своих нужд или для дальнейшей продажи программы пользователям. Заказчиками могут быть физические или юридические лица.]. Здесь подразумевается следующее: мы проверяем, что в программе реализовано то, что попросил заказчик.
Ни одно из этих определений не является полностью верным или точным, так как тестирование – это более сложный и многогранный процесс, который включает в себя множество активностей, методов и подходов. На основании всего вышесказанного выведем определение.
Тестирование ПО – это процесс исследования, испытания программы, с целью продемонстрировать заказчикам и/или заинтересованным лицам, что программа соответствует установленным требованиям, а также это процесс проверки соответствия между реальным поведением программы и ожидаемым поведением, и выявление ситуаций, в которых поведение программы является неправильным или нежелательным.
Данное определение даёт полное понимание, что из себя представляет тестирование программного обеспечения. И ничего сверх того, что сказано в определении, не добавить.
Цели тестирования
Мы уже знаем и понимает, что такое тестирование, кто его проводит и что тестируется. Но с какой целью всё это осуществляется? Чтобы ответить на этот вопрос, необходимо рассмотреть цели тестирования программного обеспечения.
Цель – это то, ради чего осуществляется какой-либо процесс. Правильно определённая цель позволяет эффективно организовать работу и направить усилия всех участников на достижение желаемого результата. Перечислим цели тестирования, которые применимы к любой разработке.
Цель № 1. Оценка состояния требований, пользовательских историй, проектной документации или написанного кода для выявления расхождений с первоначально запланированными результатами и формирования предложений по их улучшению. Специалисты проводят детальный анализ всех имеющихся артефактов проектирования и разработки программного обеспечения – требований, пользовательских историй, технического задания, дизайн-документации, написанного кода. Цель данного анализа – проверить их корректность и соответствие первоначальному замыслу и плану. Специалисты ищут расхождения между тем, что было описано или запланировано на этапе проектирования, и тем, как это выглядит на данный момент на этапе разработки. Выявленные расхождения анализируются и на их основе разрабатываются конкретные предложения по улучшению.
Цель № 2. Проверка выполнения всех требований, т. е. проверка, что разработанное программное обеспечение полностью отвечает всем изначально заявленным пользовательским нуждам и ожиданиям. При разработке программного обеспечения сначала определяются все необходимые функции и возможности, которыми должна обладать программа. Это фиксируется в виде требований к программе. Затем приступают к непосредственной разработке самого программного кода. Программисты стараются реализовать все заявленные в требованиях функции. Однако чтобы убедиться, что разработанная программа действительно соответствует изначальным требованиям, проводится его тестирование. В ходе тестирования проверяется, был ли воплощён в жизнь каждый пункт требований. То есть проверяется, реализован ли в программном коде весь функционал, который был описан на этапе определения требований.
