#Проект проходит через шесть основных фаз:
✅Планирование
✅Анализ системы
✅Дизайн
✅Разработка и внедрение
✅Тестирование
✅Поддержка системы

Модели разработки подразделяются на классические и гибкие.

Список классических моделей:

👏🏼Code and Fix (написание кода, проверка и устранение ошибок),

👏🏼Waterfall (проект последовательно проходит все стадии),

👏🏼V-Model (проведение тестирования одновременно с разработкой),

👏🏼Инкрементная модель (проект делится на составные компоненты, команда по очереди готовит каждый из них, затем происходит финальная сборка),

👏🏼Спиральная модель (предусматривает тщательную проработку рисков),

👏🏼Итеративная модель (сначала делается базовая модель продукта, затем следуют итерации по ее усовершенствованию),

👏🏼RAD-Model - Rapid Application Development (скоростная разработка продукта).

Гибкая методология разработки - Agile
Методологии разработки — это применение той или иной модели на практике. Так, Agile-модель имеет целый ряд довольно популярных методологий — от мягкого Kanban, когда команда работает с доской с задачами, до жестких Scrum и XP (Extreme Programming – Экстремальное программирование), а также Lean Software Development, или бережливая разработка программного обеспечения — гибкая методология, основанная на концепции бережливого производства.

Более подробно ознакомиться с информацией о каждой методологии можно по ссылке, которую я увидела на канале @qa_heroes
👇🏻👇🏻👇🏻👇🏻👇🏻

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

🔶 В процессе разработки программного обеспечения метрики используются:

🔹Для контроля над процессом разработки в целом, а в тестировании в частности
🔸Для оценки прогресса выполнения работ по тестированию ПО
🔹Для последующего планирования процессов.

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

🔷Метрики могут быть представлены:

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

#расшифровкапонятий

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

📚📙📖
АНГЛО-РУССКИЙ СЛОВАРЬ IT–ТЕРМИНОВ

Словарь программиста. Здесь собрано 220+ терминов

#расшифровкапонятий

#рекомендации для прочтения и изучения

Техники тест-дизайна:

📌Классы эквивалентности и граничные значения

📌Таблицы решений и их применение в тестировании

📌Методология разработки тестовых случаев на основе сценариев использования

📌Техника попарного тестирования

📌Предугадывание ошибок

📌Таблица состояний и переходов - часть 1 и Таблица состояний и переходов -часть 2

📌Эквивалентное разбиение, Граничные значения, Таблица принятия решений, Причина и следствие, Попарное тестирование, Предугадывание ошибок

📌Расшифровка понятий по техникам тест-дизайна

📌Обзор техник тест-дизайна: все вышеупомянутые техники, а также Тестирование и покрытие операторов, Тестирование и покрытие условий, Исследовательское тестирование, Тестирование на основе чек-листов

Дополнительная информация:
Чит-лист – список повторяющихся проверок.

Примеры проверок для тестирования формы регистрации.

Извиняюсь за небольшое отсутствие, включаюсь в процесс изучения и повторения😄😄😄

#выжимкаинформации из одной презентации про #дефекты

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

🖍Причина 1 – Нехватка времени.
В любом проекте приходится иметь дело с огромным количеством программных свойств. Людей, которые эти свойства могли бы записать в код и протестировать, как правило не хватает, не говоря уже о времени для завершения работ.

🖍Причина 2 – Дефект вовсе не дефект.
Может, вам доводилось слышать фразу: «Это не дефект, а такое свойство!» или «Это не дефект, а фича!» или «Это не баг, а фича!». Это часто приводит к непониманиям, ошибкам в тестах или изменениям в спецификации, поскольку потенциальные дефекты рассматриваются как свойства системы.

🖍Причина 3 – Устранять неисправность слишком рискованно.
К сожалению, это случается очень часто. ПО – хрупкая и взаимосвязанная система. Устранение одной неисправности может привести к появлению других. Менять что-либо в программе незадолго до выпуска релиза может быть очень рискованной затеей. Лучше оставить в программе известный дефект, чтобы избежать риска появления новых, неизвестных.

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

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

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

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

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

🧰анализируем требования и выделяем для себя следующие нюансы:
⚙️какие из полей обязательные для заполнения?
⚙️имеют ли поля ограничения по длине или по размерности (границы)?
⚙️какие из полей имеют специальные форматы?

🧰Бывает:
💻Тестирование форм без спецификации
💻Проверка полей на основе технической документации
💻Тестирование текстовых полей + автоматизация

🧰Определяют:
📌Текстовое поле ввода для буквенных данных
📌Текстовое поле ввода для числовых данных
📌Поле ввода для дробных чисел
📌Текстовое поле для ввода процентов (%)
📌Поля ввода для даты
📌Поле ввода для времени
📌Текстовые поля ввода определенного формата (например, адрес электронной почты)
📌Ниспадающие списки с заранее определенным набором данных
📌Таблицы (списки)
📌Переключатели (Флажки, Радиокнопки)
📌Диалоговые окна с кнопками Да, Нет, Отмена

🧰Тестовые сценарии для проверки функциональности систем
🎈Вход в систему
🎈Фильтр и поиск
🎈Генерация отчетов
🎈Создание, редактирование и удаление сущности
🎈Сортировка списков
🎈Экспорт, печать, открытие файлов

🧰Чит-лист для проверки поля:
🏮Пустое поле
🏮Корректное значение
🏮Граничные значения
🏮Отрицательные числа
🏮Ноль
🏮Числа со знаком +
🏮Спецсимволы
🏮Дробные числа с разделителем "точка"
🏮Дробные числа с разделителем "запятая"
🏮Условие: должны приниматься или не приниматься буквы
🏮Условие: должны приниматься или не приниматься спецсимволы
🏮Условие: должны приниматься или не приниматься числа
🏮Научная запись, в виде экспоненты, логарифма, тригонометрических функций, суммы...
🏮Шестнадцатеричная система счисления

🧰последовательный подход к разработке тестовых случаев (тест кейсов), используя самые простейшие техники тест дизайна:
Эквивалентное Разделение (Equivalence Partitioning)
Анализ Граничных Значений (Boundary Value Analysis)
Предугадывание ошибки (Error Guessing)
Причина / Следствие (Cause/Effect)

Необходимая информация для прочтения:

Тестирование текстового поля

Самые простые и эффективные способы тестирования поля ввода текста

Тестирование полей ввода (Чит-листы)

Практическое применение техник тест дизайна при разработке тест кейсов

‼️Завтра проведу тестирование на закрепление знаний!

Из данных ссылок можно ознакомиться с различными проверками такими как:

🔷Нажать на кнопку «Готово», без предварительного заполнения формы.

🔷Несколько раз нажать на клавишу пробела внутри формы, а затем кликнуть на кнопку подтверждения.

🔷Проанализировать, сколько можно ввести символов в форму, с последующим нажатием кнопки «Готово».

🔷Ввести минус, затем ввести максимальное количество цифр и нажать на клавишу подтверждения.

🔹Ввести все доступные специальные символы и нажать на кнопку отправки формы. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.

🔷Попробуйте ввести символы, которые технически не относятся к ASCII, разные эмоджи и нажмите на Submit. Если вы увидите сообщение с ошибкой, попробуйте проанализировать ее содержание.

🔷Испытайте возможность выполнения межсайтового скриптинга. Для этого нужно ввести такой сценарий: <noscript>alert(«I hacked this!»)</noscript>. Если после нажатия на кнопку отправки формы отобразится всплывающий поп-ап, значит данное текстовое поле максимально уязвимо для XSS-атаки.

🔷Проверьте возможность ввода SQL-инъекции. Введите FOO’); DROP TABLE USERS. Но ни в коем случае не совершайте подобные манипуляции с базами данных сайтов, которые уже запущенны онлайн.

Найдите возможность и время ознакомиться с информацией😉