Тестирование ПО: что это, где применяется и как освоить

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

Из каких действий состоит навык

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

Второе — придумать проверки с помощью техник тест-дизайна. Самые полезные для начала — классы эквивалентности (значения, на которые система должна реагировать одинаково, проверяют одним представителем) и граничные значения (ошибки копятся на краях диапазонов: «до 10 000 ₽» ломается на 9 999, 10 000 и 10 001, а не на 5 000).

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

Кому нужен навык и чем он отличается от профессии тестировщика

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

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

У этой роли есть объективное ограничение, о котором прямо пишет программа сертификации ISTQB. В силлабусе Certified Tester Foundation Level v4.0.1 (раздел 1.5.3 «Независимость тестирования») выделены четыре степени независимости. Когда продукт проверяет его автор, независимости нет совсем; коллега из той же команды даёт некоторую независимость; тестировщики другого подразделения — высокую; внешняя организация — очень высокую. Независимый проверяющий находит больше дефектов, потому что его когнитивные искажения отличаются от искажений автора: автор помнит, что имел в виду, и неосознанно обходит неудачные сценарии.

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

Учебный пример: фильтр заказов по датам

Учебная ситуация: аналитик добавил во внутренний отчёт фильтр «Заказы за период». Он выбирает сентябрь, видит правдоподобную сумму и хочет закрыть задачу.

Сначала уточняем ожидаемое поведение: включается ли конечная дата в период, в каком часовом поясе хранятся заказы, что показывать, если дата начала позже даты окончания. Допустим, ответы такие: обе даты включаются, заказы хранятся по UTC, отчёт смотрят в Москве, а перевёрнутый период должен давать понятное сообщение.

Затем подбираем проверки по граничным значениям. Заказ, созданный 30 сентября в 23:59 по Москве, должен попасть в сентябрь. Заказ 1 октября в 00:00 — не должен. Заказ 1 сентября в 01:30 по Москве хранится в базе как 31 августа, 22:30 по UTC, и именно на нём фильтр, написанный без учёта пояса, ошибётся. Добавляем классы эквивалентности: период из одного дня, пустой период без заказов, перевёрнутый период, период длиной в год.

Проверка показывает, что фильтр сравнивает время заказа с полуночью конечной даты по UTC и не переводит время в московское. В итоге он теряет заказы 30 сентября начиная с 03:00 по Москве, а заодно и заказы первых трёх часов 1 сентября. Аналитик описывает дефект одной фразой в заголовке, прикладывает три тестовых заказа с точным временем, ожидаемую и фактическую сумму. После исправления он проходит все проверки заново и дополнительно смотрит соседний отчёт «Заказы по неделям», который использует ту же функцию. На всё уходит около часа.

С чего начать и в каком порядке осваивать

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

1. Возьмите любую форму с правилами (регистрацию, калькулятор доставки на сайте магазина) и выпишите для неё классы эквивалентности и граничные значения, прежде чем что-либо вводить.
2. Превратите список в чек-лист, пройдите его и отметьте, какие проверки что-то нашли, а какие дублировали друг друга.
3. Опишите каждое расхождение в формате «шаги — ожидаемый результат — фактический результат» и попросите знакомого воспроизвести его без ваших пояснений.
4. Освойте инструменты разработчика в браузере (вкладки Network и Console) и простые запросы к API в Postman: так видно, где ошибка — в интерфейсе или на сервере.
5. Научитесь проверять данные SQL-запросом: сравнить то, что показывает интерфейс, с тем, что лежит в таблице.
6. Если вы пишете код, добавьте модульные тесты с теми же граничными значениями, которые до этого проверяли руками.

Если нужен систематический разбор с проверкой заданий, посмотрите программу онлайн-курса Skillbox «Ручное тестирование (Manual QA)»: он рассчитан на четыре месяца, среди адресатов прямо названы специалисты поддержки и аналитики, в программе есть тест-дизайн, тестирование веб-интерфейсов и API, SQL и мобильных приложений, а на курсе предусмотрено семь проектов.

Упражнения и частые ошибки новичков

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

Самая частая ошибка — проверять только «счастливый путь», где пользователь всё делает правильно. Вторая — писать вывод «работает» после одного успешного прогона, не записав, что именно проверено. Третья — описывать дефект оценкой, а не фактом: «фильтр кривой» вместо «при периоде 01.09–30.09 не учитываются заказы 30.09 после 03:00 МСК». Четвёртая — не повторять соседние проверки после исправления и узнавать о новой ошибке от пользователей.

Тем, кто хочет короткий маршрут с большим числом практических заданий, подойдёт курс Eduson Academy «Ручное тестирование ПО + ИИ»: он длится три месяца, охватывает требования и тестовую документацию, веб-приложения, базы данных, API и мобильное тестирование, а в описании указаны 58 практических заданий. Тип выдаваемого документа в обзоре описан противоречиво, поэтому его стоит уточнить у школы.

Как навык тестирования влияет на доход

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

Сопоставимых данных о доплате за навык тестирования мы не нашли, поэтому можно опираться только на общий фон. По отчёту «Хабр Карьеры» за первое полугодие 2026 года, построенному на 45 226 зарплатах из калькулятора сервиса, медианная зарплата IT-специалиста в России составила 191 000 ₽, в регионах — 160 000 ₽; зарплаты тестировщиков за полугодие выросли на 5 %, так же, как у аналитиков. Это фактические зарплаты по анкетам, а не предложения в вакансиях, и надбавку за навык по ним не вычислить.

Чтобы посмотреть актуальные цифры для своей роли, откройте зарплатный калькулятор «Хабр Карьеры» или вакансии на hh.ru, отфильтруйте по региону, специализации и опыту, смотрите медиану, а не среднее, и отличайте суммы «до вычета налога» от сумм «на руки».

Как выбрать обучение

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

Если вы всё же думаете о переходе в тестирование и готовы писать код, обратите внимание на программу Нетологии «Инженер по тестированию»: за восемь месяцев она ведёт от чек-листов, тест-кейсов и отчётов о дефектах через Postman, SQL, Git и Docker к автотестам на Python или Java, а практика собрана в 13 крупных проектов.

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

Для такого сравнения удобен рейтинг онлайн-школ по тестированию и QA: в нём собраны программы от ручного тестирования до автоматизации.

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