QA Engineer
  • Введение
  • FAQ
    • Качества и навыки, которыми нужно обладать тестировщику?
    • Что должен знать и уметь Midle? Что спросят на собеседовании?
    • Как происходит процесс найма?
    • Как проходить собеседование?
    • Ошибки в работе у начинающих тестировщиков
    • Как взаимодействовать с коллегами?
  • МОДУЛЬ 1. ТЕОРИЯ ТЕСТИРОВАНИЯ
    • Общее понимание тестирования
  • Виды тестирования
    • Функциональное тестирование
    • Нефункциональное тестирование
    • Тестирование связанное с изменениями
  • Уровни тестирования
  • Методы тестирования
    • Black box testing
    • White Box Testing
    • Grey box testing
  • Тест-Дизайн
  • Тестовая документация
    • Требования
      • Тестирование требований
    • Тест-план
    • Чек-лист
    • Тест-кейс
    • Баг-репорт
  • ЗАДАНИЕ. ТЕСТ
  • МОДУЛЬ 2. API (BackEnd)
    • API. Что это?
  • Архитектуры ПО
    • Монолитная архитектура
    • Микросервисная архитектура
  • Брокеры сообщений
    • Kafka
  • Клиент-серверное взаимодействие
  • Тестирование API (BackEnd)
    • REST и SOAP
    • jRPC
    • JSON
    • XML
    • Протоколы
    • Коды состояния ответов HTTP(S)
    • Логирование (Logs)
  • Swagger
  • Postman
  • ЗАДАНИЕ. ТЕСТИРОВАНИЕ API
  • МОДУЛЬ 3. FRONTEND и WEB
    • Теория FrontEnd
    • Элементы интерфейса сайта
  • Верстка
  • Основы HTML
  • CSS
  • Сети и около них
    • Идентификация ресурсов в сети (Identifying resources on the Web)
    • Веб-сервис (WS - Web service)
    • Сокет/веб-сокет (socket/websocket)
    • Рендеринг в интернете (Rendering on the Web)
  • DevTools
    • Network
    • Application
    • Source
    • Elements
    • Console
    • Performances
  • Кроссбраузерность
  • Сетевые данные
    • Сache
    • Сookie
  • МОДУЛЬ 4. SDLC и STLC
    • Жизненный цикл разработки SDLC
    • Жизненный цикл тестирования STLC
    • Модели разработки ПО
      • «V-Model»
      • «Waterfall Model» (каскадная модель или «водопад»)
      • «Agile Model» (гибкая методология разработки)
    • Agile
    • Scrum
    • Подходы к разработке/тестированию
  • МОДУЛЬ 5. БАЗЫ ДАННЫХ.
    • Теория
    • Типы БД
      • Реляционные
      • Нереляционные
    • SQL. ОСНОВЫ
      • Работа с Select * From
      • JOIN
    • Задание
  • ALL SOFT (Ознакомление)
    • Jira и Confluence
    • SOAP UI
    • Git
    • Kibana
    • Docker
    • Jenkins
Powered by GitBook
On this page
  • Для чего проводится тестирование ПО?
  • Принципы тестирования
  • Требования
  1. МОДУЛЬ 1. ТЕОРИЯ ТЕСТИРОВАНИЯ

Общее понимание тестирования

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

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

Для чего проводится тестирование ПО?

  • Для проверки соответствия требованиям

  • Для обнаружение проблем на более ранних этапах разработки и предотвращение повышения стоимости продукта

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

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

Принципы тестирования

  • Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects). Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.

  • Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible). Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).

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

  • Принцип 4 — Скопление дефектов (Defects clustering). Большая часть дефектов находится в ограниченном количестве модулей.

  • Принцип 5 — Парадокс пестицида (Pesticide paradox). Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.

  • Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.

  • Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям. Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть. QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта. К задачам контроля качества относятся:

    • проверка готовности ПО к релизу;

    • проверка соответствия требований и качества данного проекта.

QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества. К задачам обеспечения качества относятся:

  • проверка технических характеристик и требований к ПО;

  • оценка рисков;

  • планирование задач для улучшения качества продукции;

  • подготовка документации, тестового окружения и данных;

  • тестирование;

  • анализ результатов тестирования, а также составление отчетов и других документов.

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

Этапы тестирования:

  1. Анализ продукта

  2. Работа с требованиями

  3. Разработка стратегии тестирования и планирование процедур контроля качества

  4. Создание тестовой документации

  5. Тестирование прототипа

  6. Основное тестирование

  7. Стабилизация

  8. Эксплуатация

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

  1. анализ требований к проекту;

  2. проектирование;

  3. реализация;

  4. тестирование продукта;

  5. внедрение и поддержка.

!!!Тестовое Покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Сложность современного ПО и инфраструктуры сделало невыполнимой задачу проведения тестирования со 100% тестовым покрытием. Поэтому для разработки набора тестов, обеспечивающего более-менее высокий уровень покрытия можно использовать специальные инструменты либо техники тест дизайна.

Требования

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

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

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

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

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

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

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

  7. Атомарность — требование нельзя разбить на отдельные части без потери деталей.

  8. Модифицируемость — в каждое требование можно внести изменение.

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

PreviousКак взаимодействовать с коллегами?NextВиды тестирования

Last updated 1 year ago