Сомнения перед стартом у всех одни: «а вдруг без программирования никуда», «а вдруг это скучная рутина», «а вдруг через пару лет всё за меня сделает ИИ». Верить на слово тут бесполезно, поэтому каждый миф ниже разобран на одном крошечном примере — форме регистрации с тремя полями: почта, пароль, промокод. Начать придётся с факта, из которого вырастают сразу три мифа: проверить всё невозможно.
Проверить все сочетания нельзя. Ценность тестировщика в том, какие шесть он выберет.
Проверить всё нельзя — и это не отговорка
Три поля, в каждом десяток осмысленных значений: пусто, пробел, короткое, длинное, кириллица, спецсимволы. Это 10 × 10 × 10 — тысяча сочетаний, по минуте на прогон больше двух рабочих дней на одну форму. А форм в продукте сотня, и полный перебор занял бы годы — без учёта браузеров, телефонов и медленного интернета. Отсюда вывод, на котором стоят три мифа ниже: работа тестировщика — выбор, а не перебор.
Миф: тестировщику обязательно уметь программировать
Из-за этого сомнения старт откладывают на год — «сначала выучу Python». А баг находят сценарием: промокод «−100 % на первый заказ» плюс возврат одного товара из двух — скидку сняли со всего заказа, возврат вычли ещё раз, и магазин перевёл покупателю деньги, которых тот не платил. Весь инструмент тут — догадка, что скидку и возврат считают по отдельности, и проход сценария до конца, а не до слова «оплачено».
Вторая половина мифа честная: с открытой панелью разработчика (клавиша F12, DevTools) видно, что страница отправила на сервер amount: -450, а сервер спокойно принял, — значит, проверку суммы забыли с обеих сторон, и так и пишут в баге. Технологии не находят баги вместо головы, а сокращают путь от «что-то не так» до «вот где не так»; поэтому в программе есть основы веба, клиент-сервер и HTTP и SQL — чтение и понимание, а не написание кода, и через год-два оно становится главным ускорителем, в том числе если захочется в автоматизацию.
Миф: тестирование — это просто
Снаружи это «кликай и смотри, что сломалось» — ровно до первой формы, которую надо проверить за час. Можно прогнать сотню сочетаний нормальных данных и не найти ничего, а можно сделать шесть проверок:
- оставить поле пустым — самый частый пропуск на свете;
- пробел вместо значения: для человека пусто, для программы — непустая строка, и проверка «поле заполнено» проходит;
- пароль на границе длины: ровно минимум и минимум минус один символ — ошибку делают на краю, а не в середине;
- почта, которая уже есть в системе;
- та же почта в другом регистре:
Ivan@mail.ruпослеivan@mail.ru— для человека один адрес, для базы два разных; - дважды нажать «Зарегистрироваться», пока страница думает.
Остальные 994 сочетания ничего не добавят: программе всё равно, anna@mail.ru у вас или boris@mail.ru. Внутри одной группы значения ведут себя одинаково, а ломается на краях групп — умение их разглядеть и есть ремесло: эквивалентные классы и граничные значения, техники тест-дизайна.
Миф: тестировщик отвечает за все ошибки в продукте
За качество отвечает вся команда: требования пишет аналитик, код — разработчик, сроки двигает менеджер. Тестировщик отвечает за своё — чтобы команда знала состояние продукта и найденные проблемы до выкладки. А раз проверить всё нельзя, пропущенный баг не халатность, а следствие выбора: эту проверку не сделали, потому что делали другие.
Спрос при этом нормальный: баг уехал в прод (боевую версию, которой пользуются живые люди) — команда спросит «как так вышло». Нормальный разбор устроен не как поиск виноватого: спрашивают, была ли эта проверка в списке, было ли про этот случай хоть что-то в требованиях и хватило ли времени на регресс. Все три вопроса — про процесс, и у каждого есть починка: дописать проверку в чек-лист, спросить аналитика раньше, попросить день на перепроверку. Если вместо этого ищут виноватого, проблема в команде (QA в Agile и Scrum).
Миф: ИИ и автоматизация скоро заменят тестировщиков
Доля правды есть: ИИ пишет черновики тест-кейсов (пошагово записанных проверок) по описанию задачи и помогает сформулировать баг, а повторяющийся регресс во многих командах и правда забрали автотесты.
Границу видно на той же форме. Попросите модель придумать проверки для регистрации — она выдаст правильный адрес, неправильный, короткий пароль, пустые поля: ровно то, что написано в задаче. Чего в списке не будет:
- почта в другом регистре — модель не знает, что в вашем продукте адрес хранится как введён и
Ivan@заводит второй аккаунт кivan@; - двойной клик по кнопке — её не было в команде месяц назад, когда из-за него дублировались заказы;
- письмо подтверждения после смены почты в профиле — уходит на старый адрес, потому что рассылка берёт данные из другой таблицы.
У модели нет контекста: как устроен ваш продукт и что в нём уже ломалось, живёт в голове команды и в истории багов. Профессия не исчезает, но спрос смещается к тем, кто думает проверками и берёт ИИ инструментом.
Упражнение: попросите ИИ придумать проверки для формы регистрации и сверьте список с шестью проверками выше. Обычно он называет две-три и почти никогда — дубль в другом регистре и двойной клик.
Ещё четыре мифа, которые закрываются короче
- «Сплошная рутина». Повторяющееся — регресс — первым отдают в автоматизацию; исследовательское тестирование роботу недоступно: он проверяет только заранее написанное.
- «Без опыта и диплома не возьмут». Диплом не спрашивают — смотрят, воспроизведёте ли вы чужой баг по обрывочному описанию. Опыт добывается этим же: пять настоящих баг-репортов по любому публичному продукту.
- «Главное — внимательность». На пятом прогоне экрана глаз перестаёт замечать очевидное: мозг подставляет картинку из памяти. Поэтому её подпирают конструкцией — чек-лист вместо памяти, записанные шаги, свежий человек на критичном сценарии.
- «Пройду курс за три месяца — и я тестировщик». Программа даёт умение придумывать проверки и описывать баги; знание конкретного продукта, его процессов и инструментов набирается только на месте.
Что реально нужно до старта
Первая задача новичка звучит буднично: «проверь, что правка в корзине ничего не сломала». Надо прочитать её (часть текста на английском), воспроизвести починенное, записать шаги и отличить «не работает» от «работает не так, как я ожидал». Отсюда четыре требования.
- Английский «читаю со словарём». Документация, интерфейсы инструментов и половина программ для учёта багов — на английском; проверка действием: найти в поиске текст любого сообщения об ошибке и прочитать первый ответ.
- Уверенное владение компьютером. Проверка действием: снять скриншот с выделенной кнопкой и открыть продукт в режиме инкогнито — иначе «баг» окажется вашим старым кэшем.
- Базовая логика. «Поле обязательное — значит, пустым его оставить нельзя; проверим, что будет, если всё-таки оставить».
- Упорство. Воспроизвести проблему, которая появляется через раз, — это десяток попыток и запись того, чем они отличались.
HTTP, DevTools, SQL, Postman, Linux до старта не нужны — это фаза «Инструменты и практика» (клиент-сервер и HTTP, API-тестирование, терминал Linux). Учить их до начала — самый распространённый способ не начать никогда.
Как выглядит первый месяц
Требуют меньше, чем вы боитесь: пройти готовый список проверок и записать всё, что разошлось с ожидаемым; превратить жалобу «не работает оплата» в точные шаги; проверить маленькую правку и то, что рядом. И обязательно спросят, что непонятно в задаче: половина проблем находится здесь, ещё до кода. Придумывать проверки с нуля попросят через месяц-два.
Коротко
- Тысяча сочетаний на одной форме — больше двух рабочих дней: работа тестировщика это выбор проверок, а не перебор.
- Ломается на краях: пусто, пробел вместо значения, граница длины, дубль, другой регистр, двойной клик.
- Кода для старта не нужно; технологии — ускоритель от «что-то не так» до «вот где не так», а не входной билет.
- Пропущенный баг разбирают как процесс: была ли проверка в списке, было ли про неё в требованиях, хватило ли времени на регресс.
- ИИ снимает механику и не снимает контекст: он не знает, что в вашем продукте уже ломалось.
- До старта нужны английский со словарём, уверенный компьютер, базовая логика и упорство.
Что почитать дальше
- Техники тест-дизайна — как из тысячи сочетаний получаются те самые шесть проверок.
- Ручное и автоматизированное тестирование — что отдают роботам, а что остаётся человеку.
- Жизненный цикл разработки и тестирования — почему баг дешевле найти рано.
- Куда расти дальше в тестировании — что бывает после первого года.