Согласно книги Святослава Куликова стр. 195 - Тестирование программного обеспечения:

Логика создания эффективных отчётов о дефектах такова:

При создании отчёта о дефекте рекомендуется следовать следующему алгоритму:

0⃣. Обнаружить дефект ☺.
1⃣. Понять суть проблемы.
2⃣. Воспроизвести дефект.
3⃣. Проверить наличие описания найденного вами дефекта в системе управления дефектами.
4⃣. Сформулировать суть проблемы в виде «что сделали, что получили, что ожидали получить».
5⃣. Заполнить поля отчёта, начиная с подробного описания.
6⃣. После заполнения всех полей внимательно перечитать отчёт, исправив неточности и добавив подробности.
7⃣. Ещё раз перечитать отчёт, т.к. в пункте 6⃣ вы точно что-то упустили.

О каждом пункте подробно почитать в данной книге.

#теория

*⃣Планирую сегодня провести тестирование в Инстаграме.

*⃣Сделать расшифровку понятий об отчёте тестирования и отредактировать / создать другой похожий пример отчёта о тестировании (на неделе)

*⃣ Готовлю теоретический пост о тест-плане, и также сделать краткий пример тест-плана.

⏸в разработке примеры тестовых данных, посты о методологиях разработки ПО, техниках тест-дизайна.
В целом информации очень много для повторения и закрепления знаний.🎲
🧨
Практикуем создавать тестовые сценарии и чек-листы ( в закрепленном сообщении есть шаблоны).
🛎Проводила марафоны - назвать заголовок баг-репорта, пишите ваши версии в директ или в комментариях соответствующих постов.
🕰Стараюсь находить время и возможность, чтобы развивать свои знания и помогать вам.🖥🧸

Пример взят из
https://istqb-training.ru/Training

Git и Github Курс для Начинающих

В ролике информация про то, как установить Git и начать работать с Github. Так же разберем основные команды: clone, init, merge, branch, checkout, push, pull, commit, add, config

https://www.youtube.com/watch?v=zZBiln_2FhM

Git и Github Шпаргалка

Статья так же доступна тут:
vk.com/@vladilen.minin-git-and-github

JSON (JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Легко читается человеком и машиной. Часто используется в REST API (чаще, чем XML)
Корректные значения JSON:
JSON-объект — неупорядоченное множество пар «ключ:значение», заключённое в фигурные скобки «{ }».
Массив — упорядоченный набор значений, разделенных запятыми. Находится внутри квадратных скобок [].
Число (целое или вещественное).
Литералы true (логическое значение «истина»), false (логическое значение «ложь») и null.
Строка

Комментариев в JSON, увы, нет.

Правила well formed JSON:

Данные в объекте написаны в виде пар «ключ:значение»

Данные в объекте или массиве разделены запятыми

Объект находится внутри фигурных скобок {}

Массив — внутри квадратных []

Ключ описывается строкой, между ним и значением стоит символ «:». Пары ключ-значение отделяются друг от друга запятыми.

Значения ключа могут быть любыми:
число
строка
массив
другой объект
И только строку мы берем в кавычки!

#теория
#полезнаяинформация

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

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

🔹Тестовая конфигурация
🔹Документация
🔹Метрики
🔹Согласования
🔹Типы тестирования по виду подсистемы или продукта
🔹Типы тестирования по способу выбора входных значений
❓
🖍Что необходимо тестировать? (Объект тестирования)
🖍Что будет тестироваться? (Список функций, система в целом и ее компоненты в отдельности)
🖍Как будет проходить тестирование? (Тестовая стратегия: виды тестирования)
🖍Когда будет проходить тестирование? (Подготовка, планирование, тестирование, результаты и их анализ)
🖍Каковы начальные критерии тестирования? (Готовность тестового окружения, наличие необходимой документации, завершение цикла разработки)
🖍Каковы критерии окончания и результаты тестирования? (Результаты цикла тестирования удовлетворяют требованиям и критериям качества продукта, отчётность по открытым и закрытым дефектам)

О структуре тест плана будет отдельный пост.

Планирую также составить шаблон, как для отчёта о тестировании.

Категория дефекта.
Предлагается для классификации использовать следующие 8 категорий («симптомов») дефектов:
1) Крах Системы – падение операционной системы (синий экран), падение серверов, зависание системы или иная проблема, приводящая к необходимости перезагрузки операционной системы клиентской машины или сервера.
2) Крах Приложения – некорректное завершение работы приложения, зависание приложения или иная проблема, приводящая к необходимости перезагрузки приложения, а также когда при работе с отдельным компонентом приложения нарушается его работоспособность в целом.
3) Сбой Безопасности – система позволяет неавторизированный вход или предоставляет не полагающиеся пользователю права, неверное разрешение конфликтов при многопользовательском доступе к объекту приложения.
4) Искажение Данных – потеря данных или их искажение
5) Дефект Функциональности – неработоспособность функции объекта тестирования, функция работает не так, как ожидается или не так, как была спроектирована, функция не соответствует стандартам и соглашениям; экранный объект ведёт себя не так, как следует из его внешнего вида.
6) Дефекты Производительности – дефекты, вызванные перегруженностью сервера, превышением времени ожидания отклика (выход по таймауту); нерациональное использование времени пользователя, приложение работает медленнее, чем ожидалось.
7) Избыточные Шаги – для достижения требуемой функциональности пользователь должен использовать обходные пути или выполнять неочевидные действия.
8) Дефекты Интерфейса (взаимодействия с пользователем) – грамматические ошибки в интерфейсе, наличие избыточных сообщений, неясные и сбивающие с толку предупреждения, отсутствие средств навигации на странице (в WEB-приложениях), неудовлетворительный пользовательский интерфейс (непродуманная структура, разнородность страниц, отсутствие необходимой вспомогательной информации на странице ввода).

#дефект #теория

#пример
Категории и серьезность дефекта

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