Теория тестирования ПО просто и понятно
Время на прочтение
Привет, Хабр! Да-да, про тестирование ПО тут уже куча статей. Здесь я просто буду стараться структурировать как можно более полный охват данных из разных источников (чтобы по теории все основное было сразу в одном месте, и новичкам, например, было легче ориентироваться). При этом, чтобы статья не казалась слишком громоздкой, информация будет представлена без излишней детализации, как необходимая и достаточная для прохождения собеседования (согласно моему опыту), рассчитанное на стажеров/джунов (как вариант, эта информация может быть для общего понимания полезна ИТ-рекрутерам, которые проводят первичное собеседование и попутно задают некоторые около-технические вопросы).
ОСНОВНЫЕ ТЕРМИНЫ
Тестирование ПО (Software Testing) — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом. Чем занимаются в тестировании:
Основные цели тестирования
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Жизненный цикл бага
Градация Серьезности дефектаКрит (Critical) – неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие непрямые пути (workaround). Значительный (Major) – часть основной бизнес логики работает некорректно, есть возможность для работы с тестируемой функцией, используя обходные пути (workaround); либо дефект с высоким visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза. Minor – часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид; либо незначительная функциональная ошибка, не нарушающая бизнес-логику тестируемой части приложения. Тривиальная (Trivial) – ошибка, не касающаяся бизнес-логики приложения, не оказывающая никакого влияния на общее качество продукта, например, опечатки в тексте, несоответствие шрифта и оттенка и т.д.
НЕКОТОРЫЕ ТЕХНИКИ ТЕСТ-ДИЗАЙНА
Пример таблицы принятия решений
ВИДЫ ТЕСТИРОВАНИЯ
Основные виды тестирования ПО
Классификация по целям
Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности. Тестирование пользовательского интерфейса (GUI Testing) — проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior). Тестирование удобства использования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Состоит из: UX — что испытывает пользователь во время использования цифрового продукта, и UI — инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс». Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным. Инсталляционное тестирование (installation testing) направленно на проверку успешной установки и настройки, а также обновления или удаления приложения. Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться, т.е. обеспечивать сохранность и целостность данных, после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями. Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок. Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству). Тестирование стабильности или надежности (Stability / Reliability Testing) — это проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки. Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса (например, повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера) и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Объемное тестирование (Volume Testing) — тестирование, которое проводится для получения оценки производительности при увеличении объемов данных в базе данных приложения. Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
Классификация по позитивности сценария
Классификация по знанию системы
Классификация по исполнителям тестирования
Классификация по уровню тестирования
Подходы к интеграционному тестированиюСнизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения. Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами. Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Классификация по исполнению кода
Классификация по хронологии выполнения
ДОКУМЕНТАЦИЯ
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Основные атрибуты требований:
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию:
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. М СТ используется для покрытия продукта тестами.
Чек-лист (check list) — это документ, описывающий что должно быть протестировано. На сколько детальным будет чек-лист зависит от требований к отчетности, уровня знания продукта сотрудниками и сложности продукта. Чаще всего, в ЧЛ содержатся только действия, без ожидаемого результата. Ч Л менее формализован, чем тестовый сценарий.
Тестовый сценарий (Test Case) — это документ, в котором содержатся условия, шаги и другие параметры для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Из тестовых сценариев, сгруппированных по некоему признаку (например, тестируемой функциональности), получаются некоторые наборы. Они могут быть как зависящими от последовательности выполнения (результат выполнения предыдущего является предварительным условием для следующего для Test script), так и независимыми (Test suite).
Отчёт о дефекте (Bug Report) — это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе функциональности.
Спасибо большое всем за фидбэк, благодаря которому материал обновляется и дополняется
Зачем в команде тестировщик, если проверить продукт могут сами программисты и менеджеры? Оказывается, всё не так однозначно.
vlada_maestro / shutterstock
За последние 17 лет прошёл весь путь от начинающего программиста до CTO в крупных проектах. Специализируюсь на стартапах и работе с удалёнными командами.
За последние 17 лет прошёл весь путь от начинающего программиста до CTO в крупных проектах. Специализируюсь на стартапах и работе с удалёнными командами.
Как-то раз ко мне обратился руководитель одного криптовалютного стартапа и попросил проконсультировать по проверке их сети перед запуском первого публичного тестнета. Кроме главы компании на первой встрече присутствовали три разработчика. На мой вопрос: «А где же ваш QA-инженер, ведь речь пойдёт именно о тестировании?» — они переглянулись и сказали, что у них нет QA, а разработчики сами проверяют свой код.
Эта ситуация встречается довольно часто. Не только стартапы, но и большие компании иногда не видят необходимости в QA-отделе, отдавая его задачи разработчикам или максимально автоматизируя. Я хочу рассказать, почему это не самая лучшая идея и как я лично отношусь к роли QA в организации.
Начем с того, что QA-инженер — одна из самых недооценённых профессий в нашей индустрии. Зарплаты тестировщиков обычно намного меньше, чем зарплаты программистов. Соответственно, эта сфера меньше привлекает талантливых людей. А если уж они и попадают в неё, то стремятся как можно быстрее продвинуться в разработку или управление проектами, чтобы зарабатывать больше.
Всё это приводит к тому, что найти хорошего тестировщика гораздо сложнее, чем хорошего программиста. При этом количество технических знаний, необходимых QA-инженеру, никак не меньше, чем разработчику. Кроме того, тестировщик должен обладать набором уникальных скилов, которых зачастую нет у кодеров. Поэтому хороший QA-специалист сегодня на вес золота.
Чтобы понять эту мысль, давайте разберём, как в теории должен происходить процесс разработки.
Если это описание вызвало у вас слёзы умиления, то я с вами. Потому что хороших продюсеров вообще очень мало, а тех, кто способен написать детальный спек, — единицы. Программисты редко видят картину настолько, чтобы уже на стадии имплементации замечать в спеках ошибки. Особенно если они не находятся внутри одного конкретного модуля, над которым сейчас работают.
Так что вернёмся теперь в реальность и попробуем разобраться, как в действительности выглядит проверка ПО и какие роли в организации исполняют тестировщики.
Тестировщики должны понимать систему в целом. Зачастую они единственные люди в организации, которые на это способны. По мере увеличения сложности продукта задача становится всё более и более трудоёмкой. Время проведения полной регрессии продукта растет экспоненциально с количеством взаимосвязанных модулей. Изменения в одной из частей системы могут непредсказуемым образом отразиться на поведении остальных.
Для понимания всех этих взаимосвязей, без которого легко пропустить в продакшн серьёзные баги, требуются время, знания, внимание и опыт. Со временем у QA вырабатывается интуиция, которая необходима, поскольку полная проверка всех возможных сценариев слишком трудоёмка и иногда попросту невозможна. Это означает, что работа тестировщика не может быть ограничена механическим исполнением тест-плана.
В случае, когда проблемы проявляются на стадии спецификаций, особенно во взаимодействии разных модулей, только QA имеют возможность заметить их на этом этапе и предотвратить пустую трату времени на имплементацию заранее неудачных решений.
От редакции: На наш взгляд не стоит говорить о QA-специалистах как о некой единой группе. Во-первых, в сложных проектах обычно есть системный архитектор, который видит проект в целом. А во-вторых, у тестировщиков может быть разный уровень задач. Часто тестирование сводится к прогону типовых и небольшого количества нетиповых пользовательских сценариев. Понятно, что занимающиеся этим специалисты не будут стоить дорого. Но такого шаблонного тестирования зачастую достаточно (особенно для обновляющихся продуктов, а не создаваемых с нуля) либо оно снимает основной объём проблем. Нам кажется, что потому профессия и не становится более заметной на рынке, что основной объём задач тестирования покрывается, так сказать, «минимальными версиями специалистов».
В идеале всё должно быть задокументировано: от кода до пользовательского руководства. На практике QA-специалисты в большинстве случаев знают про систему больше, чем кто-либо другой в организации. Именно они сталкиваются с максимальным количеством сценариев на разных системах. В результате тестировщики зачастую являются тем центром знаний, который гарантирует целостность понимания системы. Именно к ним имеет смысл обращаться за объяснениями, как работает та или иная функциональность.
Это очень важный момент. Если в организации нет QA-отдела, для того чтобы понять, как ведёт себя конкретный элемент системы, надо найти разработчика, который его писал, и надеяться на то, что он помнит, что и как он делал пару месяцев назад. Это в том случае, если он всё ещё работает в компании.
От редакции: Отметим, что чаще всего документация, независимо от этапа разработки, пишется на основе кода, а тесты — уже на основе документации. Далее, в зависимости от уровня компетентности тестировщиков, документация может пополняться. Утверждать, что тестировщик берёт код, тестирует и на основе своих опытов пишет доки, — всё же слишком категорично. С утверждением «если нет QA, то и не понять, как ведёт себя элемент» тоже можно поспорить. Правила разработки требуют, чтобы программисты комментировали и документировали код. Если код не задокументирован — проблема не в отсутствии QA-службы, а в том, что весь процесс разработки построен криво и неуправляемо.
Тестировщики должны понимать, как технически устроены все компоненты, и владеть соответствующими инструментами, чтобы их эффективно проверять. Но этого мало. Нужно уметь создавать ситуации, которых не было в процессе разработки, но они могут появиться при эксплуатации. Для этого требуется глубокое понимание технологий, умение прогнозировать сценарии и предвидеть проблемы.
Но и это ещё не всё. Тестировщик обязан заметить, если каким-то функционалом неудобно пользоваться. Что он непонятен или не соответствует существующим стандартам. Нужно уметь думать как пользователь и смотреть на продукт его глазами и свободно ориентироваться в предметной области продукта.
У тестировщика должно быть отличное понимание процессов в организации, чтобы знать, к кому обратиться с вопросом и кому перевести баг. И, конечно, умение эффективно общаться с разработчиками и продактами, с каждым говоря на его языке.
Если бы Супермен работал в IT, он был бы тестировщиком.
Друг, который занимался тестированием высоконагруженных серверов, рассказал мне историю. В одной большой компании начали проверять новую версию системы и обнаружили, что не хватает записей в логах, позволяющих понять, что происходит в определённом наборе сценариев. Разработчиков попросили их добавить. Но у тех обычно горят дедлайны и спринты забиты под завязку — обещали сделать, но в рамках своих приоритетов. Проверить систему было нельзя, и моему другу пришлось идти к начальству — просить, чтобы надавили на разработчиков и они добавили три строчки логов.
Это неправильно. Тестировщикам требуется непоколебимый авторитет: когда они что-то говорят, все должны внимательно слушать и немедленно исполнять. Q A-специалисты должны влиять на процессы и присутствовать на всех совещаниях на стадиях планирования и разработки. К их мнению стоит прислушиваться на всех этапах проектирования.
От редакции: Приведённый пример — в большей степени о взаимодействии отделов. Так будет происходить в любой организации, где есть деление на отделы с внутренней приоритезацией задач. Руководитель отдела расставил очередность, а тут приходит запрос от другого отдела. Никто не возьмётся за чужую задачу, пока руководитель не внесёт её в список задач отдела. То есть решение не столько в том, чтобы тестировщик напрямую ставил задачи программистам, сколько в том, чтобы урегулировать это на уровне процессов: передачи информации от отдела к отделу и приоритезации, которая оговаривается заранее. Потому что хотелки тестировщиков не всегда критически важные.
«У нас все проверяют продукт, даже CEO занимается этим», — часто слышу я. Прекрасно! Но CEO не всегда может правильно открыть баг в системе, перепроверить его, когда он будет закрыт, и проследить, что именно входит в каждый конкретный релиз. Разработчики сами проверяют свой код? Несомненно, так и должно быть. Но просить программиста найти то, о чём он не подумал на стадии написания кода, — по меньшей мере чересчур оптимистично. У вас автоматизированы QA-процессы? Прекрасно. Это может упростить жизнь тестировщику, но никакое автотестирование не сможет заменить человека.
В конце концов, именно тестировщики несут ответственность за качество продукта, отсюда и название этой профессии — Quality Assurance. Не надо забывать, что именно они и есть та последняя линия обороны, которая стоит между вами и большими проблемами.
Жизнь можно сделать лучше!Освойте востребованную профессию, зарабатывайте больше и получайте от работы удовольствие. А мы поможем с трудоустройством и важными для работодателей навыками.
Текущая версия страницы пока не проверялась опытными участниками и может значительно отличаться от версии, проверенной 2 января 2022 года; проверки требуют 9 правок.
По виду деятельности могут выделяться:
Необходимыми качествами тестировщика являются логическое мышление, внимательность, хорошая память, умение учиться и адаптироваться к существующим задачам, быстро переключаться с одного типа задач на другой. Не менее важны терпение, усидчивость и умение работать в команде.
Кроме того, тестировщик выступает одновременно и как пользователь, и как эксперт, а потому должен иметь определённый склад мышления: уметь воспроизводить поведение пользователя продукта и анализировать поведение системы, входящие параметры и полученные результаты с точки зрения инженера. Одной из особенностей профессии является возможность удалённой работы, причём расстояние часто не имеет значения (тестировщик может находиться в другом городе или стране по отношению к разработчику и заказчику).
Основными требованиями к соискателю, как правило, являются:
При этом требования к уровню необходимых навыков и специализации варьируются в зависимости от тестируемого программного обеспечения.
9 сентября отмечается неофициальный «день тестировщика». и 3 мая день рождения основателя направления тестирования в ИТ Гищёвского Г. G
На курсе, где я учился frontend-разработке, нас познакомили только с unit тестированием. Но уже на первом месте работы, я столкнулся и с регрессионным тестированием, и с автотестами, и с E2E-тестами. Мне было сложно понять, чем они отличаются, какие еще есть виды тестирования и кто их должен писать. Эта статья для начинающих разработчиков, которые задаются подобными вопросами.
Модульное тестирование (Unit testing)
Модульное тестирование выполняется на уровне отдельных блоков приложения. Это может быть тест, который проверяет корректность работы отдельной функции или React-компонента.
Пример. Функция на JavaScript принимает два числа и возвращает сумму.
Пример модульного теста, который проверяет работу этой функции:
Кто пишет тесты: модульные тесты обычно пишет сам автор кода.
ПРИМЕЧАНИЕ: я написал обзорную статью на библиотеку React-testing-library, в ней подробно рассказывается, как покрыть unit-тестами React-компонент.
Интеграционное тестирование (Integration testing)
Интеграционное тестирование проверяет правильность взаимодействия узлов IT-продукта. При проведении интеграционного тестирования необходимо убедиться в том, что каждый компонент приложения работает корректно при определенном сценарии. Веб-интерфейс должен правильно отправлять запросы к API, API должен правильно обрабатывать запросы и взаимодействовать с базой данных, а база данных сохранять нужную информацию.
Кроме того, нужно убедиться в том, что приложение работает корректно в случае возникновения ошибок, например, при отсутствии соединения с базой данных.
ВАЖНО: Корректность обработки ошибок – это часть любого вида тестирования.
Интеграционное тестирование выполняется как вручную, так и автоматизированно с использованием специальных инструментов, таких как Postman или SoapUI.
Пример. Приложение для онлайн-оплаты, которое включает в себя: веб-интерфейс, API для обработки платежей и базу данных для хранения информации о платежах. Интеграционное тестирование поможет убедиться в том, что компоненты работают корректно вместе.
Один из возможных сценариев тестирования:
Кто пишет тесты: Интеграционные тесты обычно пишутся командой QA-инженеров.
Функциональное тестирование (Functional testing)
Функциональное тестирование проводится для проверки функциональности приложения. Оно позволяет убедиться в том, что приложение работает корректно и выполняет функции, соответствующие требованиям пользователей и заказчика.
Функциональное тестирование проверяет отдельные функции и возможности приложения, а интеграционное тестирование проверяет взаимодействие компонентов системы в целом.
Пример. Веб-приложение для онлайн-бронирования номеров в отеле. Функциональное тестирование поможет убедиться в том, что приложение работает корректно и выполняет свои функции.
Возможный сценарий тестирования:
Кто пишет тесты: функциональные тесты обычно пишутся командой QA-инженеров.
ПРИМЕЧАНИЕ: Пара слов о End-to-End(E2E) тестировании, это тестирование, которое позволяет проверить работу всей системы или приложения с точки зрения пользователя от начала до конца (от “end” – начала, до “end” – конца).
Оно включает в себя проверку основных сценариев использования приложения – от взаимодействия пользователя с интерфейсом до проверки корректности ответа сервера. Также при E2E тестировании проверяются функциональные возможности приложения, такие как формирование отчетов, работа с базами данных и другие.
Таким образом, E2E тестирование можно рассматривать и как функциональное и как интеграционное.
Регрессионное тестирование (Regression testing)
Регрессионное тестирование проводится после внесения изменений в приложение и позволяет убедиться в том, что уже существующая функциональность продукта продолжает работать корректно после изменений.
Регрессионное тестирование и функциональное тестирование имеют схожие, но все же разные цели и задачи.
Функциональное тестирование проверяет, что приложение соответствует требованиям, которые описаны в функциональных спецификациях.
Регрессионное тестирование проверяет, что изменения в приложении не повлияли на уже существующую функциональность и не вызвали регрессию (возврат к более ранней стадии разработки).
Пример. Онлайн-магазин, в котором можно выбирать товары, добавлять их в корзину и оформлять заказы. После выпуска новой версии нужно убедиться, что функциональные возможности, которые работали в предыдущей версии, продолжают работать корректно в новой версии. Для этого проводится регрессионное тестирование.
Функции которые нужно проверить:
Для каждой из этих функций нужны тесты, которые будут проверять правильность работы приложения в новой версии. Успешное прохождение тестов подтвердит, что приложение работает корректно и что пользователи не будут сталкиваться с проблемами при использовании сайта.
Кто пишет тесты: регрессионные тесты обычно пишутся командой QA-инженеров.
Нагрузочное тестирование (Load testing)
Нагрузочное тестирование проводится для определения максимальной нагрузки, которую может выдержать приложение. В процессе проверяется производительность приложения и выявляются возможные проблемы в работе при большой нагрузке.
Пример. Необходимо убедиться, что онлайн-магазин продолжает работать корректно, когда к нему обращается большое количество пользователей.
Для нагрузочного тестирования создается тест-сценарий, который имитирует действия пользователя на сайте, например:
Тест-сценарий запускается под разной нагрузкой, например, с одновременным выполнением скрипта на 100, 500 и 1000 пользователей. Анализ результатов тестирования помогает определить, как много пользователей приложение может обрабатывать одновременно, не замедляя работу и не выходя из строя.
Кто пишет тесты: нагрузочные тесты обычно пишутся командой QA-инженеров.
Тестирование на производительность (Performance testing)
Тестирование на производительность проверяет производительность продукта при различных нагрузках и условиях использования. Цель – убедиться в том, что продукт может обрабатывать большое количество запросов сохраняя скорость и стабильность.
Отличие между тестированием на производительность и нагрузочным тестированием заключается в целях тестирования.
Цель тестирования на производительность – проверить, как быстро работает приложение и с какой скоростью обрабатывает определенный объем данных. Например проверяется скорость открытия страницы, время загрузки данных и т.д.
Нагрузочное тестирование, проверяет как много пользователей может использовать приложение одновременно без существенного замедления работы или падения производительности.
Пример. Как пример теста на производительность используем пример нагрузочного тестирования. Те же условия, тот же тест-сценарий, но главное отличие будет в фокусе тестирования, т.е. в том, на какие показатели будут смотреть тестировщики.
Тестирование на производительность и тестирование на нагрузку могут быть взаимосвязаны и часто проводятся вместе.
Кто пишет тесты: тестирование на производительность обычно пишет команда QA-инженеров.
Автоматизированное тестирование (Automated testing)
Автоматизированное тестирование – это способ проведения тестирования. Пример интеграционного тестирования, описанный выше, можно выполнить вручную, без использования специальных инструментов, а можно автоматизировать. Для автоматизации используются специальные инструменты и программы.
Автотесты имеют ряд преимуществ перед ручным тестированием, например:
Пример: примером может быть любой из приведенных выше, если это тестирование было автоматизировано.
Кто пишет тесты: Автоматизированные тесты обычно пишутся командой QA-инженеров.
Заключение
В видах тестирования легко запутаться. Во-первых их часто пишут одни и те же люди, во-вторых, у них могут совпадать инструменты, и наконец, даже сами тесты могут быть полностью идентичными. Чтобы понять, какой вид тестирования перед вами, важно выявить какие цели оно преследует.
Я постарался описать не все виды тестирования, а те, с которыми, на мой взгляд, чаще всего сталкиваются начинающие разработчики. Если вам интересно углубиться в тему, вот неполный список других видов тестирования:
СписокТестирование безопасности (Security Testing)Тестирование доступности (Accessibility Testing)Тестирование совместимости (Compatibility Testing)Тестирование локализации (Localization Testing)Тестирование отказоустойчивости (Fault Tolerance Testing)Тестирование масштабируемости (Scalability Testing)Тестирование надежности (Reliability Testing)
В преддверии старта специализации Fullstack Developer от OTUS хочу порекомендовать вам несколько бесплатных уроков, которые будут полезны начинающим fullstack-разработчикам.