Функциональная ошибка это

1. Напоминание!

Тестирование
= поиск дефектов!
Тестирование-
процесс
исследования ПО с целью
получения информации о качестве
продукта.

2. Что такое дефект (баг)?

Дефект
(он же баг) — это несоответствие
фактического результата выполнения
программы ожидаемому результату.

3. «First actual case of bug being found»

4. Как определить дефект перед нами или нет?

Программа
не делает, то что она должна
делать согласно ТЗ.
Программа
делает что-то, чего она не
должна делать согласно ТЗ.
Программа
делает что-то, о чём в
требованиях не упоминалось.
Программа
не делает чего-то, о чём не
говорится в требованиях , однако
подразумевается, что она должна это делать.
Программа
трудна для понимания и
неудобна в использовании.

5. Оформление отчёта об ошибке

Цель составления :отчета об ошибке является ее
исправление.
Каждое хорошее описание ошибки должно содержать
роено три вещи
1. Какие шаги привели к ошибке;
2. Что Вы ожидали, увидеть;
3. Что Вы на самом деле увидели.
.1 отчет в багтреккере на I баг
.1 отчет в багтреккере на один итот жебаг, который
воспроизводится браузерах/ОС.

6. Основные типы дефектов ПО

функциональные
ошибки

7. Функциональные ошибки. Примеры:

1.
Не сохраняются изменения данных в
профиле
2.
Не работает добавление комментария
3.
Не работает удаление товара из
корзины
4.
Не работает поиск

8. Основные типы дефектов ПО

функциональные ошибки
визуальные ошибки

9. Визуальные ошибки. Примеры:

1.
Текст вылезает за границы поля
2.
Элемент управления сайтом
наслаивается на нижестоящий элемент.
3.
Не отображается картинка

10. Основные типы дефектов ПО

функциональные
ошибки
визуальные ошибки
логические ошибки

11. Логические ошибки. Примеры:

1.
Можно поставить дату рождения в
будущем. 31 февраля, 31 июня и т.д.
2.
Можно сделать заказ не указав адрес
доставки
3.
Неверная работа логики поиска

12. Основные типы дефектов ПО

функциональные
ошибки
визуальные ошибки
логические ошибки
ошибки контента

13. Ошибки контента. Примеры:

1.
Конвертация валют идет по некорректному курсу.
2.
Орфографические или пунктуационные ошибки.
3.
Картинка товара не соответствует
карточке товара

14. Основные типы дефектов ПО

функциональные
ошибки
визуальные ошибки
логические ошибки
ошибки контента
ошибки удобства
использования

15. Ошибки удобства использования. Примеры:

1.
Отсутствие подсветки или текста
ошибки при некорректно заполненных
полях формы
2.
Сброс значений заполненных полей
при некорректной попытке регистрации
3.
Перегруженный интерфейс
(чрезмерное количество однотипных
точек входа)

16. Основные типы дефектов ПО

функциональные
ошибки
визуальные ошибки
логические ошибки
ошибки контента
ошибки удобства
использования
ошибки безопасности

17. Ошибки безопасности. Примеры:

1.
XSS-уязвимости
2. SQL-инъекции

18. Зачем документируют дефекты

Чтобы
Чтобы
не забыть
иметь возможность
исправлять конкретные проблемы
Чтобы собирать метрики

19. Ошибки безопасности. Примеры:

1.
XSS-уязвимости
2. SQL-инъекции

20. Простые правила оформления

Один дефект — один репорт
Говорящее название
Понятное описание

21. Оформление ошибок. Название

Локатор. Действие для проявления.
Проявление. Ожидаемый результат.
Где? Что делал? Что получилось? Что
ожидали?

22. Оформление ошибок. Описание

1. Предусловия воспроизведения
2. Последовательность действий для
воспроизведения
3. Фактический результат
4. Ожидаемый результат

23. Оформление ошибок. Доп. инфо

1. Окружение/условия воспроизведения
2. Скриншоты/видео
3. Логи/артефакты работы ПО
4. Атрибуты ошибки (важность, компонент)

24. Атрибуты бага: (Summary)

Принцип описания
сути(Summary) бага:
Что?
Где?
Когда?, (При каких условиях?)

25. Практика формулирования Summary бага.

Сформулируйте
баг на скриншоте
используя принцип: Что, где, когда?

26. Практика формулирования Summary бага.

Ответ:
Что:
Отсутствует выпадающее меню
Где:
в пункте Actionc
Когда:
при не выбранном документе.

27. Серьёзность и Приоритет багов.

СЕРЬЁЗНОСТЬ
ПРИОРИТЕТ
S1 Блокирующий (Blocker)
S2 Критический (Critical)
S3 Значительный (Major)
P1 Высокий (High)
S4 Незначительный (Minor)
P2 Средний (Medium)
S5 Тривиальный (Trivial)
P3 Низкий (Low)

28. Жизненный цикл дефекта.

29. Жизненный цикл дефекта.

30. Состояние дефектов

31. Жизненный цикл дефекта.

Варианты прохождения багов:
1. (новый)new
(отклоненный)rejected
(закрытый)closed
2. new
(отложенный)deferred
3. new
(принятый)Accepted
(открытый)open
(исправленный)fixed
(закрытый)closed
4. new
pen
accepted
(открыт снова)reopend
fixed
closed

32. Дефекты — основной продукт работы тестировщиков !!!

Министерство
науки и высшего образования РФ

Федеральное
государственное бюджетное образовательное

учреждение
высшего образования

«Уфимский
государственный авиационный технический
университет»

Факультет
информатики и робототехники

Кафедра
вычислительной математики и кибернетики

Отчет
по лабораторной работе №5

Поиск
и документирование дефектов

по
дисциплине

«Технология
разработки программного обеспечения»

Выполнили:

студент
группы МО-317

Шакиров
А. Р.

Проверил:

старший
преподаватель

Тугузбаев
Гаяз Ахтямович

Уфа
2020

Оглавление

Теоретические
сведения 3

1.
Описание дефектов 4

2.
Ответы на контрольные вопросы 6

Вывод 7

Приложение
А 8

Цель:

Протестировать мобильное приложение
и описать найденные дефекты.

Задачи:

1. Изучить
   теоретические сведения.

2. Выполнить
   практическое задание по лабораторной
   работе.

3. Оформить
   отчёт и ответить на контрольные вопросы.

Теоретические сведения

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

Описание каждого дефекта сохраняется
в специализированной – багтрэкинговой
– системе (например, JIRA, Bugzilla, Mantis, Redmine
и др.) или в предварительно созданном в
программной среде Microsoft Excel файле.

Описание дефекта включает следующие
обязательные поля:

1. Headline –
   название дефекта.

2. Severity –
   степень критичности (важность дефекта).

3. Description
   – алгоритм воспроизведения.

4. Result –
   фактический результат.

5. Expected
   result – ожидаемый результат.

6. Attachment –
   прикреплённые файлы (приложение).

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

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

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

1. Описание дефектов

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

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

При составлении тестовой документации
Acceptance Sheet мобильного приложения «Импорт
расписания УГАТУ» в процессе проведения
тестовых проверок были выявлены дефекты,
представленные на рисунке 1.1, их описания,
приведенные в таблице 1.1.

Рис.1.1.
Acceptance Sheet

Таблица 1.1

Описание дефектов

№	Название дефекта	Важность	Алгоритм воспроизведения	Фактический результат	Ожидаемый результат	Приложение
1	Главный экран: Строка поиска: Отсутствие интернациионализации заглушки строки поиска	Minor	Шаги по воспроизведению: 1. В настройках ОС выбрать язык отличный от русского. 2. Открыть приложение.	Заглушка строки поиска отображается на русском языке.	Заглушка строки поиска отображается на текущем языке системы или на английском языке.	Рисунок А.1
2	Главный экран: Кнопки под списком «Учебные группы»: Отсутствие интернациионализации заголовка кнопок «Импорт» и «Очистить календарь»	Minor	Шаги по воспроизведению: 1. В настройках ОС выбрать язык отличный от русского. 2. Открыть приложение.	Заголовок кнопки отображается на русском языке.	Заголовок кнопки отображается на текущем языке системы или на английском языке.	Рисунок А.1
3	Главный экран: Всплывающее уведомление: Отсутствие интернациионализации текста уведомления	Minor	Шаги по воспроизведению: 1. В настройках ОС выбрать язык отличный от русского. 2. Открыть приложение. 3. Нажать кнопку «Импорт». 4. Дождаться завершения операции.	Текст уведомления отображается на русском языке.	Текст уведомления отображается на текущем языке системы или на английском языке.	Рисунок А.2

1. Ответы на контрольные вопросы

   1. Шакиров Айдар

Ответ на вопрос №5 «Что такое Severity в
описании дефекта?»:

Severity (степень критичности). Степень
критичности (серьезности, важности)
показывает степень ущерба, который
наносится проекту существованием
дефекта. В общем случае выделяют следующие
градации критичности дефектов, указанные
в таблице 2.1.1.

Таблица
2.1.1

Степени критичности дефектов

№	Severity	Описание	Примеры
1	Critical (критический)	Функциональная ошибка, которая блокирует работу части функционала или всего приложения. Функциональная ошибка, которая нарушает ключевую (с точки зрения конечного пользователя или бизнеса заказчика) функциональность приложения	Заблокирована вкладка (категория меню). Неправильно подсчитывается итоговая сумма при вводе скидочного промокода. Раскрывается конфиденциальная информация.
2	Major (значительный)	Функциональная ошибка, которая нарушает нормальную работу приложения, но не блокирует работу части функционала в целом.	Невозможно загрузить видеофайлы на персональной страничке. Необходимо перезапускать приложение при выполнении типичных сценариев работы.
3	Average (средней значимости)	Не очень важная функциональная ошибка. Критичные дефекты GUI.	Не работает сортировка. «Уехал» текст за пределы окна.
4	Minor (незначительный)	Редко встречающиеся незначительные функциональные дефекты. 90 % дефектов GUI.	Введены необязательные для заполнения поля, которых нет в спецификации. Грамматические, пунктуационные ошибки.
5	Enhancement (предложение по улучшению)	Функциональные предложения, советы по улучшению дизайна (оформления), навигации и др. Такой дефект является необязательным для исправления.	Добавить кнопку «Наверх» на длинных формах. Увеличить размер шрифта.

Вывод

В
ходе лабораторной работы протестировал
мобильное приложение и описал найденные
дефекты.

Приложение А

Рисунок А.1. Отсутствие интернационализации
элементов GUI

Рисунок А.2. Отсутствие интернационализации
текста всплывающего уведомления о
результате операции

Как научиться искать баги — Серьезность и приоритет — Алгоритм действий — Лучшие практики — Шпаргалка

Типы багов:

• Функциональные
• Синтаксические
• Логические
• Производительности
• Ошибки вычислений
• Безопасности
• Уровня модуля
• Интеграционные баги
• Юзабилити-баги
• Потока управления
• Совместимости

Функциональные

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

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

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

Поиском багов этого типа занимается функциональное тестирование — отдельная важная сфера в QA (мини-гайд по ссылке).

Синтаксические баги

Ошибка в коде программы. Вероятно, самая частая ошибка, статистически. Случается обычно по невнимательности. Заключается, например, в неправильном/пропущенном символе, неправильно прописанной команде, или пропущенной скобке. 

Логические ошибки

Коварная ошибка, труднее выявляемая. Приложение выдает неправильный вывод, или вообще падает. 

Логические дефекты это например бесконечные циклы или некорректные переходы, допущенные разработчиком по неопытности или незнанию синтаксиса, вызывающие сложно определяемые ошибки в user flow (“маршруте пользователя по приложению” в процессе пользования им).

Бесконечные циклы — больное место тестировщика, так же как утечки памяти, проблемы с типами данных во многих языках, с компилятором в С++ или сборщиком мусора в Java. Несоблюдение хороших практик в программировании и недостаток опыта у разработчиков добавляют задач QA-отделу.

Еще примеры: переменной присвоено некорректное значение; деление чисел вместо умножения, и т.п.

Подробнее о логических ошибках.

Проблемы производительности

Такие ошибки влияют на скорость, на стабильность, на время отклика, или на потребление ресурсов, из-за чего их находят довольно быстро. Чаще их находят сами разработчики, а не тестировщики. Очень распространенный тип багов.

Ошибки вычислений

Когда приложение выдает некорректное значение пользователю или другой программе.

• Когда в приложении применен некорректный, неподходящий алгоритм
• Несоответствие типа данных

Уязвимости в безопасности

Дефекты в системе безопасности, видимо, наиболее опасные из тех, с которыми сталкивается junior QA. Они “компроментируют” весь проект, всю компанию, и разумеется, QA-команду, если она их пропустила. 

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

Самыми частыми, статистически, ошибками безопасности являются: ошибки шифрования; подверженность SQL-инъекциям; XSS-уязвимости; переполнения буфера; логические ошибки в подсистеме безопасности; некорректная аутентификация.

Баги уровня модуля

На уровне отдельного модуля. Принято, чтобы разработчики сами делали юнит-тестирование модулей (им это сделать проще, т.к. они лучше понимают свой код), но в принципе к этому могут привлекать и QA.

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

Интеграционные баги

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

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

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

Юзабилити-баги

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

Баги потока управления (Control Flow)

Ошибки Control Flow (потока управления, путей выполнения программы) мешают ей корректно переходить к выполнению следующих задач, то есть корректно “передавать управление”, что стопорит весь workflow компании. Обычно это “мертвый код” (отсутствует вход), или “бесконечный цикл” (отсутствует выход). 

Пример: в опроснике пользователь нажимает “Сохранить”, предполагается переход к концу опросника/теста, а перехода к следующей странице не происходит. 

Проблемы совместимости (Compatibility issues)

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

Итак, уже примерно знаем, ЧТО искать, постараемся понять, КАК искать.

Как научиться искать баги

“Быстрая проверка” на реальных устройствах и в браузерах

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

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

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

Даже если таким образом будет найдено сравнительно мало багов, логично предположить, что все-таки есть проблемы в основной части функциональности. Отсутствие багов при “экспресс-анализе” (“quick attack”) обычно показывает, что основная часть функциональности более-менее в порядке.

Такая “быстрая атака” должна выполняться в стандартном пользовательском окружении — как можно более близком к тем условиям, в которых будет работать конечный пользователь. 

Внимание тестовому окружению

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

Из-за проблем с плохо подготовленным тестовым окружением возникают задержки в получении результатов тестирования. Проявляются баги, вызванные именно тестовым окружением, а не самим софтом. Мало что так раздражает, как некорректно работающее окружение.

Например, тестировщик нашел и отрепортил баг, а когда разработчик проверил его, в коде проблем не нашел, потому что проблема была с окружением. От этого возникает задержка.

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

Тщательное исследование

Перед началом тестирования нужно внимательно изучить приложение или тестируемый модуль.

Подготовить достаточно тестовых данных. Этот датасет должен включать и базы данных, если тестируется приложение, использующее базы данных (а это почти все приложения сейчас).

Полезно вставлять в код своих автотестов указатели (если язык это поддерживает), для облегчения поиска нужных блоков. А также точки останова (брейкпойнты, контрольные точки), останавливающие выполнение в какой-то точке, чтобы точнее определить “место бага”.

Принцип Парето

Согласно этому принципу, 20% усилий дают 80% результата. 

А 80% усилий дают лишь 20% результата. 

Применительно к QA-индустрии, принцип Парето гласит, что 80% багов сосредоточены в 20% модулей. (Необязательно такое точное соотношение, но в целом). По принципу Парето, большинство багов затаились в одном-двух модулях (или даже еще меньшей части кода).

Если всерьез взяться за эти модули и вычистить из них баги, можно считать работу на 80% сделанной.

Подробно о принципе Парето в тестировании.

Четкие цели

Тестировщик должен учитывать стандарты и лучшие практики и придерживаться их, это даст понимание, какие ошибки искать тщательнее и в первую очередь. Должен понимать логику действий конечного пользователя. Что пользователь ожидает от этого софта? Какой его user experience? Какой функциональности ожидает? На какие баги вообще не обратит внимания, а какие заставят отказаться от приложения?

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

Серьезность и приоритет

По серьезности (Severity)

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

• Критический баг. “Критикал”. Некорректно работает все приложение, или его важнейший модуль. Тестирование остальных, менее существенных багов прекращается, все силы бросают на фикс такого бага. Сюда входит, например, кейс, когда приложение выдает ошибку сервера при попытке входа в приложение.

• Существенный. “Мажор”. Влияет на ключевую функцию, и приложение ведет себя с отклонением от прописанных требований. Например, email-провайдер не дает добавить больше одного адреса в поле получателя.

• Средней серьезности. “Минор”. Когда не очень важная функция не ведет себя соответственно требованиям. Например, ссылка в “Условиях использования” продукта ведет в никуда.

(Перечисленные выше баги коротко обозначаются S1, S2, S3, S4 по серьезности.)

• Низкой серьезности. “Тривиал”. Обычно это небольшие дефекты пользовательского интерфейса. Например, кнопки, которые должны быть одинаковыми, немножко отличаются по цвету и размеру.

По приоритету

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

Приоритеты выставляются менеджером проекта:

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

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

Низкий приоритет. Их можно не фиксить, и критериям завершения это не противоречит, но такие дефекты надо устранить до финального релиза. Обычно это опечатки, небольшие дефекты в дизайне (например выравнивание текста), не очень заметные ошибки в размере элементов, и прочие “косметические” дефекты.

(Перечисленные выше баги обозначаются P1, P2, P3 от высокого к низкому.)

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

Подробнее о серьезности и приоритете, а также о глобальном приоритете и частоте багов.

Стандартный порядок действий при обнаружении бага

1. Проверить дополнительные (связанные) вещи

Обычно баги “по одному не ходят”, то есть где-то поблизости есть аналогичные, или связанные с уже найденными. 

1. Зафиксировать текущее состояние приложения

Состояние приложения и состояние окружения. Это поможет примерно определить причину бага — внутренняя или внешняя, и воспроизвести баг.

1. Проверить, может баг уже есть в репортах

Чтобы не делать уже сделанную кем-то работу.

1. Репорт

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

Статусы багов (в жизненном цикле)

• Открыт (добавлен в репорт)
• В работе (принят к исправлению)
• Исправлен (и передан на перепроверку)
• Закрыт (уже не воспроизводится)

также дополнительно:

• Отклонен (ошибка в репорте)
• Отсрочен (как неприоритетный)
• Переоткрыт (после двух предыдущих статусов)

Подробнее о системах контроля багов — здесь

Лучшие практики

• Сначала хорошо исследовать и понять приложение (модуль)
• Создать специальные тест-кейсы, а именно функциональные тест-кейсы, посвященные критически важным функциям
• Подготовить достаточно тестовых данных
• Запустить тесты снова, в другом тестовом окружении
• Сравнивать полученные результаты с ожидаемыми
• Проанализировать тестовый сет, используя старые тестовые данные
• Выполнить стандартные тест-кейсы, которые ранее показывали себя надежными. Например, если тестировалось поле ввода для стандартного текста, ввести HTML-теги и проверить, что получится
• После завершения большей части тестов, если есть усталость, отдохнуть, занявшись обезьяньим тестированием (monkey testing)

Тестирование на реальных девайсах и в реальных окружениях

Тестирование в реальных окружениях является хорошей практикой в QA, а в тестировании мобильных приложений — обязательной практикой. Реальное окружение быстрее “апгрейдит” тестировщика. Но оно требует закупки/аренды довольно-таки внушительного парка устройств. Вообще, тестирование всех возможных комбинаций браузер/ОС/девайс — отдельная головная боль. Здесь помогают облачные платформы.

***

Шпаргалка QA Trainee/Junior

Что делает тестировщик, когда находит баг

• Проверяет связанные или аналогичные вещи
• Фиксирует текущее состояние приложения и тестового окружения
• Проверяет, нет ли этого бага в репорте
• Пишет репорт

***

Пять технических и пять нетехнических навыков хорошего QA

 Регрессионное тестирование: подборка инструментов

Эмуляторы и симуляторы: в чем разница

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

---

ОСНОВНЫЕ ТЕРМИНЫ

Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:

1. планированием работ (Test Management)

2. проектированием тестов (Test Design) — этап, на котором создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями. Т.е., определяется, КАК будет тестироваться продукт.

3. выполнением тестирования (Test Execution)

4. анализом результатов (Test Analysis)

Основные цели тестирования

• техническая: предоставление актуальной информации о состоянии продукта на данный момент.

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

Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.

Следует уметь различать, что:

• Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).

• Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.

• Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).

Жизненный цикл бага

Атрибуты дефекта

• Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.

Градация Серьезности дефекта

• Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.

НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА

1. Эквивалентное Разделение (Equivalence Partitioning) — это техника, при которой функционал (часто диапазон возможных вводимых значений) разделяется на группы эквивалентных по своему влиянию на систему значений. ПРИМЕР: есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.

2. Анализ Граничных Значений (Boundary Value Analysis) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных. Если брать выше ПРИМЕР: в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.

3. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.

4. Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.

5. Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).

6. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

7. Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.

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

9. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.

10. Таблица принятия решений (decision table) — инструмент для упорядочения бизнес-требований, которые должны быть реализованы в продукте. Применяется для систем со сложной логикой. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.

ВИДЫ ТЕСТИРОВАНИЯ

Классификация по целям

• Функциональное тестирование (functional testing) рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом, т.е. проверяется корректность работы функциональности приложения.

Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.

Классификация по позитивности сценария

• Позитивное — тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.

• Негативное — тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций; при таком тестировании часто выполняются некорректные операции.

Классификация по знанию системы

• Тестирование белого ящика (White Box) — метод тестирования ПО, который предполагает полный доступ к коду проекта, т.е. внутренняя структура/устройство/реализация системы известны тестировщику.

• Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).

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

Классификация по исполнителям тестирования

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

• Бета-тестирование — практически готовое ПО, выпускаемое для ограниченного количества пользователей, разрабатывается в первую очередь для тестирования конечными пользователями и получения отзывов клиентов о продукте для внесения соответствующих изменений.

Классификация по уровню тестирования

• Модульное (компонентное) тестирование (Unit Testing) проводится самими разработчиками, т.к. предполагает полный доступ к коду, для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде, проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).

• Интеграционное тестирование (Integration Testing) направлено на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое, т.е. проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.

Подходы к интеграционному тестированию

• Системное тестирование (System Testing) — это проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д., и оцениваются характеристики качества системы — ее устойчивость, надежность, безопасность и производительность.

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

Классификация по исполнению кода

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

• Динамическое тестирование проводится на работающей системе, т.е. с осуществлением запуска программного кода приложения.

Классификация по хронологии выполнения

• Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок, т.е. проверяется исправление багов.

• Регрессионное тестирование (regression testing) — это тестирование после внесения изменений в код приложения (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям, т.е. проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвали новых багов.

• Приёмочное тестирование проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

ДОКУМЕНТАЦИЯ

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

Основные атрибуты требований:

• Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.

• Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.

• Недвусмысленность — требование должно содержать однозначные формулировки.

• Проверяемость (тестопригодность) — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.

• Приоритетность — у каждого требования должен быть приоритет (количественная оценка степени значимости требования).

Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:

• Что нужно тестировать?

• Как будет проводиться тестирование?

• Когда будет проводиться тестирование?

• Критерии начала тестирования.

• Критерии окончания тестирования.

Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.

Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для покрытия продукта тестами.

Чек-лист (check list) — это документ, описывающий что должно быть протестировано. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. ЧЛ менее формализован, чем тестовый сценарий.

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

Атрибуты тест кейса:

• Предусловия (PreConditions) используются, если предварительно систему нужно приводить к состоянию пригодному для проведения проверки; т.е. указываются либо действия, с помощью которых система оказывается в нужном состоянии, либо список условий, выполнение которых говорит о том, что система находится в нужном состоянии для основного теста.

• Шаги (Steps) — cписок действий, переводящих систему из одного состояния в другое, для получения результата.

• Ожидаемый результат (Expected result), на основании которого можно делать вывод о удовлетворении поставленным требованиям.

• иногда используются Постусловия (PostConditions), как некоторое напоминание для перевода системы в первоначальное состояние, как до проведения теста (initial state)

Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего для Test script), так и независимыми (Test suite).

Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.

---

Огромное спасибо @alexlobach и @Gennadii_M за статьи! Большая часть информации взята именно оттуда.

UPD: статья пополняется. Спасибо @yakoeka

Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется

Автор: Екатерина Курач

Классификация ODC (Orthogonal Defect Classification — ортогональная классификация дефектов) — это метод, разработанный корпорацией IBM с целью сбора информации о типах неисправностей, которые имеют место в разрабатываемых программных системах. Этот метод полезен при сборе и анализе тестовой информации с тем, чтобы направить усилия совершенствования процесса разработки в нужном направлении. Можно воспользоваться стандартной классификацией, разработанной авторами ODC, в качестве основы для отбора тестовых случаев.

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

Но, как известно, полностью протестировать программу невозможно по следующим причинам:

1. Количество всех возможных комбинаций входных данных слишком велико, чтоб его можно было проверить полностью.
2. Количество всех возможных последовательностей выполнения кода программы также слишком велико, чтобы его можно было протестировать полностью.
3. Пользовательский интерфейс программы (включающий все возможные комбинации действий пользователя и его перемещений по программе) обычно слишком сложен для полного тестирования.

Т.е. написать тест кейсы для «полного» тестирования продукта — просто невозможно. Мы можем разработать миллионы тестов, но будет ли время у нас их выполнить? Вероятнее всего — нет. Поэтому приходится тщательно выбирать тест кейсы, которые мы будем проводить.

Характеристики хорошего теста:

• Существует обоснованная вероятность выявления тестом ошибки
• Набор тестов не должен быть избыточным
• Тест должен быть наилучшим в своей категории
• Он не должен быть слишком простым или слишком сложным

В настоящее время наблюдается несколько методологий разработки тест кейсов. Они отличаются и теоретическим подходом, и практической реализацией.

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

Методология построения тестовых случаев на основе Ортогональной классификации дефектов

Второй широко используемый подход к разработке тест кейсов [первый рассматривался в статье «Методология разработки тестовых случаев на основе сценариев использования»] предлагает задуматься над тем, какие типы дефектов может содержать в себе программный продукт, и написать тестовые случаи, способные их обнаружить. То есть он требует определиться с тем, как система будет использована, и построить тестовые случаи, которые проведут испытание системы на всех этапах использования. Этот подход называется метод целенаправленной проверки и построен на основе классификации ODC.

Классификация ODC (Orthogonal Defect Classification — ортогональная классификация дефектов) — это метод, разработанный корпорацией IBM с целью сбора информации о типах неисправностей, которые имеют место в разрабатываемых программных системах. Этот метод полезен при сборе и анализе тестовой информации с тем, чтобы направить усилия совершенствования процесса разработки в нужном направлении. Можно воспользоваться стандартной классификацией, разработанной авторами ODC, в качестве основы для отбора тестовых случаев.

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

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

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

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

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

Ошибки синхронизации/сериализации — это те ошибки, которые устраняются путем улучшенного управления распределенными ресурсами и ресурсами в реальном времени.

Ошибки билда/пакета/соединения описывают ошибки, которые случаются из-за ошибок в библиотеках, управлении изменениями или контроле версий.

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

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

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

Список дефектов и соотношение этих дефектов с любой стадией разработки

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

Матрица: виды дефектов/стадии процесса верификации

Например, тип дефекта — функциональный — связан с дизайном и можно ожидать, что ошибки такого типа могут быть найдены при изучении high-level дизайна и при проведении функционального тестирования. Аналогично заполняется данная таблица для дефектов других типов. На основе данной таблицы разрабатываются группы тест кейсов. Необходимо заметить, что сейчас разработаны математические алгоритмы для автоматической генерации данных таблиц связей.

Другим основным понятием классификации ODC является понятие «триггеров отказов». Грубо говоря, триггер отказа — это условие, при котором ошибка проявляется. Например, когда продукт собран, предполагается, что все его функции протестированы. Однако, оказывается, что новые ошибки возникают при использовании продукта на другом тестовом окружении, при использовании других аппаратных средств. Таким образом, хоть тип дефекта и тот же самый, необходимо задействовать различные типа триггеров отказов для того, чтоб он проявился. При проявлении ошибки, триггер может быть определен инженером или кем-то, кто разбирается в проблемном диагнозе.

Вот список шести категорий причин отказов, распознаваемых методом ODC:

1. Рабочий объем/Повышенная нагрузка
2. Нормальный режим
3. Восстановление/Исключение
4. Пуск/Повторный пуск
5. Конфигурация аппаратных средств
6. Конфигурация программных средств.

Метод целенаправленной проверки использует несколько таких триггеров в качестве ориентиров для выбора тестовых случаев. Нам необходимо быть уверенными в том, что нам удалось построить тестовые случаи, которые позволяют задействовать каждый из этих триггеров дефектов. Некоторые из категорий, такие как Пуск или Нормальный режим, вряд ли удастся избежать. В то же время категория Исключение напоминает нам, что каждая исключительная ситуация на системном уровне должна быть покрыта тестовыми случаями. Слово Восстановление в названии этой категории также напоминает, что ожидаемые ситуации захвата исключительной ситуации должны быть четко описаны. Однако не всегда возможно продолжать выполнение операций в результате возникновения некоторых исключительных ситуаций, например таких как «File not found». Каждая хорошо спроектированная программа должна быть способной справиться с такой ситуацией.

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

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

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

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

При использовании обеих этих методологий довольно важным вопросом является вопрос измерения тестового покрытия.

Покрытие — это мера, показывающая степень доверия, которое мы испытываем по отношению к проводимому тестированию.

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

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

Литература:

1. Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. — Киев: Издательство «Диа Софт», 2001.—544 с.
2. Макгрейгор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения. Практическое пособие. — Киев: ООО «ТИД «ДС»», 2002.—432 с.
3. Официальный сайт Chillarege Inc: http://www.chillarege.com/index.html

функциональная ошибка