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

1.

Тестирование

2.

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

3.

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

4.

Основные понятия и определения
• Верификация (Verification) - это процесс оценки системы или её компонентов с целью определения
удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа .
Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей
фазы.
• Валидация (Validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям
пользователя, требованиям к системе.
• План Тестирования (Test Plan) - это документ, описывающий весь объем работ по тестированию, начиная с
описания объекта, стратегии, критериев начала и окончания тестирования, до необходимого в процессе
работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
• Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором проектируются и создаются
тестовые случаи (тест кейсы), в соответствии с определёнными ранее критериями качества и целями
тестирования.
• Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных условий и
параметров, необходимых для проверки реализации тестируемой функции или её части.
• Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность действий
приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

5.

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

6.

Зачем?
После выяснения цели, меняется или вовсе
устраняется задача.
Например

7.

Что?
Цель достигается разными путями. И второй важный шаг
при разработке требований как раз про выбор пути — что
конкретно мы будем делать, чтобы прийти к цели.
Например

8.

Виды тестирования

9.

Функциональное тестирование или
Functional Testing
Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе
спецификаций функциональности компонента или системы в целом.
Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех
уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции
описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use
cases).
Тестирование функциональности может проводиться в двух аспектах:
• требования
• бизнес-процессы
Преимущества функционального тестирования:
• имитирует фактическое использование системы;
Недостатки функционального тестирования:
• возможность упущения логических ошибок в программном обеспечении;
• вероятность избыточного тестирования.

10.

Тестирование безопасности или Security
and Access Control Testing
Тестирование безопасности - это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа
рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к
конфиденциальным данным.
Принципы безопасности программного обеспечения
Общая стратегия безопасности основывается на трех основных принципах:
• конфиденциальность
• целостность
• Доступность
Конфиденциальность - это сокрытие определенных ресурсов или информации. Под конфиденциальностью можно понимать
ограничение доступа к ресурсу некоторой категории пользователей, или другими словами, при каких условиях пользователь
авторизован получить доступ к данному ресурсу.
Целостность
Существует два основных критерия при определении понятия целостности:
• Доверие. Ожидается, что ресурс будет изменен только соответствующим способом определенной группой пользователей.
• Повреждение и восстановление. В случае когда данные повреждаются или неправильно меняются авторизованным или не
авторизованным пользователем, вы должны определить на сколько важной является процедура восстановления данных.
Доступность представляет собой требования о том, что ресурсы должны быть доступны авторизованному пользователю, внутреннему
объекту или устройству. Как правило, чем более критичен ресурс тем выше уровень доступности должен быть.

11.

Виды уязвимостей
• В настоящее время наиболее распространенными видами уязвимости в безопасности программного
обеспечения являются:
• XSS (Cross-Site Scripting) - это вид уязвимости программного обеспечения (Web приложений), при которой,
на генерированной сервером странице, выполняются вредоносные скрипты, с целью атаки клиента.
• XSRF / CSRF (Request Forgery) - это вид уязвимости, позволяющий использовать недостатки HTTP
протокола, при этом злоумышленники работают по следующей схеме: ссылка на вредоносный сайт
устанавливается на странице, пользующейся доверием у пользователя, при переходе по вредоносной ссылке
выполняется скрипт, сохраняющий личные данные пользователя (пароли, платежные данные и т.д.), либо
отправляющий СПАМ сообщения от лица пользователя, либо изменяет доступ к учетной записи пользователя,
для получения полного контроля над ней.
• Code injections (SQL, PHP, ASP и т.д.) - это вид уязвимости, при котором становится возможно осуществить
запуск исполняемого кода с целью получения доступа к системным ресурсам, несанкционированного доступа к
данным либо выведения системы из строя.
• Server-Side Includes (SSI) Injection - это вид уязвимости, использующий вставку серверных команд в HTML
код или запуск их напрямую с сервера.
• Authorization Bypass - это вид уязвимости, при котором возможно получить несанкционированный доступ к
учетной записи или документам другого пользователя

12.

Тестирование взаимодействия или
Interoperability Testing
С развитием сетевых технологий и интернета взаимодействие разных систем,
сервисов и приложений друг с другом приобрело значительную актуальность, так как
любые связанные с этим проблемы могут привести к падению авторитета компании,
что как следствие повлечет за собой финансовые потери. Поэтому к тестированию
взаимодействия стоит подходить со всей серьезностью.
Тестирование взаимодействия (Interoperability Testing) – это функциональное
тестирование, проверяющее способность приложения взаимодействовать с одним и
более компонентами или системами и включающее в себя тестирование
совместимости (compatibility testing) и интеграционное тестирование (integration
testing).
Программное обеспечение с хорошими характеристиками взаимодействия может
быть легко интегрировано с другими системами, не требуя каких-либо серьезных
модификаций. В этом случае, количество изменений и время, требуемое на их
выполнение, могут быть использованы для измерения возможности взаимодействия.

13.

Нагрузочное тестирование или
тестирование производительности
Нагрузочное тестирование или тестирование производительности - это
автоматизированное тестирование, имитирующее работу определенного количества
бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.
Основные виды тестирования производительности
Тестирование производительности (Performance testing)
Задачей тестирования производительности является определение масштабируемости
приложения под нагрузкой, при этом происходит:
• измерение времени выполнения выбранных операций при определенных
интенсивностях выполнения этих операций
• определение количества пользователей, одновременно работающих с
приложением
• определение границ приемлемой производительности при увеличении нагрузки
(при увеличении интенсивности выполнения этих операций)
• исследование производительности на высоких, предельных, стрессовых нагрузках

14.

Дымовое тестирование или Smoke Testing
Понятие дымовое тестирование пошло из инженерной среды:
"При вводе в эксплуатацию нового оборудования ("железа") считалось, что
тестирование прошло удачно, если из установки не пошел дым."
В области же программного обеспечения, дымовое тестирование
рассматривается как короткий цикл тестов, выполняемый для подтверждения
того, что после сборки кода (нового или исправленного) устанавливаемое
приложение, стартует и выполняет основные функции.
Вывод о работоспособности основных функций делается на основании
результатов поверхностного тестирования наиболее важных модулей
приложения на предмет возможности выполнения требуемых задач и
наличия быстронаходимых критических и блокирующих дефектов. В случае
отсутствия таковых дефектов дымовое тестирование объявляется
пройденным, и приложение передается для проведения полного цикла
тестирования, в противном случае, дымовое тестирование объявляется
проваленным, и приложение уходит на доработку.

15.

Тестирование сборки или Build Verification
Test
Тестирование направленное на определение соответствия,
выпущенной версии, критериям качества для начала тестирования.
По своим целям является аналогом Дымового Тестирования,
направленного на приемку новой версии в дальнейшее
тестирование или эксплуатацию. Вглубь оно может проникать
дальше, в зависимости от требований к качеству выпущенной
версии.

16.

Регрессионное тестирование или
Regression Testing
Регрессионное тестирование - это вид тестирования направленный
на проверку изменений, сделанных в приложении или
окружающей среде (починка дефекта, слияние кода, миграция на
другую операционную систему, базу данных, веб сервер или
сервер приложения), для подтверждения того факта, что
существующая ранее функциональность работает как и прежде
(см. также Санитарное тестирование или проверка
согласованности/исправности). Регрессионными могут быть как
функциональные, так и нефункциональные тесты.

17.

Тестирование Установки или Installation
Testing
Тестирование установки направленно на проверку успешной
инсталляции и настройки, а также обновления или удаления
программного обеспечения.
В настоящий момент наиболее распространена установка ПО при
помощи инсталляторов (специальных программ, которые сами по себе
так же требуют надлежащего тестирования, описание которого
рассмотрено в разделе "Особенности тестирования инсталляторов.").
В реальных условиях инсталляторов может не быть. В этом случае
придется самостоятельно выполнять установку программного
обеспечения, используя документацию в виде инструкций или readme
файлов, шаг за шагом описывающих все необходимые действия и
проверки.

18.

Тестирование удобства пользования или
Usability Testing
Иногда мы сталкиваемся с непонятными, нелогичными приложениями,
многие функции и способы использования которых часто не очевидны. После
такой работы редко возникает желание использовать приложение снова, и мы
ищем более удобные аналоги. Для того чтобы приложение было популярным,
ему мало быть функциональным – оно должно быть еще и удобным. Если
задуматься, интуитивно понятные приложения экономят нервы
пользователям и затраты работодателя на обучение. А значит они более
конкурентоспособные! Поэтому тестирование удобства использования, о
котором пойдет речь далее является неотъемлемой частью тестирования
любых массовых продуктов.
Тестирование удобства пользования - это метод тестирования, направленный
на установление степени удобства использования, обучаемости, понятности и
привлекательности для пользователей разрабатываемого продукта в
контексте заданных условий.

19.

Тестирование на отказ и восстановление
(Failover and Recovery Testing)
• Тестирование на отказ и восстановление (Failover and Recovery
Testing) проверяет тестируемый продукт с точки зрения
способности противостоять и успешно восстанавливаться после
возможных сбоев, возникших в связи с ошибками программного
обеспечения, отказами оборудования или проблемами связи
(например, отказ сети). Целью данного вида тестирования
является проверка систем восстановления (или дублирующих
основной функционал систем), которые, в случае возникновения
сбоев, обеспечат сохранность и целостность данных тестируемого
продукта.

20.

Конфигурационное тестирование или
Configuration Testing
Конфигурационное тестирование (Configuration Testing) — специальный вид
тестирования, направленный на проверку работы программного обеспечения при
различных конфигурациях системы (заявленных платформах, поддерживаемых
драйверах, при различных конфигурациях компьютеров и т.д.)
В зависимости от типа проекта конфигурационное тестирование может иметь разные
цели:
1) Проект по профилированию работы системы
Цель Тестирования: определить оптимальную конфигурацию оборудования,
обеспечивающую требуемые характеристики производительности и времени
реакции тестируемой системы.
2) Проект по миграции системы с одной платформы на другую
Цель Тестирования: Проверить объект тестирования на совместимость с
объявленным в спецификации оборудованием, операционными системами и
программными продуктами третьих фирм.

21.

БЕЛЫЙ, СЕРЫЙ И ЧЕРНЫЙ ЯЩИК
Существует три подхода к тестированию программного
обеспечения: тестирование белого, серого и черного ящиков.
Каждый из них рассматривает процесс с иной точки зрения, и не
может быть использован как единственный подход. Завершение
всех трех этапов гарантирует качество продукта.

22.

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

23.

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

24.

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

25.

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

26.

Преимущества и недостатки тестирования
Черного Ящика
Преимущества тестирования Черного Ящика:
• Разработчик и тестировщик работают независимо друг от друга
• Тестировщику не нужны знания каких-либо конкретных языков программирования
• Тест выполняется с точки зрения пользователя, а не разработчика
• Тестовые сценарии могут быть разработаны, как только спецификации будут ясны.
Недостатки тестирования Черного Ящика:
• Тест может быть бесполезным, если разработчик программного обеспечения уже
запустил тестовый сценарии
• Тестовые сценарии сложно спроектировать
• Тестирование всех возможных потоков ввода нереально, потому что это займет
слишком много времени. Поэтому лишь многие пути программы будут
протестированы.

27.

Тестирование серого ящика
Проверка серого ящика (англ. grey box testing) – специальный метод тестирования программного обеспечения с
неполным знанием его внутреннего устройства. Чтобы выполнить подобный вид тестов, не нужно иметь доступ к
исходному коду ПО.
Основные преимущества метода:
• Имеет некоторые особенности черного и белого ящика. Иными словами, тестировщик смотрит на объект проверки
с позиции черного ящика, но проводит анализ системы с точным расчетом данных, которые ему предварительно
известны (белый ящик).
• Данная проверка позволяет программисту заручиться достаточным количеством времени для исправления багов.
• Программист взаимодействует с тестировщиком на начальном уровне, что позволяет сразу же убрать ненужные и
избыточные тест-кейсы.
Недостатки:
• Анализ программного кода ограничен, так как доступа к исходному коду у тестировщика нет.
• Нет времени тестировать все потоки ввода и вывода информации, так как это займет очень много времени.
• Возможна ситуация, когда тестировщики могут стать лишними (когда не только QA-специалист, но и программист
проверяет свой код с помощью юнит-тестов).

28.

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

29.

Жизненный цикл тестирования STLC
STLC, или жизненный цикл
тестирования — это
последовательность действий,
проводимых в процессе
тестирования, с помощью которых
гарантируется качество
программного обеспечения и его
соответствие требованиям. STLC
включает действия по
верификации и валидации.
Тестирование состоит из серии
действий, выполняемых по
методике, с целью гарантирования
качества продукта.
Цикл состоит из шести основных
этапов.

30.

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

31.

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

32.

Виды тестовой документации
Создание тестовой документации является вторым этапом жизненного
цикла ПО.
Тестовая документация включает в себя:
• тест план;
• тестовая стратегия;
• чек-лист;
• тестовый сценарий;
• тестовый комплект;
• пользовательская история (User Story);
• отчет о дефекте.

33.

Виды тестовой документации
Тест план (Test Plan) — это документ, описывающий весь объем работ по
тестированию, начиная с описания объекта, стратегии, расписания, критериев начала
и окончания тестирования, до необходимого в процессе работы оборудования,
специальных знаний, а также оценки рисков с вариантами их разрешения.
Хороший тест план должен описывать следующее:
• Что надо тестировать? Описание объекта тестирования: системы, приложения,
оборудования.
• Что будете тестировать? Список функций и описание тестируемой системы и её
компонент в отдельности.
• Как будете тестировать? Стратегия тестирования, а именно: виды тестирования и их
применение по отношению к объекту тестирования.
• Когда будете тестировать? Последовательность проведения работ: подготовка (Test
Preparation), тестирование (Testing), анализ результатов (Test Result Analisys) в
разрезе запланированных фаз разработки.

34.

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

35.

Тестовая стратегия

36.

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

37.

Тестовая документация. Тест кейс
Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных
условий и параметров, необходимых для проверки реализации тестируемой функции или её
части.

38.

Тестовая документация. Тест кейс
Создан (new) — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.
Запланирован (planned, ready for testing) — в этом состоянии тест-кейс находится, когда он или явно включён в план ближайшей итерации тестирования,
или, как минимум, готов для выполнения.
Не выполнен (not tested) — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение
тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
Выполняется (work in progress) — если тест-кейс требует длительное время для выполнения, то он может быть переведён в это состояние для
подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние,
как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».
Пропущен (skipped) — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики
тестирования.
Провален (failed) — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый
результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Пройден успешно (passed) — данное состояние означает, что
в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
Заблокирован (blocked) — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной
является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В
некоторых системах управления тест-кейс переводят в данное состояние, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия
с ним завершены.
Требует доработки (not ready) — как видно из схемы, в это состояние (или из него) тест-кейс может быть переведён в любой момент времени, если в нём
будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс
пригодным для выполнения и перевода в иные состояния.

39.

Отчёты о дефектах
Баг(дефект)— расхождение ожидаемого и фактического
результата.
Ожидаемый результат — поведение системы, описанное в
требованиях.
Фактический результат — поведение системы, наблюдаемое в
процессе тестирования.
Отчёт о дефекте — это документ, описывающий ситуацию или
последовательность действий приведшую к некорректной работе
объекта тестирования, с указанием причин и ожидаемого
результата.

40.

Виды ошибок

41.

Виды ошибок
• Ошибка — действие человека, приводящее к некорректным результатам. Этот
термин очень часто используют как наиболее универсальный, описывающий
любые проблемы («ошибка человека», «ошибка в коде», «ошибка в документации»
и т.п.
• Дефект — это отклонение от требований спецификаций или ожиданий
пользователей. Другими словами, дефект является ошибкой в ​кодировании или
логике, что приводит к сбою программы или созданию неправильного /
неожиданного результата. Это могут быть аппаратные средства, программное
обеспечение, сеть, производительность, формат или функциональность. Недостаток
в компоненте или системе, способный привести к ситуации сбоя или отказа.
• Сбой — самоустраняющийся отказ или однократный отказ, устраняемый
незначительным вмешательством.
• Отказ — событие, заключающееся в нарушении работоспособного состояния
объекта. Это неспособность системы или компонента выполнять требуемые
функции в рамках определенных требований к производительности. Неисправность
возникает при выполнении ошибки.

42.

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

43.

Тестовая документация. Чек-лист
Чек-лист — набор идей по тестированию, разработке, планированию и
управлению. А также, это перечень формализованных тестовых случаев
в удобном для проведения проверок виде. Тестовые случаи в чек-листе
не должны быть зависимыми друг от друга.
Обязательно должен содержать в себе следующую информацию:
• идея проверок;
• набор входных данных;
• ожидаемые результаты;
• булевая отметка о прохождении/непрохождении тестового случая;
• булевая отметка о совпадении/несовпадении фактического и
ожидаемого результата по каждой проверке.

44.

Тестовая документация. Чек-лист
Цель – обеспечить стабильность покрытия требований проверками необходимыми и
достаточными для заключения о соответствии им продукта. Особенностью является то, что
чек-листы компонуются теми тестовыми случаями, которые показательны для определенного
требования.
Чек-лист должен обладать рядом важных свойств:
• Логичность. Чек-лист пишется не «просто так», а на основе целей и для того, чтобы помочь в
достижении этих целей.
• Последовательность и структурированность. Со структурированностью всё достаточно
просто — она достигается за счёт оформления чек-листа в виде многоуровневого списка.
Что касается последовательности, то, даже в том случае, когда пункты чек-листа не
описывают цепочку действий, человеку всё равно удобнее воспринимать информацию в
виде неких небольших групп идей, переход между которыми является понятным и
очевидным.
• Полнота и неизбыточность. Чек-лист должен представлять собой аккуратную «сухую
выжимку» идей, в которых нет дублирования ( которые часто появляется из-за разных
формулировок одной и той же идеи) и, в то же время ничто важное не упущено.

45.

Правила составления чек-листов:
• Одна операция.
• Пункты чек-листа — это минимальные полные операции. Например,
заказать изготовление визиток и доставить визитки в офис — это 2
разных операции. Поэтому в чек-листе они отображаются отдельными
пунктами: визитки заказаны и визитки доставлены в офис.
• Пункты пишутся в утвердительной форме. Цель чек-листа – проверка
готовности задачи, поэтому лучше составлять пункты в утвердительной
форме — «заказаны, доставлены». Сравните формулировку: «заказать
визитки» и «визитки заказаны».
• Оптимальное количество пунктов — до 20. Чек-листы не должны быть
длинными. Если все же это требуется, то лучше разбить задачу на
несколько этапов и составить к каждому этапу отдельный чек-лист.

46.

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

47.

Тестовая документация. Чек-лист

48.

Отчётность в тестировании
Отчётность — сбор и распространение информации о результатах работы
(включая текущий статус, оценку прогресса и прогноз развития ситуации).
К высокоуровневым задачам отчётности относятся:
• Сбор, агрегация и предоставление в удобной для восприятия форме
объективной информации о результатах работы.
• Формирование оценки текущего статуса и прогресса (в сравнении с планом).
• Обозначение существующих и возможных проблем (если такие есть).
• Формирование прогноза развития ситуации и фиксация рекомендаций по
устранению проблем и повышению эффективности работы.
Отчёт о результатах тестирования — документ, обобщающий результаты
работ по тестированию и содержащий информацию, достаточную для
соотнесения текущей ситуации с тест-планом и принятия необходимых
управленческих решений.

49.

Отчётность в тестировании
К низкоуровневым задачам отчётности в тестировании относятся:
• Оценка объёма и качества выполненных работ.
• Сравнение текущего прогресса с тест-планом (в том числе с помощью анализа значений
метрик).
• Описание имеющихся сложностей и формирование рекомендаций по их устранению.
• Предоставление лицам, заинтересованным в проекте, полной и объективной информации о
текущем состоянии качества проекта, выраженной в конкретных фактах и числах.
Качественный отчёт о результатах тестирования обладает многими свойствами качественных
требований, а также расширяет их набор следующими пунктами:
• информативность (в идеале, после прочтения отчёта не должно оставаться никаких
открытых вопросов о том, что происходит с проектом в контексте качества);
• точность и объективность (ни при каких условиях в отчёте не допускается искажение фактов,
а личные мнения должны быть подкреплены твёрдыми обоснованиями).