Методическое руководство по тестированию

Тестирование является одним из этапов
жизненного цикла ПС, направленным на
повышение качественных характеристик.

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

• отсутствие эталона (программы), которому
  должна соответствовать тестируемая
  программа;

• сложность программ и принципиальная
  невозможность исчерпывающего
  тестирования;

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

Применительно к программному средству
тестирование – процесс многократного
выполнения программ с целью обнаружения
ошибок.

Цель тестирования – выявление как можно
большего количества ошибок. Тестовый
прогон считается удачным, если он
позволяет выявить ошибки; эффективным,
если имеет высокую вероятность обнаружения
большего числа ошибок.

Существуют следующие методы тестирования
программ:

– статический; наиболее
формализованный, базируется на правилах
структурного построения программ и
обработки данных. Проверка степени
выполнения этих правил проводится без
изменения объектного кода программы
путем формального анализа текста
программы на языке программирования.
Операторы и операнды текста программы
анализируются в символьном виде, поэтому
этот метод тестирования иногда называютсимволическим тестированием;

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

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

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

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

Для тестирования программного средства
курсовой работы рекомендуется
детерминированное и стохастическое
тестирование, и их сочетание.

Детерминированное тестирование или
тестирование на определенных входных
данных, основывается на двух подходах:
структурное тестирование и функциональное
тестирование. Структурное тестирование,
или тестирование программ как «белого
ящика» (стратегия тестирования,
управляемого логикой программы),
предполагает детальное изучение текста
(логики) программы и построение таких
входных данных, которые позволили бы
при многократном выполнении программы
обеспечить выполнение максимально
возможного количества маршрутов,
логических ветвлений, циклов и так
далее. Функциональное тестирование,
или тестирование программ, как «Черного
ящика» (тестирование по «входу — выходу»),
полностью абстрагируется от логики
программы, предполагается, что логика
программы неизвестна, а тестовые наборы
подбираются на основании анализа
функциональных входных спецификаций.

При построении наборов данных по принципу
«белого ящика» руководствуются
следующими критериями:

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

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

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

• комбинаторное покрытие условий;
  используется для выполнения ошибок в
  логических выражениях. Требует создания
  такого числа тестов, чтобы все возможные
  комбинации результатов условия в каждом
  решении и все точки входа выполнялись,
  по крайней мере, один раз.

К стратегии «черного ящика» относятся
методы:

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

• анализ граничных значений. Предполагает
  исследование ситуаций, возникающих на
  границах и вблизи границ эквивалентных
  разбиений.

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

1. В спецификации программы выделяются
причины и следствия. Причина — отдельное
входное условие или класс эквивалентности
входных условий. Следствие — выходное
условие или результат преобразования
системы. Каждой причине и следствию
приписывается уникальный номер.

2. Анализируется семантическое содержание
спецификации, которая преобразуется в
булевский граф, связывающий причины и
следствия. Каждая вершина может находиться
в состоянии «истина» или «ложь».

3. Диаграмма снабжается примечаниями,
задающими ограничения и описывающими
комбинации причин и (или) следствий,
которые являются невозможными из-за
синтаксических или внешних ограничений.

4. По полученной функциональной диаграмме
строится таблица решений. Для этого
поочередно для каждого следствия,
значение которое условно устанавливается
в «истину», прослеживается обратный
путь (по диаграмме) ко всем причинам,
связанным с этим следствием, и фиксируется
их состояние. Каждый столбец таблицы
решений соответствует тесту.

5. Столбцы решений преобразуют в тесты.

В курсовой работе выполнить тестирование
программного средства, предварительно
выбрав и обосновав выбранные методы
тестирования.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Работа тестировщика входит в пятерку самых популярных работ в сфере IT, согласно статистике за 2020 год. Рынок растет очень быстро, а IT-компании постоянно создают новые команды тестировщиков. А вот еще немного впечатляющей статистики – на тестирование уходит 50% всего времени и более 50% общей стоимости любого проекта по созданию софта. А это приличный бюджет. Это означает, что налаживание процессов тестирования позволит сэкономить не только время, но и деньги.

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

Тестирование является важнейшим методом контроля качества. Под качеством программного обеспечения мы имеем в виду соответствие программного обеспечения заявленным и предполагаемым требованиям. Основная цель тестирования программного обеспечения состоит в проверке совпадений между фактическими и ожидаемыми характеристиками программы. Ручное и автоматическое тестирование – это два наиболее известных типа тестирования программного обеспечения. Оба типа моделируют возможные сценарии действий пользователей и проверяют, выполняются ли при этом требования. Но в чем разница между ними?

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

И ручное, и автоматическое тестирование являются частью контроля качества в процессе разработки программного обеспечения. Ручное тестирование подразумевает выполнение задокументированной процедуры. Устанавливается порядок проведения тестов и приводится список параметров. Поскольку процедуру выполняет человек, в ней могут содержаться заданные по умолчанию значения и ссылки на информацию, хранящуюся в другом документе.

Автоматизированная тестировка программного обеспечения снижает стоимость тестирования. На автоматизированную тестировку и устранение дефектов также уходит меньше времени, а инструменты по автоматизации снижают риски. Однако все перечисленное не значит, что автоматическое тестирование является универсальным решением. Если скрипты не включены в регрессионную или непрерывную интеграцию, предпочтительнее использовать ручную тестировку. Автоматизированная тестировка не подойдет, если скрипты временные или если автоматизация скриптов слишком сложная.

Выбор инструмента и способа тестирования зависит от ваших целей и от желаемого уровня тестирования.  

А какие еще есть типы тестов?

При классификации типов тестирования можно использовать несколько подходов. Различают методы статического и динамического тестирования, в рамках которых используются разные методы.

При статическом тестирование не выполняется программный код. Статические методы тестирования могут быть как ручными, так и автоматическими. Их используют на ранней стадии жизненного цикла программного обеспечения и они являются важной частью процесса проверки качества. В некоторых случаях можно даже обойтись без использования компьютера, например, при проверке требований.

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

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

Тестирование методом «белого ящика» и тестирование методом «черного ящика» – это ключевые методы тестирования. Разница между ними определяется наличием или отсутствием у тестировщика доступа к исходному коду программного обеспечения. В некоторых случаях он есть, в остальных тестирование выполняется через пользовательский интерфейс или интерфейс программного обеспечения, предоставленный модулем. Тестирование «белого ящика» типично для модульного тестирования, когда тестируются только определенные части системы. Это обеспечивает работоспособность и устойчивость компонентов системы. При тестировании «черного ящика» у тестировщика есть доступ к программному обеспечению только через интерфейсы, которые доступны заказчику и пользователю.

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

Этот тип тестирования подразумевает процедуру написания или выбора тестовых примеров на основе анализа функциональной или нефункциональной спецификации компонента или системы без знания ее внутренней структуры. Тестирование методом «черного ящика» выполняется с использованием спецификаций или других документов, которые описывают системные требования.

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

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

Уровни тестирования

Что касается уровней тестирования, существует модульное тестирование, интегральное тестирование, системное тестирование и приемочное тестирование. Модульное тестирование позволяет проверять правильность отдельных модулей исходного кода программы. Оно включает написание тестов для каждой нетривиальной функции или метода. Это позволяет тестировщику быстро проверить, не привело ли следующее изменение в коде к регрессу, то есть не вызвало ли оно ошибки в уже протестированных частях программы. Более того, это облегчает выявление и устранение таких ошибок. Модульное тестирование – это тестирование отдельных модулей и компонентов программы. Обычно его выполняют сами программисты, это своего рода самопроверка. Обнаруженные таким образом дефекты немедленно исправляются.

Интегральное тестирование предназначено для проверки связи между компонентами, а также взаимодействия с различными частями системы. Есть разные уровни интегрального тестирования – тестирование компонентов интеграции и тестирование системной интеграции. Интеграция снизу вверх касается всех низкоуровневых модулей, процедур и функций, которые собираются вместе и затем тестируются. Такой подход считается удобным, если все или почти все модули разработанного уровня готовы. Интеграция сверху вниз подразумевает тестирование высокоуровневых модулей. Низкоуровневые модули добавляются один за другим.

Системное тестирование проводится на полной интегрированной системе. Его основная цель – проверить, соответствует ли система требованиям. Оно относится к тестированию методом «черного ящика» и, следовательно, не требует знания внутренней структуры. Системное тестирование делится на альфа-тестирование и бета-тестирование.

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

Итак, с чего начать изучение тестирования программного обеспечения? Лучший способ стать тестером – пройти онлайн-курс, который поможет вам понять, как создается программное обеспечение, с какими трудностями сталкиваются программисты и как выглядит процесс устранения ошибок. Наши курсы предоставляют качественное обучение от лучших инструкторов, поэтому присоединяйтесь к нам. Мы поможем вам изучить основы тестировки программного обеспечения и начать карьеру в IT.

Запись на курс Manual QA

‍

‍

Уровень сложности
Простой

Время на прочтение
6 мин

Количество просмотров 8.7K

Всем привет! Меня зовут Елена Поплоухина. Я — один из авторов Youtube‑канала по тестированию «Багаж тестировщика». На канале выходил выпуск про построение процесса ручного тестирования с нуля. Данная статья содержит основную информацию из этого выпуска — 2 общих совета и 6 первых шагов для организации процесса.

Введение

Представим, что вы оказались на новом проекте. Единственным тестировщиком или в команде QA инженеров. Перед вами стоит задача — организовать процесс ручного тестирования. При этом проект находится в одной из стадий:

• Проект только стартует, команда формируется, процессы строятся с нуля;

• Проект уже развивается, выпускаются публичные релизы. Но присутствуют проблемы с качеством.

Возможно, вы чувствуете себя как ежик в тумане. С чего же начать?

Совет 1 — Начните с выяснения проблем и ожиданий от тестирования

Если разработка проекта уже ведется, выясните основные проблемы с качеством. Для этого проведите опрос среди членов команды. Начать опрос можно с QA инженеров и менеджера проекта, а далее подключить лидов разработки и остальных членов команды. 

Не ждите, что коллеги с энтузиазмом возьмутся за дело и подробно опишут проблемы. Лучше заранее подготовить список самых распространенных проблем и отправить его команде в виде опросника.  Для таких опросов хорошо подходят Гугл формы.

Примеры проблем:

• Ошибки в требованиях обнаруживаются на стадии разработки или тестирования фич;

• Значительные затраты времени на коммуникации между членами команды;

• Баги часто не воспроизводятся по описанию. Разработчикам приходится тратить время на общение с тестировщиком для выяснения деталей бага;

• Нет критериев для выпуска текущей версии приложения в прод;

• и т.д.

Дополнительно выясните ожидания от тестирования. В отличие от перечня проблем, предложите описать эту информацию в свободной форме.  Обычно ожидания тесно связаны с проблемами, выявленными на предыдущем этапе.

Ожидания от тестирования укажут направление, с которого стоит начать строить процесс тестирования. Например, ожидание «Снизить в 2 раза% возврата багов между QA и Dev» говорит о том, что нужно внедрить шаблоны для багов и согласовать регламент работы с багами.

Совет 2 — Внедряйте улучшения постепенно

По итогам опроса команды вы получите список проблем и определите ожидания от тестирования. Не стоит исправлять сразу все проблемы. Отсортируйте список по важности в зависимости от ожиданий от тестирования. Берите по одной-две проблемы из сформированного списка. Вносите улучшение, анализируйте результаты, при необходимости делайте корректировки процесса. И приступайте к исправлению следующей проблемы. Так по шагам вы выстроите процесс тестирования.

---

Далее рассмотрим 6 практических рекомендаций для организации процесса тестирования.

Внедрите шаблон бага

Разработайте шаблон бага и описывайте найденные ошибки по нему. Если на проекте используется система вики — заведите в ней отдельный раздел для тестирования и храните в нем шаблоны документов и регламенты.

Наличие шаблонов для багов несет следующие преимущества:

• Экономия времени на воспроизведении багов как разработчиками, так и тестировщиками. В случае короткого и неинформативного описания не только разработчик, но и сам автор бага может не вспомнить, о чем шла речь.

• Сокращение времени на коммуникации между dev и qa — этот пункт вытекает из предыдущего. Разработчики не будут стучаться к вам в личку со словами — а что имелось в виду в этом баге? А на каком стенде и тестовых данных он воспроизводится? 

• Единый стиль багов — с багами приятно и привычно работать всем членам команды.

Согласуйте список приоритетов багов

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

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

Вы можете установить 5 приоритетов для багов, например: 

• Блокирующий — Blocker

• Критический — Critical

• Важный — Major

• Нормальный — Normal

• Минорный — Minor

Или обойтись более простой версией из трех приоритетов:

• Высокий — High

• Средний — Normal

• Низкий — Low

Согласуйте правила установки приоритетов, оформите в виде регламента и положите в wiki.

Внедрите регламент работы с багами

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

ЖЦ бага представляет из себя описание состояний бага и правил перехода по ним в системе управления проектами. 

Для составления регламента выполните следующие шаги:

• Продумайте набор статусов для багов. 

• Определите правила перехода между статусами и порядок назначения исполнителей.

• Согласуйте регламент с менеджером проекта.

Регламент представляется в виде наглядной схемы или текстового описания. После согласования регламента с командой положите его в wiki и следите первое время за его исполнением.

Согласуйте регламент работы с задачами в системе управления проектами

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

Вся команда должна придерживаться правил перевода задач по статусам. QA инженерам особое внимание стоит уделить статусам для тестирования задач:

• Ready for test — задача завершена разработчиками и готова к тестированию;

• Testing — задача находится на тестировании у тестировщика;

• Done — задача протестирована в рамках итерации;

• и т.д.

Пишите тест-кейсы или чек-листы… как можно раньше в процессе обеспечения качества

Один из первых навыков, которым учатся тестировщики — проектирование тест-кейсов. Это база. Тем не менее, тестировщики не всегда создают тестовые сценарии «на бумаге».

Одной из главных причин называется «нет времени». Эта проблема решается путем грамотного планирования итерации и оценки времени на тестирование.

При отсутствии чек‑листов или тест‑кейсов вы рискуете качеством своего продукта.

2 основных совета по стадии проектирования тест-кейсов следующие:

• Если нет необходимости в тест-кейсах, пишите чек-листы; 

• Пишите тест-кейсы или чек-листы как можно раньше в процессе обеспечения качества. В идеале — еще на стадии тестирования требований или до разработки.

Преимущества раннего проектирования тест-кейсов или чек-листов:

• Вы не торопитесь, сосредоточены и можете качественно продумать тестовые случаи;

• Ранний поиск ошибок в требованиях;

• Возможность приступить к тестированию сразу после передачи задачи на тест.

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

Минусы тестирования без тест-кейсов или чек-листов:

• Вы придумываете тестовые ситуации на ходу, при этом прерываетесь на тестирование, локализацию и заведение багов, коммуникации;

• Перепроверка одних и тех же ситуаций несколько раз;

• Риск пропуска тестовых случаев повышается из-за спешки или отсутствия задокументированных результатов выполнения;

• Присутствует ощущение, что “вроде вы все проверили”, но “возможно что-то забыли”.

Риск пропуска багов в таком случае гораздо выше, чем при наличии кейсов. А уверенность в качестве продукта — ниже.

Установите критерии выпуска релиза в прод

Как определить, когда текущая версия готова к релизу? Ждать до исправления последнего бага или все же нет?

Ответить на эти вопросы помогают критерии выпуска релиза в прод. Это четкие правила, при выполнении которых вы как специалист по качеству можете дать добро на релиз. 

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

Пример критериев:

• По всем фичам проведено тестирование;

• По фичам исправлены баги всех приоритетов, кроме низкого;

• Проведено регрессионное тестирование;

• и т.д.

В результате тестирования вы предоставляете менеджеру проекта решение о готовности продукта к релизу. Критерии помогут вам перейти от варианта “вроде все работает” к обоснованному заключению.

Заключение

Мы рассмотрели 2 общих совета и 6 первых практических шагов для построения процесса ручного тестирования на проекте.

Спасибо за внимание и до встречи в следующей статье!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

	Вопрос на ручной ввод числа предполагает ввод числа или нескольких чисел в качестве ответа. Правильный ответ, при создании теста, может быть задан в виде числа или в виде числового диапазона. В последнем случае ответ тестируемого считается правильным если он попадает в указанный диапазон. Каждое поле для ввода числа может иметь подпись. Это удобно при использовании ввода нескольких чисел. Также имеется возможность не учитывать порядок введенных чисел. Например, при вводе корней квадратного уравнения не важно в какое поле ввести какое значение, лишь бы были нужные значения. При вводе ответа тестируемый может ввести только число (буквы и др. знаки игнорируются). Так же не возникает проблем с символом для разделения целой и дробной части — можно вводит либо точку, либо запятую — программа сама подкорректирует символ. После того как введен вариант ответа для перехода к следующему вопросу достаточно нажать либо клавишу Enter, либо клавишу Пробел, либо щелкнуть по кнопке «Дальше» мышкой. Ручной ввод текста		Вопрос на ручной ввод текста предполагает введение текстовой строки в качестве ответа. При создании теста можно задать не один, а несколько вариантов ответа. Ответ считается верным если совпадает хоть с одним из вариантов. Т.е. вы можете предусмотреть возможные опечатки (например, позиционная и позиционая) или неоднозначности ввода (например, алгоритм и алгоритмом). Так же вы можете указать учитывать или нет регистр символов. В качестве вариантов ответа можно использовать регулярные выражения. Это позволяет более гибко использовать этот тип заданий. Если включен Обучающий режим, то в качестве верного ответа будет показан первый (первая строка из нескольких возможных). Поэтому, если используете регулярные выражения, рекомендуется первый вариант задавать просто в виде текста. После того как введен вариант ответа для перехода к следующему вопросу достаточно нажать либо клавишу Enter, либо клавишу Пробел, либо щелкнуть по кнопке «Дальше» мышкой. Место на изображении

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

Нужны ли мне какие-то знания для работы с учебником?

Учебник рассчитан на начинающих тестировщиков с небольшим опытом в QA (или вообще без опыта).

Содержание

• 👶 Основы тестирования
• ↔️ Типы тестирования
• 📄 Тестовая документация
• 📁 Тест-кейсы
• 🛠️ Техники тест-дизайна
• 🐞 Все о багах
• ⚙️ Автоматизация
• 🚄 Тестирование производительности
•  📱 Тестирование мобильных приложений
• 🛠️ Инструменты тестировщика
• 💬 Софт-скиллы
• 👨‍💼 Собеседование
• 🔥 Интересное
• ✅ Тесты для самопроверки
• 📚 Чтение для отдыха

👶 Основы тестирования

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

Читать	Тестирование. Что это такое, описание, виды тестирования
Читать	Путь тестировщика: скиллы, зарплата, перспективы
Читать	Большая дорожная карта развития тестировщика
Читать	Семь главных принципов тестирования
Читать	STLC — жизненный цикл тестирования приложений. Этапы, критерии начала и окончания
Читать	V-модель тестирования
Читать	Этапы тестирования
Читать	Уровни тестирования
Читать	Функциональные и нефункциональные требования

↔️ Типы тестирования

Разбираемся в видах и типах тестирования — важно понимать особенности каждого из них. Чем отличается модульное тестирование от smoke-тестирования? Что такое альфа-, бетта- тестирование? Чем функциональное тестирование отличается от нефункционального? Ответы на все эти и многие другие вопросы в статьях ниже.

Читать	Виды и типы тестирования: подробный разбор
Читать	Тестирование белого ящика vs тестирование черного ящика
Читать	Что такое ручное тестирование?
Читать	Что такое статическое и динамическое тестирование
Читать	Негативное тестирование: что это
Читать	Юзабилити-тестирование — большой гайд
Читать	Тестирование GUI: мини-гайд
Читать	Что такое функциональное тестирование? Мини-гайд
Читать	Нефункциональное тестирование — гайд
Читать	Что такое регрессионное тестирование?
Читать	Что такое системное тестирование?
Читать	Приемочное тестирование
Читать	Санитарное тестирование (sanity testing) — небольшой гайд
Читать	𝛼 Что такое альфа-тестирование?
Читать	β Что такое бета-тестирование?
Читать	Что такое monkey-testing? Чем отличается от ad-hoc тестирования? Что такое torture тестирование?
Читать	Что такое smoke-тестирование?
Читать	Что такое риск-тестирование?
Читать	Что такое ad-hoc тестирование?
Читать	Что такое тестирование доступности?
Читать	Что такое кросс-браузерное тестирование?
Читать	Тестирование конфигураций
Читать	Тестирование масштабируемости
Читать	Инсталляционное тестирование
Читать	Тестирование пиков нагрузки
Читать	Исследовательское тестирование

📄 Тестовая документация

Все о тестовой документации и о том, как ее писать.

Читать	Что такое тестовая документация и зачем она нужна?
Читать	Тестовые артефакты
Читать	Что такое тест план и как его написать?
Читать	Что такое use case? Теория и примеры
Читать	Что такое тестовый сценарий?
Читать	Что такое user story и как ее писать?
Читать	Что такое стратегия тестирования
Читать	Матрица сопоставления требований с тест-кейсами
Читать	Стратегия обеспечения качества и вопросы в процессе ее составления

📁 Тест-кейсы

Руководства по написанию тест-кейсов.

Читать	Техники тест-дизайна: теория и примеры
Читать	Как писать тест-кейсы: полное руководство
Читать	Основные методики создания тест-кейсов
Читать	Тестовый набор (тест-сьют)

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

Классы эквивалентности, таблицы решений, предугадывание ошибок и многое другое — раздел о техниках тестирования.

Читать	Что такое предугадывание ошибок?
Читать	Что такое классы эквивалентности?
Читать	Анализ граничных значений
Читать	Что такое таблица решений?
Читать	Попарное тестирование

🐞 Баги

Баги, их классификация и баг-репорты — обо всем этом в разделе.

Читать	Жизненный цикл бага
Читать	Как искать баги — гайд
Читать	Что такое баг-репорт?
Читать	Как составить баг-репорт: мини-гайд
Читать	Как написать классный баг-репорт
Читать	Серьезность и приоритет багов — в чем разница?
Читать	Верификация и валидация: что это и в чем разница?
Читать	Баг-трекинговые системы: Jira и альтернативные варианты

⚙️ Автоматизация

Читать	Что такое автоматизированное тестирование?
Читать	Что такое автоматизированное тестирование? Гайд по основам
Читать	Что такое ручное тестирование. Основные подходы и инструменты
Читать	В чем разница между ручным и автоматизированным тестированием?
Читать	Почему не получается автоматизация — 100 причин (на самом деле меньше)
Читать	Как не надо автоматизировать
Читать	Как стать автоматизированным тестировщиком? Небольшой план действий
Читать	Автоматизация кроссбраузерного тестирования на Java/Python/JS — гайд
Читать	Решаем, что и когда автоматизировать, и нужно ли
Читать	Как выбрать инструменты автоматизации (с таблицей)
Читать	Три типичных ошибки автоматизатора
Читать	Определяем, нужно ли автоматизировать тест-кейс? Чеклист, который вам поможет.
Читать	Признаки ХОРОШЕГО автотеста
Читать	Траблы автоматизации — как их избежать
Читать	Автоматизированное тестирование НИКОГДА не заменит ручное
Читать	Лучшие open-source инструменты для автоматизированного тестирования
Читать	Автоматизация: актуальные инструменты (и статистика)
Читать	5 самых популярных инструментов автоматизации тестирования в 2022 году

🚄 Тестирование производительности

Читать	Тестирование производительности веб-сервисов — теория и инструменты
Читать	Что такое нагрузочное тестирование
Читать	Что такое объемное тестирование?
Читать	Что такое стресс-тестирование: мини-гайд
Читать	Тестирование производительности в Postman
Читать	Планируем нагрузочное тестирование
Читать	Топ-15 бесплатных инструментов для нагрузочного тестирования

📱 Тестирование мобильных приложений

Обучающие материалы по мобильному тестированию.

Читать	Тестирование мобильных приложений: шаги и процедуры
Читать	Большой гайд по тестированию Android-приложений
Читать	Appium — гайд
Читать	Автоматизация жестов в Appium: блиц-практикум
Читать	Моки в инструментальных тестах Android
Читать	Большой гайд по автоматизации в XCUITest

🛠️ Инструменты

Читать	Chrome Developer Tools для тестировщика
Читать	Docker — быстрый гайд
Читать	Bugzilla: экспресс-гайд
Читать	Playwright — базовый гайд
Читать	Puppeteer — большой гайд
Читать	Пять расширений Google Chrome для тестировщиков
Читать	Гайд по Selenium. Часть 1. Установка Selenium WebDriver
Читать	Большой гайд по тестированию с Postman для начинающих
Читать	TestNG — большой гайд
Читать	Тестирование производительности API с помощью K6
Читать	100 (да, сто) бесплатных советов по Java-инструментам QA
Читать	Что такое Cypress: Введение и архитектура
Читать	Как ускорить тесты Selenium — полный гайд
Читать	Ошибки в Selenium — гайд по exceptions
Читать	Плюшевый Cypress: 5 советов
Читать	Что удобнее, Cypress или Selenium
Читать	E2E-тестирование в Cypress
Читать	Бесплатные онлайн-генераторы тестовых данных
Читать	Десять классных генераторов тестовых данных
Читать	Автотесты и Docker: блиц-практикум
Читать	Обзор фреймворков для iOS тестирования
Читать	Как ускорить тесты с помощью сypress-grep
Читать	Регрессионное тестирование: подборка инструментов
Читать	Эмуляторы и симуляторы: в чем разница?
Читать	Playwright config — смотрим в деталях
Читать	Кажется, Playwright уже лучше чем Cypress
Читать	curl — учимся тестировать API

💬 Софт-скиллы

Читать	Как войти в QA: cоветы QA Lead
Читать	Пять технических и пять нетехнических навыков хорошего QA
Читать	Экономия на тестировщиках? Что такое Lean QA
Читать	Вильфредо Парето говорит: сосредоточься на главном
Читать	Бритва Оккама: как тестировщик решает вопросы правильно и быстро
Читать	Как стать QA-лидом
Читать	Как QA общаться с разработчиками? Что делать ✅ и чего не делать ❌

👨‍💼 Собеседование

Материалы для подготовки к собеседованиям — вопросы и ответы по самым разным темам.

Читать	Что можно и чего нельзя делать на собеседовании по тестированию
Читать	Тестировщик без опыта — советы по резюме
Читать	Вопросы на собеседовании тестировщика — стажер/джуниор
Читать	Вопросы на собеседовании тестировщика: джуниор++/миддл
Читать	Собеседование тестировщика — cкользкие вопросы
Читать	Вопросы по SQL и базам данных на собеседовании тестировщика (+ ответы)
Читать	Собеседование QA — что спрашивают о CI/CD
Читать	О чем спрашивают на собеседовании QA Junior: Selenium
Читать	Идем на собеседование на позицию тестировщика — 36 частых вопросов по Postman
Читать	QA-интервью: как решить любую задачу
Читать	Метод STAR на собеседовании
Читать	Собеседование тестировщика в Евросоюзе и США/Канаде: вопросы
Читать	Тайтлы в QA

🔥 Интересное

Читать	Языки программирования, которые тестировщик обязан знать
Читать	Нестабильные тесты. Почему они существуют и что с ними делать
Читать	ChatGPT для тестировщика — как создавать тесты и документацию?
Читать	Что такое CI/CD (непрерывная интеграция и доставка)
Читать	Почему Google не нанимает тестировщиков
Читать	Что такое тестовое покрытие (test coverage)
Читать	Релизим в пятницу без валидола — советы для безопасных релизов
Читать	Как ускорить регрессионное тестирование
Читать	Структуры данных — большой гайд
Читать	Что такое BDD? Опыт с Cucumber/Gherkin + вопросы на собеседовании
Читать	Контролируем тестовые девайсы (и тестировщиков) в Slack
Читать	Владелец продукта и скрам-мастер: в чем разница?
Читать	Советы для проведения эффективного ретро
Читать	Осваиваем Data-driven Testing в Selenium
Читать	Английский для тестировщиков. Грамматика с Джеймсом Виттакером, Ли Коуплендом и другими мэтрами тестирования
Читать	Большой гайд по Page Object Model
Читать	Юнит-тесты vs интеграционные тесты
Читать	JavaScript QA — делаем все правильно с самого начала
Читать	Кто такие стейкхолдеры? Определения, типы и примеры
Читать	Мутационное тестирование. Теория + практикум
Читать	Бэклог продукта и бэклог спринта: краткое руководство
Читать	QA-команда и DevOps: что делать
Читать	10 советов по управлению проектами
Читать	Типичные вопросы для собеседования на проджект менеджера и как на них отвечать
Читать	Юнит-тесты и Jest: toBe or not.toBe
Читать	Как тестировать формы? Мини-руководство
Читать	В чем разница между QA и QC?
Читать	13 вопросов и ответов на собеседовании на scrum-мастера
Читать	Борьба с задержкой тестов в Selenium: пример из практики
Читать	E2E-тестирование в Cypress
Читать	Параметризация тестов: JUnit
Читать	Искусственный интеллект в функциональном тестировании
Читать	Сказ о ненатуральном эджайле
Читать	Как тестировать GraphQL API? Гайд для начинающих
Читать	Введение в тестирование блокчейна
Читать	6 готовых оправданий, чтобы не писать юнит-тесты
Читать	Что такое Test-Driven-Development?
Читать	Unit-тесты на фронтенде. Best practices

✅ Тесты для самопроверки

Читать	Тест по основам тестирования
Читать	Блиц-тест ISTQB — Основы
Читать	Тест по основам тестирования (in English)
Читать	Тестовый экзамен ISTQB Foundation Level (на английском)

📚 Чтиво

Интересные статьи по теме. Смотрим, почему QA-инженеры нужны и к каким багам приводит некачественное тестирование.

Читать	7 эпичнейших багов в истории человечества
Читать	Баги войны
Читать	Баги войны: вторая часть
Читать	«Грудь выскочила наружу, не могу убрать ее обратно» — о багах в играх и отношении к джунам на примере Cyberpunk 2077
Читать	В России растут зарплаты тестировщиков. Смотрим, кому, где и сколько платят
Читать	Тестирование легче программирования? Мой путь из программиста в QA
Читать	Обычный день твоего лида
Читать	Пузырь популярности ИТ скоро лопнет. Глобальное сокращение на горизонте
Читать	Тренды тестирования 2021. Правда и мифы