Многие считают, что главное в QA — это проверка интерфейса. Но настоящая магия происходит под капотом, то есть в базе данных. Именно там хранятся логины, заказы, сообщения, фотографии, пароли, адреса доставки и многое другое. Если там все сломается, то интерфейс будет уже не так важен. Сейчас разберемся, как проходит тестирование базы данных (или просто БД).

Что такое база данных простыми словами

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

Как устроена база данных и где она используется

Представьте себе Excel-таблицу. Только не одну, а десятки или сотни. И каждая из них — про что-то свое: пользователи, товары, заказы, платежи. База данных — это как Excel, только умнее, быстрее и со способностью работать с миллионами строк данных одновременно.

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

Так работает почти каждое современное приложение.

Базы данных используются в:

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

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

Как это связано с тестированием

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

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

Даже если на экране все выглядит отлично, в базе может быть полный бардак: дубли, ошибки, «висящие» записи. И задача тестировщика это найти.

Зачем вообще тестировать базу данных

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

Что может пойти не так, если провести тесты базы данных

Если не проверить, как сработала база, можно пропустить серьезные баги. Например, данные могут записаться с ошибкой или не сохраниться вообще. Может быть и такое, что запись попала не в ту таблицу либо пользователь видит чужие данные (а это уже серьезная уязвимость).

Какие ошибки может обнаружить в тестировщик

• Пользователь оформил заказ, а в таблице заказов — пусто.
• В корзине отображается товар, которого уже нет в наличии.
• После обновления приложения исчезли все отзывы к товарам.
• Один и тот же пользователь зарегистрировался дважды, и оба раза данные попали в базу.

Все эти ошибки связаны с тем, как база данных обрабатывает информацию. И все они — в зоне ответственности тестировщика.

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

Почему это важная часть работы тестировщика

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

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

Кто может тестировать базу данных

Тестировать базу данных можно без опыта программирования. Не нужно уметь писать сложный код или разбираться в архитектуре серверов. Достаточно понимать, как хранятся и передаются данные, и уметь задавать простой логичный вопрос: «Что должно произойти с информацией после этого действия?»

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

Если вы работали с Excel — вы уже близки к базовому пониманию структуры базы данных. А простые SQL-команды, которые позволяют делать запросы к данным, можно освоить за пару дней.

Как тестируют базы данных

Допустим, пользователь заполнил форму на сайте — зарегистрировался, оформил заказ или изменил данные в профиле. Задача тестировщика — проверить, что информация действительно сохранилась в базе и все записалось правильно. Пример тестирования БД:

1. Проверяем, появились ли новые данные

После действия пользователя тестировщик отправляет SQL-запрос к базе и смотрит, появилась ли нужная запись в таблице. Например, была ли создана новая строка с данными о заказе или пользователе.

2. Сравниваем значения с тем, что ввел пользователь

Важно убедиться, что все поля заполнены корректно: имя, номер телефона, email и т. д. Если где-то ошибка или значение пустое — это уже баг.

3. Проверяем изменения данных

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

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

SQL и база данных изнутри: минимум теории для тестировщика

SQL (читается как «эс-кью-эл» или «сиквел») — это язык, с помощью которого мы разговариваем с базой данных. На нем можно задавать вопросы: какие заказы есть в системе? кто зарегистрировался сегодня? сколько товаров осталось на складе?

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

Самые простые команды: SELECT, WHERE, INSERT

SELECT — вытаскивает данные из таблицы. Например: SELECT * FROM users;
Этот запрос покажет все строки из таблицы пользователей.

WHERE — используется в связке с SELECT, UPDATE и DELETE, чтобы отфильтровать данные. Например: SELECT * FROM users WHERE email = ‘test@test.com‘;
Так мы получим только того пользователя, у которого такой email.

INSERT — добавляет новую строку в таблицу. Например: INSERT INTO users (name, email) VALUES (‘Ольга’, ‘olga@test.com’);

Есть и другие команды, например, UPDATE (обновить данные) или DELETE (удалить строку). Но для начала достаточно уметь вытаскивать информацию и проверять, что она записалась правильно.

Примеры использования оператора DELETE — скриншот из программы базового курса «основы тестирования»

Как тестировщик использует SQL на практике

В повседневной работе SQL помогает увидеть, что происходит в базе данных:

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

Иногда можно и нужно использовать SQL напрямую — в DBeaver, DataGrip или другом инструменте. Иногда — опосредованно, при тестировании API или запуске автотестов.

Что такое ACID и зачем это знать тестировщику

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

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

Для тестировщика ACID — это ориентир при тестировании БД: если что-то из этих принципов нарушается, значит, в системе может быть серьезный баг.

Где можно практиковаться

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

1. SQL-песочницы (тренажеры)

Такие сайты позволяют писать SQL-запросы и сразу видеть результат.

• SQLZoo — интерактивный тренажер с задачами по SQL. Пишете запросы прямо в браузере, задания идут от простого к сложному. Есть подсказки. Хорошо подойдет для первых шагов.
• SQL Teaching — учите SQL через короткие объяснения и сразу применяете на практике. Минималистичный интерфейс, удобно для новичков.
• W3Schools — популярный учебник с разделом Try-it-Yourself: можно читать теорию и сразу выполнять запросы. Подходит для самостоятельного обучения в комфортном темпе. 

2. Визуальные клиенты для работы с БД

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

3. На обучении тестированию

На курсе «Основы тестирования» вы получите основные знания для старта работы в QA, в том числе научитесь использовать SQL, даже если раньше никогда его не видели. Вы поймете, как связаны интерфейс, база и логика системы.

Тестирование БД кажется чем-то сложным только на первый взгляд. Но когда вы начинаете работать этим на практике — все становится понятнее.

Часто задаваемые вопросы

Нужно ли знание SQL на старте?

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

Сложно ли это для гуманитариев?

Вообще нет. Здесь больше логики, чем математики. Если вам нравится разбираться в причинах, анализировать и искать закономерности — вам будет комфортно. Многие наши выпускники пришли в тестирование из совершенно других сфер и отлично освоили базу данных.

Реально ли найти работу, если вы умеете тестировать БД?

Да, и это даже преимущество. Не все новички умеют работать с базами, потому что боятся. А если вы уверенно используете SQL и понимаете, как устроены данные — вы сразу выделяетесь. Это показывает, что вы глубже понимаете систему и готовы к реальной работе.

Записаться на курс

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

Что такое дефект (баг) и почему его важно устранять

Жизненный цикл дефекта (bug life cycle) — это путь, который проходит баг с момента, когда его заметили, и до полного устранения. Если тестировщик не умеет правильно фиксировать дефекты, они могут затеряться, не дойти до разработчика или остаться нерешенными. Это может привести к проблемам с продуктом, недовольству пользователей и финансовым потерям компании.

Дефект, баг, ошибка — в чем разница?

Часто эти термины используют как синонимы, но между ними есть небольшие различия.

• Ошибка (error) — это действие, которое привело к некорректной работе программы на этапе разработки.
• Дефект (defect, fault) — это отклонение программы от требований, которое обнаружили на этапе тестирования. Если код содержит ошибку и из-за нее программа ведет себя не так, как ожидалось, то это дефект.
• Баг (bug) — это фактически то же самое, что и дефект, но более популярное в IT-среде название.

Другими словами, ошибка разработчика приводит к появлению дефекта, а тестировщик находит этот дефект и заводит его как баг в баг-трекере.

Научитесь тестировать ПО и находить баги в системе. Приходите на курс по основам тестирования и войдите в профессию QA с нуля.

Помощь с трудоустройством

С нуля

Хит продаж

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

Подробнее про курс

Помощь с трудоустройством

Автоматизация тестирования

Подробнее про курс

Зачем фиксировать и отслеживать дефекты?

Представьте, что тестировщик нашел баг, но просто сообщил о нем разработчику устно. Что может пойти не так? Да все что угодно.

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

Нормально оформленный баг-репорт в баг-трекере решает эти проблемы: он четко описывает проблему, фиксируется в системе и передается в работу.

Как дефекты влияют на продукт, бизнес и пользователей?

Дефекты в QA — это не просто небольшие ошибки в коде, а реальные проблемы, которые могут наделать беды в ПО и, как следствие, в бизнесе.

• Ухудшают пользовательский опыт. Например, если кнопка «Купить» на сайте не работает, пользователь не сможет оформить заказ.
• Наносят финансовый урон. Представьте баг в интернет-банке, который приводит к неверному списанию средств.
• Накладывают тень на репутацию компании. Ошибки в безопасности или частые сбои могут привести к потере доверия клиентов.

Где и как заводить дефект?

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

Популярные баг-трекеры

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

Jira

Безусловный лидер среди баг-трекеров, особенно в крупных компаниях. Гибкость в настройке рабочих процессов делает ее мощным инструментом, но из-за обилия функций новичкам может быть сложно разобраться. Лицензия платная, что может быть минусом для небольших команд.

Bugzilla

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

Redmine

Чуть больше, чем баг-трекер. Это полноценная система управления проектами, где можно вести задачи, баги и даже учет времени. Гибкий, с возможностью установки плагинов, но требует ручной настройки, а интерфейс не самый интуитивный. Хорош для тех, кто готов немного повозиться с настройками, чтобы ювелирно подстроить систему под себя.

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

Как правильно описать дефект?

Хороший баг-репорт должен содержать следующие пункты.

1. Название — кратко описывает суть проблемы. Например: «Не работает кнопка “Отправить” в форме регистрации».
2. Окружение — версия браузера, операционная система, устройство и другие технические детали.
3. Шаги для воспроизведения — подробное описание действий, которые привели к багу.
4. Ожидаемый результат — как система должна работать в идеале.
5. Фактический результат — что произошло на самом деле.
6. Вложения — скриншоты, видео или логи, которые помогут разработчику понять проблему.

Этапы жизненного цикла дефекта

Как только дефект зафиксирован в баг-трекере, он проходит несколько этапов, пока не будет исправлен и закрыт. Этот процесс называется жизненным циклом дефекта.

Так выглядит жизненный цикл дефекта

Создание: кто и когда заводит баг?

Баг может завести тестировщик, разработчик или аналитик. Но обычно это делает тестировщик во время тестирования нового функционала.

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

Назначение: кто отвечает за исправление?

После создания дефект получает статус Open и назначается на разработчика или тимлида. В этот момент возможны разные сценарии.

• Если баг действительно есть, разработчик берет его в работу.
• Если воспроизвести дефект не удается, он может быть переведен в статус Cannot Reproduce.
• Если баг дублирует уже зарегистрированную проблему, он помечается как Duplicate.
• Если ошибка признана несущественной или связанной с неправильным использованием системы, ее могут закрыть с резолюцией Won’t Fix.

Исправление: что делает разработчик?

Разработчик анализирует дефект, ищет его причину и вносит правки в код. После этого он отправляет исправление на проверку тестировщикам.

Если система настроена правильно, каждый коммит (изменение кода) фиксируется в баг-трекере, и тестировщик может видеть, когда исправление было загружено.

Проверка фикса: тестирование после исправления

Когда разработчик исправил баг, он переводит его в статус Resolved или Ready for Testing. Теперь тестировщик смотрит, на самом ли деле ошибка устранена.

Возможны три исхода.

1. Баг исправлен. Тестировщик закрывает его, присвоив статус Closed.
2. Баг все еще воспроизводится. Тестировщик переоткрывает его (Reopen) и отправляет обратно разработчику.
3. Появился новый баг. Исправление могло привести к появлению другой ошибки, тогда заводится новый баг.

Закрытие: когда баг считается устраненным?

Баг можно закрыть, если:

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

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

Статусы дефекта в баг-трекерах

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

Основные статусы: Open, In Progress, Resolved, Closed

• Open — баг зарегистрирован и ждет обработки.
• In Progress — разработчик работает над исправлением.
• Resolved — баг исправлен и ожидает проверки.
• Closed — баг проверен и закрыт.

Дополнительные статусы: Duplicate, Won’t Fix, Postponed, Cannot Reproduce

• Duplicate — этот баг уже зафиксирован в системе.
• Won’t Fix — исправлять баг не планируется (например, он не критичен).
• Postponed — исправление отложено на будущее.
• Cannot Reproduce — тестировщик или разработчик не смогли воспроизвести баг.

Названия статусов в цикле дефекта не так принципиальны: главное, чтобы все в команде понимали, что они означают. В разных баг-трекерах могут быть свои названия и логика работы статусов. Например, в Jira и Bugzilla можно добавлять кастомные статусы.

Резолюции дефекта и их значение

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

Fixed, Fixed Indirectly, Functions As Designed (FAD)

• Fixed — баг исправлен разработчиком.
• Fixed Indirectly — ошибка исчезла не из-за прямого исправления, а, например, после обновления зависимостей или переписывания части кода.
• Functions As Designed (FAD) — система работает так, как задумано, и найденное поведение не является багом.

Duplicate, Incomplete, Won’t Fix, Cannot Reproduce

• Duplicate — этот баг уже есть в системе, дубликаты закрывают.
• Incomplete — недостаточно данных для анализа, тестировщик не предоставил шаги воспроизведения или детали.
• Won’t Fix — команда решила не исправлять баг (например, он не критичен или устарел).
• Cannot Reproduce — тестировщик или разработчик не смогли воспроизвести баг, и без дополнительных данных его исправление невозможно.

Как правильно оформлять баг-репорты?

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

Читайте подробнее о том, как правильно оформить баг-репорт, пошагово и с примерами.

Основные элементы баг-репорта

Каждый баг-репорт должен содержать следующие пункты.

Название — коротко, но понятно. Вместо «Ошибка в кнопке» лучше написать «Кнопка “Отправить” не работает в Chrome».

Окружение — версия браузера, ОС, устройство (если нужно). Например, Windows 10, Chrome 134.0.6998.88/89.

Шаги воспроизведения — четкий список действий, которые приводят к багу.

1. Открываем страницу регистрации.
2. Вводим данные в форму.
3. Нажимаем «Отправить».
4. Ничего не происходит.

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

Фактический результат — что произошло на самом деле: «Кнопка не реагирует, в консоли ошибки‎».

Приоритет — насколько баг критичен. 

• Blocker — система вообще не работает.
• Critical — важный функционал сломан.
• Major — значительная ошибка, но можно обойти.
• Minor — мелкий дефект, не влияющий на работу.
• Trivial — косметическая проблема, например, опечатка.

Вложения — скриншоты, видео, логи ошибок.

Пример хорошо оформленного баг-репорта

Пример баг-трекера в Jira

Часто задаваемые вопросы

Баг или фича? Как определить?

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

Что делать, если разработчик не хочет исправлять дефект?

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

Какие ошибки чаще всего допускают новички?

Частая проблема — неполные или неточные шаги воспроизведения. Без четкого описания разработчику сложно понять, в чем ошибка. Также новички забывают прикладывать скриншоты, логи и другую информацию, которая помогает разобраться в баге. Еще одна ошибка — неправильная оценка приоритета: не все баги критичны, но и мелкие дефекты могут серьезно повлиять на пользовательский опыт. Наконец, важно проверять, есть ли такой баг в системе, чтобы не создавать дубликаты.

Записаться на курс

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

Что такое баг-репорт?

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

Официальное определение баг-репорта в справочнике ISTQB (международного совета по QA) звучит так:

A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function.

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

Почему баг-репорты так важны? Они:

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

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

Основные виды багов

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

Функциональные баги

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

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

Нефункциональные баги

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

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

Баги совместимости

Эти ошибки появляются, когда приложение работает по-разному в разных средах. Например, сайт корректно отображается в Chrome, но некорректно работает в Firefox: появляются дефекты в верстке или функционале.

Как составить баг-репорт: пошаговое руководство

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

На курсе «‎Основы тестирования» вы научитесь составлять баг-репорты на профессиональном уровне, чтобы говорить на языке, понятном всей команде.

Структура баг-репорта

Четкая и логичная структура позволяет разработчикам не тратить время на уточнения и сразу перейти к устранению проблемы. А для тестировщика это способ доказать свою внимательность и профессионализм.

Headline (Заголовок)

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

И конечно, он не должен содержать эмоциональных оценок или догадок. Например, не «Форма сломана», а «Форма не отправляет данные при нажатии кнопки “Отправить”».

Severity (Критичность)

Укажите, насколько ошибка влияет на работу продукта. Обычно используют следующие общепринятые стадии критичности.

• Critical: блокирует ключевые функции, например, не работает кнопка «Оплатить».
• Major: серьезно влияет на работу бизнес-модели приложения, но не блокирует ее, например, некорректно считается сумма заказа в корзине.
• Average: ошибки средней важности. Они не мешают основным задачам, но заметны в интерфейсе и не только.
• Minor: это незначительные дефекты, так сказать, косметические ошибки (опечатки, дефекты верстки).
• Enhancement: это скорее запросы на улучшение, а не баги. Например, тестировщик может порекомендовать добавить подсказки или изменить анимацию.

Определить критичность важно, чтобы QA-команда и разработчики могли правильно расставить приоритеты в работе над ошибками.

Следом иногда указывают приоритетность (Priority) найденного дефекта. Этот атрибут показывает, насколько срочно нужно исправить дефект.

• High (Высокий). Баг нужно исправить как можно скорее, потому что он серьезно влияет на функционал или пользовательский опыт. Например, ошибка блокирует оформление заказа на сайте.
• Medium (Средний). Дефект желательно устранить поскорее, но он не мешает основным функциям продукта. Например, кнопка работает некорректно, но есть обходной путь.
• Low (Низкий). Баг почти не влияет на работу системы, и его можно исправить позже. Например, опечатка в тексте или некорректное отображение иконки.

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

Description (Описание)

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

Result (Фактический результат)

Здесь указывайте, что произошло в реальности. Например: «После нажатия кнопки “Сохранить” ничего не происходит, данные не сохраняются».

Expected Result (Ожидаемый результат)

Укажите, как приложение должно было себя вести. Например: «После нажатия кнопки “Сохранить” данные должны передаваться на сервер, а пользователь — увидеть сообщение “Настройки сохранены”».

Attachments (Приложения)

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

Советы по созданию качественного баг-репорта

• Будьте конкретными. Не пишите обобщения, например: «Сайт работает плохо». Опишите конкретную проблему.
• Используйте структурированный формат. Разделите баг-репорт на логические части, чтобы его было легче читать.
• Пишите по делу. Избегайте лишних деталей, которые не помогают понять суть ошибки.

Пример баг-репорта в Jira

Jira предлагает готовую структуру для баг-репорта, поэтому ее предпочитают тысячи команд по всему миру. Готовая структура исключает хаос и помогает сразу расставить акценты. В то же время здесь можно кастомизировать баг-репорт под себя: добавить или убрать параметры, которые нужны именно в этом отчете или проекте.

Но главное — это гибкость и интеграции. Jira связывает баги с другими задачами и тест-кейсами, объединяя работу всех команд. Все хранится в одном месте: комментарии, логи и история правок. Это помогает отслеживать жизненный цикл дефекта, да и в целом упрощает коммуникацию между тестировщиками и разработчиками.

Бывают примеры, когда баг репорт делают в Excel. Но на самом деле это редкая практика: совместно работать с таким отчетом очень неудобно.

Шаблон баг-репорта в Jira

Как мы говорили выше, для баг-репорта в Jira есть стандартный шаблон, который включает все ключевые элементы для описания дефекта. Это помогает структурировать информацию и четко описать проблему по понятной и привычной всем схеме.

Заполнение баг-репорта на примере

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

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

Часто встречающиеся ошибки при составлении баг-репортов

Из-за следующих ошибок разработчики могут отправить баг-репорт на уточнение.

• Нечеткое описание. Например: «Не работает форма регистрации». Такое сообщение не дает разработчику никаких подсказок.
• Нет описания шагов воспроизведения. Если разработчик не сможет повторить действия, он не поймет, что именно идет не так.
• Не указано окружение. Указывайте устройства, браузеры и ОС, в которых обнаружены дефекты.
• Несколько багов в одном репорте. Это путает разработчиков. Поэтому один баг=один отчет.

Рекомендации по использованию баг-репортов

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

Как отслеживать статус багов в Jira

У баг-репорта в Джире есть несколько стандартных статусов.

• Open: дефект зарегистрирован, но работа над ним еще не началась.
• In Progress: разработчик приступил к устранению ошибки.
• Resolved: проблема решена, но еще требует проверки со стороны тестировщика.
• Closed: дефект устранен и подтвержден тестировщиком.
• Postponed: устранение бага отложено.
• To Be Reformulated: баг-репорт нужно уточнить или переформулировать.

Каждый баг, помимо статуса, будет иметь свою резолюцию (результат).

• Fixed: проблема исправлена.
• Fixed indirectly: баг исправился сам после внесения других изменений.
• Functions As Designed (FAD): описанное поведение не является багом, оно соответствует требованиям.
• Won’t Fix: проблему невозможно исправить.
• Duplicate: такой баг уже зарегистрирован в системе.
• Incomplete: недостаточно данных для работы с дефектом.
• Cannot Reproduce: ошибка не воспроизводится, поэтому ее нельзя исправить.

Улучшение коммуникации между тестировщиками и разработчиками

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

• Указывайте точные шаги для воспроизведения, а лучше записывайте видео.
• Используйте факты, избегайте эмоций и расплывчатых формулировок. Например, вместо «Кнопка вообще не работает» напишите «Кнопка “Отправить” не реагирует на нажатие в браузере Chrome».
• Используйте понятные названия элементов интерфейса: «кнопка “Войти”» вместо «большая синяя кнопка».

FAQ: Ответы на популярные вопросы о баг-репортах

Что делать, если баг нельзя воспроизвести?

Сначала перепроверьте указанные в репорте шаги: возможно, вы упустили какую-то важную деталь. Затем убедитесь, что используете нужную версию системы, браузера или устройства. Если проблема все равно не воспроизводится, обсудите ее с коллегами — возможно, кто-то из команды сможет повторить баг и дать дополнительные данные. В крайнем случае, вернитесь к автору репорта: попросите уточнить шаги или предоставить больше информации, например, скриншоты, видео или логи.

Как описывать сложные баги?

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

Записаться на бесплатную консультацию

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

Пара слов о нюансах нефункционального тестирования

Глобально выделяют два вида тестирования: функциональное и нефункциональное. Об этом мы говорили в общем гиде по видам тестирования. Также мы собрали отельный гид по функциональным тестам. Прочитайте их, чтобы собрать в голове общую картинку QA-процессов в компаниях. А теперь перейдем к теме этой статьи.

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

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

Обычно сначала проводят функциональное тестирование, а после — нефункциональное. Логика проста: если базовые функции не работают, тестировать производительность или безопасность бессмысленно.

Нефункциональные виды тестирования

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

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

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

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

Тестирование безопасности

• Его проводят, чтобы выявить и устранить уязвимости , особенно это важно на фоне повышенных требований к кибербезопасности. Тестирование безопасности помогает обнаружить слабые места, которые злоумышленники могут использовать во время атак. Цель — предотвратить взломы, утечки данных и другие инциденты.
• Тестирование уязвимостей. Выявляет слабые места, которые потенциально могли бы быть мишенью для атаки.
• Аудит безопасности. Проверяет соответствие системы стандартам безопасности и политике компании — например, при хранении и обработке персональных данных.
• Тестирование на проникновение. Симулирует атаки злоумышленников, чтобы оценить, насколько программа устойчива к взлому.

Тестирование удобства использования

Юзабилити-тестирование нужно, чтобы убедиться, что пользователям будет удобно пользоваться приложением, а его интерфейс будет интуитивно понятным.

В функциональном тестировании тоже проводят юзабилити-тесты. Там тестировщик проверяет, работает ли интерфейс правильно (выполняет ли функции), а в нефункциональном — насколько он удобен для пользователя (как он выполняет функции).

Юзабилити-тестирование. Оценивает, насколько приложение удобно для пользователя. Например, насколько легко найти нужную функцию или заполнить форму.

Тестирование пользовательского интерфейса. Проверяет, как интерфейс отображается на разных устройствах и экранах.

Для старта в QA важно освоить как функциональное, так и нефункциональное тестирование. С ними можно ознакомиться на нашем курсе «Основы тестирования ПО», который подходит для новичков в IT.

Подробнее

Тестирование совместимости

Здесь проверяют, как программа будет работать в разных браузерах и ОС, а также на разных устройствах (телефонах, смарт-часах, ноутбуках и планшетах). Например, как сайт поведет себя при запуске в Chrome, Яндекс.Браузере, Firefox или Safari. Или как приложение работает на разных моделях смартфона, есть ли разница в работе на Android и iOS.

Дополнительные виды нефункционального тестирования

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

Тестирование надежности

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

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

Тестирование масштабируемости

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

Тестирование на соответствие стандартам

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

Тестирование интернационализации и локализации

Нужны для доступности и удобства ПО для людей из разных стран и культур. Актуально для международных компаний.

• Тестирование локализации. Проверяет корректность перевода и адаптации интерфейса под культурные особенности региона.
• Тестирование интернационализации. Оценивает, легко ли ПО адаптировать для использования в других странах и под другие языки.

Тестирование эффективности

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

Как проводить нефункциональное тестирование

Способ проведения тестов примерно такой же, как и везде в QA: сначала планирование, потом выполнение, отчет и передача разработчикам.

Подход к нефункциональному тестированию

Процесс можно разделить на пять этапов.

1. Определение требований. Это могут быть критерии по производительности, безопасности, удобству использования и совместимости. По каждому из них устанавливают свои KPI.
2. Создание тест-плана. Он описывает все планируемые виды тестирования, сроки, ответственных лиц и ожидаемые результаты. Подробнее читайте в нашей статье о том, что такое тест-план и как он может выглядеть.
3. Выбор инструментов и методологий. Например, для тестирования производительности можно использовать Apache JMeter, для безопасности — Burp Suite.
4. Проведение тестирования. Этим может заниматься как целая команда, так и один QA-инженер.
5. Написание отчета. Его пишут по определенному плану, оставляют рекомендации по улучшению ПО и передают разработчикам.

Чек-листы для нефункционального тестирования

Вот что можно проверить в рамках того или иного вида нефункционального тестирования.

Чек-лист тестирования производительности

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

Чек-лист тестирования безопасности

• Выявить уязвимости, такие как SQL-инъекции и XSS-атаки.
• Проанализировать защиту данных при их передаче и хранении.
• Провести тестирование на проникновение и найти узкие места.

Чек-лист юзабилити-тестирования

• Оценить удобство навигации и доступность интерфейса.
• Проанализировать поведение пользователей и их отзывы.
• Протестировать работу интерфейса на разных устройствах и экранах.

Инструменты для нефункционального тестирования

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

Часто задаваемые вопросы о нефункциональном тестировании

• Что такое нефункциональное тестирование?

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

• Почему нефункциональное тестирование так важно?

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

• Какие инструменты используют для нефункционального тестирования?

Это программы, помогающие автоматизировать вещи, которые трудно или невозможно сделать в ручную. Например, они имитируют повышенную нагрузку на ПО. Без них тесты были бы менее эффективными и более трудоемкими. Например, для проверки безопасности используют OWASP ZAP или Burp Suite, а чтобы проверить юзабилити — могут подключить к работе Crazy Egg. Каждый инструмент помогает провести специфические тесты, такие как нагрузочные тесты, поиск уязвимостей, оценку удобства использования и анализ совместимости. Подобный софт для QA помогает выявлять даже скрытые проблемы, о которых могут не догадываться разработчики.

• Как определить требования перед тем, как проводить функциональные тесты?

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

• Какие виды нефункционального тестирования важнее?

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

Заключение

Нефункциональное тестирование, пример которого мы рассмотрели в этой статье, позволяет оценить производительность, безопасность, удобство и совместимость ПО. После такой всесторонней проверкой, в тандеме с функциональным тестированием, ПО будет приносить пользу как пользователям, так и бизнесу, который его заказал.

помощь с трудоустройством

с нуля

хит продаж

QA English Basics

Подробнее про курс

Помощь с трудоустройством

С нуля

Хит продаж

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

Подробнее про курс

Помощь с трудоустройством

Автоматизация тестирования

Подробнее про курс

В этой статье мы разберем ключевые виды функционального тестирования и инструменты, которые сделают вашу работу в QA более эффективной. А если вы только в начале пути, читайте, какие вообще есть виды тестирования и гид по нефункциональному тестированию, а потом возвращайтесь на эту страницу. Итак, поехали.

Основные виды функционального тестирования

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

Модульное тестирование (юнит-тестирование)

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

Инструменты:

• JUnit. Популярный инструмент для проверки Java-приложений, благодаря которому можно создавать и выполнять тесты автоматически.
• NUnit. Фреймворк для тестирования кода на платформе .NET. Он помогает создавать, группировать и анализировать выполненные тесты.
• PyTest. Разработан для тестирования на Python, довольно простой в сравнении с аналогами.

Интеграционное тестирование (Integration Testing)

Фокусируется на проверке взаимодействия между разными модулями программы. Это помогает убедиться, что компоненты не конфликтуют между собой и корректно обмениваются данными. Его часто используют для проверки микросервисной архитектуры, чтобы узнать, как отдельные сервисы взаимодействуют друг с другом через API.

Инструменты:

• Postman. Подходит для тестирования API и интеграций, позволяет создавать и выполнять запросы к API, проверять ответы и анализировать производительность.
• SoapUI. Подходит для тестирования API с открытым исходным кодом, поддерживает протоколы SOAP и REST.
• JUnit. Помимо модульного тестирования, о котором мы говорили выше, подходит и для интеграционного тестирования. Поможет протестировать взаимодействие компонентов Java-приложений.

Системное тестирование (System Testing)

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

Инструменты:

• Selenium. Один из самых популярных инструментов для автоматизации тестирования. Позволяет создавать тесты, которые можно выполнять в различных браузерах и ОС.
• TestRail. Помогает управлять тестами и отслеживать результаты тестирования.
• LoadRunner. Используется для системного тестирования, выдает данные в виде понятного визуала — графиков и диаграмм.

Приемочное тестирование (Acceptance Testing)

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

Инструменты:

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

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

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

Методы функционального тестирования

Ручное тестирование. Включает выполнение тест-кейсов вручную. Тестер может внимательно, своими глазами анализировать поведение системы и выявлять дефекты. Например, проверять пользовательский интерфейс на соответствие требованиям к ПО. При этом важна усидчивость и доля придирчивости (внимание к деталям).

Начните ваш путь в тестировании с обучения в QA Academy

Ручное тестирование — это самый простой способ попасть в QA. С него начинают, чтобы заработать первые деньги как тестировщик. Пройдите курс «‎Основы тестирования», чтобы стартовать в этой профессии и получить возможность трудоустройства.

Подробнее

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

На курсе «‎Автоматизация тестирования» вы узнаете больше о том, как писать скрипты для тестов и потренируетесь выполнять их, как в реальных проектах.

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

Этапы функционального тестирования

Теперь посмотрим, что же входит в функциональное тестирование и какие общие шаги нужно выполнить тестерам.

Подготовка

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

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

Проведение

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

И конечно, в процессе используют баг-трекинговые системы (например, Jira), чтобы зафиксировать обнаруженные дефекты и в будущем отследить их устранение.

Отчет

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

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

Практические примеры функционального тестирования

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

• Игры (геймдев). Можно проверить логику начисления очков и сохранения прогресса. Например, проследить, что геймер получает правильное количество очков за выполнение заданий и что прогресс сохраняется даже после выхода из игры.
• E-commerce. Может понадобиться проверить функцию поиска по товарам и обработку платежей: считается ли заказ оплаченным и переходит ли он на этап сборки и доставки.
• Сайты. Здесь нужно тестировать многое, зависит от функционала сайта. Чаще всего на любом сайте есть форма обратной связи. Важно убедиться, что она корректно передает введенные пользователем данные, а его сообщение или заявка попадают куда нужно и ее видят администраторы сайта.

Автоматизация функционального тестирования

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

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

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

Лучшие инструменты функционального тестирования

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

• Selenium
• JUnit
• TestComplete
• Postman
• QTest
• PyTest 
• SoapUI
• Cucumber
• Ranorex
• Appium
• Robot Framework

Заключение

Функциональное тестирование программного обеспечения — это важнейшая часть QA-процессов в компаниях разных масштабов, от стартапа до корпорации. Оно всегда было и будет необходимо в разработке любых проектов. Ведь ПО всегда предполагает какие-то функции (иначе зачем его создавать).

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

Часто задаваемые вопросы 

• Какие существуют виды тестирования?

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

Ручное функциональное тестирование QA-специалист выполняет вручную, автоматизированное — с помощью скриптов и программирования. Проще всего освоить ручное функциональное тестирование, ведь в нем не нужно уметь программировать. Автоматизированное тестирование сложнее, но за него и платят больше, потому что для него нужно освоить программирование и специальные инструменты.

• Что такое методы тестирования?

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

• Что такое функциональное тестирование с примером?

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

• Как выбрать инструменты для функционального тестирования?

Выбор инструмента зависит от специфики проекта, требований к тестированию и навыков команды. Например, Selenium это практически универсальный инструмент для автоматизации веб-тестирования, PyTest подходит для проверки на Python, JUnit — для Java-приложений.

• Как автоматизировать функциональное тестирование?

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

помощь с трудоустройством

с нуля

хит продаж

QA English Basics

Подробнее про курс

Помощь с трудоустройством

С нуля

Хит продаж

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

Подробнее про курс

Помощь с трудоустройством

Автоматизация тестирования

Подробнее про курс

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

Функциональное и нефункциональное тестирование: виды

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

Функциональное тестирование

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

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

К корзине есть требования: 

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

Далее, следуя тест-плану, вы тестируете эти функции, скорее всего, вручную, то есть без использования автоматизации. В случае обнаружения ошибок, например, неправильного расчета стоимости, вы фиксируете дефект в системе отслеживания багов, в программе Jira.

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

Начните ваш путь в тестировании с обучения в QA Academy

 Освойте «‎Основы тестирования ПО» и научитесь профессионально выполнять функциональное и нефункциональное тестирование.

Подробнее

Нефункциональное тестирование

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

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

• Система должна выдерживать 23 000 пользователей одновременно.
• Время отклика не должно превышать 2 секунд.
• Данные пользователей должны быть защищены от несанкционированного доступа.

Вы используете метод нагрузочного тестирования и инструменты автоматизации, чтобы имитировать заход 23 000 пользователей, и измеряете производительность системы. Также вы выполняете тесты на несанкционированное проникновение (пентесты).

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

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

Функциональные виды тестирования

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

Модульное тестирование

Модульное тестирование (оно же Unit Testing, юнит-тестирование) проверяет отдельные компоненты или модули программы. Это помогает выявлять ошибки на ранней стадии разработки. Например, можно тестировать отдельные функции или методы в коде. Главное убедиться в том, что эта часть кода работает корректно, независимо от других частей программы.

Интеграционное тестирование

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

Сквозное тестирование

Его еще называют End-to-End Testing. Этот вид тестирования программного обеспечения проверяет полную работу системы. Такие тесты помогают убедиться, что все компоненты системы взаимодействуют правильно. Что еще могут проверять при сквозном тестировании: например, весь процесс покупки в интернет-магазине, от добавления товара в корзину до оплаты и подтверждения заказа.

Приемочное тестирование

Оно нужно для проверки соответствия системы бизнес-требованиям. Его проводят на этапе сдачи продукта его заказчику, то есть во время приема готовых работ (отсюда и название). Желательно, чтобы это тестирование проводили конечные пользователи.

Нефункциональные виды тестирования

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

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

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

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

Нагрузочное и стресс-тестирование

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

Тестирование безопасности

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

Тестирование удобства использования

Usability Testing оценивает, насколько ПО удобно и интуитивно понятно для пользователей. В этом виде тестирования есть доля творчества: например, нужно предположить, как может повести себя новый юзер приложения, поймет ли он, куда нажимать и как управлять функциями приложения или игры. 

Тестирование совместимости

Здесь QA-специалисты проверяют, как система себя ведет на разных операционных системах, браузерах и устройствах. Например, корректно ли отображается и работает сайт в Яндекс Браузере, Chrome, Firefox и Safari.

Часто задаваемые вопросы о видах тестирования

• Какие виды пулов тестирования существуют?

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

• Сколько есть видов тестирования?

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

• Какие виды тестирования подходят для мобильного приложения?

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

• Какой из видов тестирования не требует навыков программирования?

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

• Какой вид тестирования чаще всего автоматизируется?

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

• Каким видом тестирования занимается QA-инженер?

Когда говорят, что человек работает QA-инженером, обычно подразумевается, что он так или иначе выполняет все виды тестирования программ, ведь это позволяет более эффективно проверять качество ПО. Также он владеет разными типами тестирования: автоматизированным — для объемных и повторяющихся задач, а ручным — для функциональных тестов, где важно впечатление живого человека.

Заключение

В этой статье мы рассмотрели виды функционального и нефункционального тестирования и немного углубились в то, как они выглядят на практике. Знание этих методологий поможет вам лучше понять процессы обеспечения качества и подготовиться к успешной карьере в QA.

помощь с трудоустройством

с нуля

хит продаж

QA English Basics

Подробнее про курс

Помощь с трудоустройством

С нуля

Хит продаж

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

Подробнее про курс

Помощь с трудоустройством

Автоматизация тестирования

Подробнее про курс