#кроссворд
📱по горизонтали:
1️⃣. один из видов тестирования, направленного на проверку соответствий функциональных требований ПО к его реальным характеристикам;
6️⃣. написанием тестов должны заниматься «специально обученный человек» это ...;
9️⃣. набор инструментов для ускоренной разработки сайта, нацелен на решение определенных задач;
1️⃣1️⃣. «фасадная» часть программы, это единственная часть, с которой взаимодействуют пользователи.

📱по вертикали:
2️⃣. помогает создавать надежные тесты автоматизированной проверки и улучшать общую логику тестирования на проектах;
3️⃣. набор инструкций, для автоматической проверки определенной части программного обеспечения;
4️⃣. инструмент для автоматизированного управления браузерами;
5️⃣. одно из преимуществ автоматизации: все написанные тесты всегда будут выполняться однообразно, то есть исключен «человеческий фактор»;
7️⃣. запуск всех необходимых тестов;
8️⃣. один из видов тестирования программного обеспечения, при котором тестируются отдельные модули или компоненты программного обеспечения;
🔟. доклад о результатах тестирования;
1️⃣2️⃣. программно-аппаратная часть сервиса, набор средств, с помощью которых происходит реализация логики веб-сайта.

#автоматизация

Рекомендую эти #книги ☺️👇

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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


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


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


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

#теория

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

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

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