#Дефекты могут возникать на разных уровнях
Не соблюдаются стандарты по проектированию / сбору требований / кодированию, имеющие отношение к проекту

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

❗️Вывод: Требования должны быть доступны и понятны всем участникам процесса разработки ПО.

😬Дефекты проектирования:
👉Некорректное проектирование: нет точности
👉Упущения при проектировании: проектные методы проектирования не отражены в документации
👉Условно-оптимальное проектирование: проектные методы требуют корректировки для того, чтобы считаться полными
👉Нечеткое проектирование: проектные методы проектирования не ясны. Слова допускают двоякое толкование
❗️Вывод: Исправить такие дефекты непросто – необходимо заново перерабатывать проектирование продукта.

😬Дефекты в разработке:
👉Ошибка базы данных: ошибка в схеме / структуре базы данных
👉Ошибка данных: некорректная совокупность данных/обновления базы данных
👉Ошибка в вычислениях: неправильный расчет по формуле, неправильная бизнес валидация в коде
👉Логическая ошибка: неактуальная или неоднозначная функциональность в исходном коде
👉Ошибка навигации между объектами: навигация неверно разработана в исходном коде
👉Ошибка объявления переменных: неверное использование переменных, ошибка несоответствия типов в исходном коде
👉Ошибка в сообщениях: некорректные или отсутствующие сообщения об ошибках в исходном коде
👉Ошибка поиска
👉Неточные, пропущенные, несоответствующие комментарии в исходном коде
❗️Вывод: этом уровне дефекты достаточно легко обнаружить и исправить, поскольку видно несоответствие требованиям.

Другие дефекты:
🙈Системная ошибка: потеря доступа к памяти
🙈Ошибка интерфейса: некорректное расположение полей и объектов, неудобное положение окна или экрана, некорректная обработка переданных параметров
🙈Ошибка производительности: ошибка связанная с оптимальностью кода
🙈Ошибка тестового плана или сценария, или тестовых данных: неполная , неверная конфигурация тестов

Снизу нарисовала известную схему уровней более подробно можно найти в интернете.

Всем желаю хорошего настроения

#классификациядефекта

Моя любимая шпаргалка!
Составила на основе примера, который был показан на стажировке.

#тестыдлязакреплениязнаний ☝️

Задание для желающих: Попробуйте воспроизвести #дефект и составить #багрепорт. Основные атрибуты отчёта об ошибке описывала выше. Мой Контакт в Инстаграме ProTestingInfo.

Небольшая теория:

🔷 Классификация и приоритезация дефектов:
📌 позволяют повысить эффективность поиска и исправления дефектов
📌 позволяют сосредоточиться на тестировании функциональности важной для пользователей
📌 позволяют экономить трудозатраты на тестирование


🔷Факторы появления дефектов кода:
📌 неверная трактовка требований
📌 Ошибки программирования
📌 Неправильный перенос решений в код

🔹 Наблюдаемый дефект🔹 - неверное поведение программного продукта.


🔷 Критерии качественных требований:
📌 Однозначность
📌 Проверяемость
📌 Краткость (локоничность)
📌 Корректность


🔷 Особенности тестирования в условиях неполных и некорректных требований:
📌 Неадекватное поведение системы в ситуациях, не предусмотренных требованиям
📌 Невозможность идентификации дефекта
📌 Медленное тестирование


🔷 Типы дефектов при системном тестировании:
📌 Дефекты производительности, инсталляции
📌 Дефекты пользовательской документации
📌 Дефекты переносимости продукта на различные платформы
📌 Отсутствующая или некорректная функциональность


🔷 Варианты тестовых раундов:
📌 Обнаружение дефектов
📌 Smoke test
📌 Верификация исправления дефектов

#теория

Полезная информация :👏
#postman

https://proglib.io/p/api-dlya-qa-uchimsya-testirovaniyu-po-bez-dostupa-k-kodu-2020-12-10

Внимательно посмотрите схему, всегда продукт можно сделать или быстро, или дёшево, или качественно. Но есть границы:
🖍быстро и качественно это дорого.
🖍 качественно и дёшево это долго
🖍 дёшево и быстро это криво, с дефектами.
В таком виде представляется проект 😌
Утопия 😱🤯 лучше до такого не доводить #проект )).

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

❗️ИТ-проект – это краткосрочное усилие по созданию уникального продукта, сервиса или среды, например, замещение старых сервисов новыми, разработка коммерческого сайта, создание новых видов настольных компьютеров или слияние баз данных. Процессы управления ИТ-проектами в компании часто имеют сложный и многоступенчатый характер.
‼️🖍Все проекты ограничены тремя факторами: время, стоимость, объем. 👍Для того, чтобы проект был успешным, эти три ограничения должны быть в равновесии. Если эти ограничения находятся вне баланса, проект движется к катастрофе.🙈
«Быстро» и «медленно» – достаточно субъективные термины: то, что кажется медленным для вашей организации, может полностью удовлетворять по скорости другую. Важно установить разумные временные рамки для завершения ИТ-проекта на основании объема работы, ожидаемых результатов и условий проекта.

🖍🖍Все проекты, включая ИТ, проходят через 5 основных фаз жизненного цикла: инициация, планирование, выполнение, мониторинг и контроль, завершение. Каждая фаза содержит процессы, которые двигают проект от идеи до реализации.
🖍🖍Практически любой проект разработки включает в себя следующие работы:
требования; анализ; проектирование; кодирование; тестирование
‼️ИТ-Проект в узком понимании - это запланированные и задокументированные работы, связанные с оценкой, выбором, модернизацией, адаптацией, настройкой, внедрением, тестированием, описанием, интеграцией
информационных систем в определённой бизнес-области
Планирование и документирование - весьма важные составляющие ИТ-Проекта.
🖍🖍 Руководитель ИТ-проектов – сотрудник, целью которого является сопровождение конкретного проекта от планирования до реализации. Критерием успеха здесь является соответствие результата поставленным задачам.

‼️Суть проекта может заключаться в разработке новой информационной системы или во внедрении уже существующей системы в компании. В один период времени руководитель ИТ-проектов может заниматься одним крупным проектом или несколькими небольшими. В любом случае его труд является разносторонним, ему приходится все время переключаться с одной задачи на другую и одновременно удерживать перед глазами общую картину.
‼️Существует три основных подхода для управления ИТ-проектами.
🖍Первый основан на традиционном управлении проектами. Он работает на любом ИТ-проекте независимо от используемых технологий или продолжительности работы над проектом.
🖍Второй подход называется «экстремальным программированием». Иногда для него используют аббревиатуру XP (не спутайте с операционной системой Windows). Экстремальное программирование – это подход к управлению проектом, созданный специально для разработки программного обеспечения. XP использует модель разработки ПО, включающую пользователей, клиентов и программистов в 4 итеративные фазы: планирование, написание кода, разработка дизайна и тестирование.
🖍Scrum – метод, лидирующий в применении к ИТ-проектам. Этот подход, названный в честь термина регби, также использует итерации планирования, кодирования, выполнения и тестирования программного обеспечения. Scrum использует свой собственный язык и имеет свои правила относительно встреч, соответствия ключевым этапам и периодам планирования деятельности.
#проект

#Тестовыйсценарий — это описание начальных условий, входных данных, действий пользователя и ожидаемого результата

Test Case - тест-кейс - тестовый случай - Test Scenario - тестовый сценарий

🔷Чего не должно быть в тест-кейсе:
🔸Зависимостей от других тест-кейсов
🔸Нечеткой формулировки шагов или ожидаемого результата
🔸Отсутствия необходимой для прохождения тест-кейса информации
🔸Излишней детализации

🔷Рекомендации:
🖍Набор тестов не должен быть избыточным
🖍Проверяет интересующую часть
🖍Не затрагивает те части, которые не интересуют на данном этапе
🖍Не пересекается с другими тестами
🖍Не слишком сложен и не слишком прост
🖍Определяет соответствие спецификации

🔷Отделение тестовой процедуры от тестовых данных
🔹Процедура является
описанием последовательности шагов для выполнения теста, описанием правил навигации

🔹Тестовые данные -любые данные, заносимые пользователем в форму или в поле, переменная часть теста

😌Запомнить!
*⃣Каждый тест должен ссылаться на требование
*⃣Каждое требование должно быть проверяемым и должно иметь тест
*⃣Тестирование проводится планово!
*⃣Принцип Парето - Всё проверить нельзя!
*⃣Начинать с малого и наращивать взаимосвязь с другими тестами
*⃣Не забывать про нефункциональные требования

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

🔷Наиболее часто выделяемыми наборами являются:
🔹Набор тестовых сценариев для Smoke-test(дымовое тестирование
🔹План приёмо-сдаточных испытаний

🖍Набор тестовых сценариев для Smoke-test — это документ, включающий в себя набор определенных тестовых сценариев, покрывающих основную функциональность объекта или системы. Цель проведения Smoke-test — убедиться в том, что ключевые функции программы работают, не вникая в подробности.
🖍План приёмо-сдаточных испытаний (ПСИ) - документ, включающий в себя набор определенных тестовых сценариев, после положительного прохождения которого заказчик подписывает акт приемо-передачи (сдачи-приемки).