Я плотно работаю с финтехом и ритейлом, а это как раз те сферы, где грядёт подключение к платформе цифрового рубля. Готовиться начал заранее, так как 1 сентября 2026 года тестовый контур уже обязан быть в порядке. Полгода собирал базу, расспрашивал знакомых из финтеха, ходил на вебинары – даже на те, что делали для бухгалтеров. Я даже прочитал документы Банка России. В итоге сложилась нормальная методологическая основа.

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

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

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

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

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

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

Привет, Хабр!

Меня зовут Харитон. Я специализируюсь на функциональном и нефункциональном мануальном тестировании. За время работы над проектами я заметил, что часто при локализации бага начинающие тестировщики игнорируют необходимость проверок на браузерах с разными движками. Хочу обратить внимание стажёров и джунов на эту ошибку и рассказать, почему знать про движки браузеров обязательно. Моя статья будет полезна и, надеюсь, интересна начинающим специалистам. Но, возможно, и более опытные коллеги что-то почерпнут для себя или дополнят в комментариях своими наблюдениями и примерами.

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

Когда на новом проекте менеджер попросила меня провести эстимацию тестирования, я сначала растерялась, ведь это вроде как задача менеджера или старшего тестировщика. А потом вспомнила, что я – единственный тестировщик на проекте.