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

Продолжаем тему эпических багов. В прошлый разЧитать полностью »
Сразу сделаю чистосердечное признание: я ручной тестировщик. Я не умею писать код с закрытыми глазами, и да — эту статью мне тоже помог структурировать ИИ по моим промптам.
Зато я умею декомпозировать задачи, выстраивать логику продукта и ломать то, что уже написано.
Меня бесила ситуация, когда я не могу подобрать себе фильм для просмотра. Обычно, у фильмов только скудное описание и рейтинг. Чтобы посмотреть трейлер нужно умудриться его найти. Да, можно прочитать отзывы, но там в основном рецензии на пару минут чтения
Современный frontend давно перестал быть страницей, которую можно объяснить через DOM, сетевые запросы и консоль браузера. Значительная часть поведения интерфейса рождается уже после загрузки: внутри состояния приложения, реактивных зависимостей, цепочек computed-логики, store, runtime-обновлений и внутренних связей между компонентами. При этом основной QA-инструментарий во многих сценариях остаётся почти тем же, каким был в эпоху, когда большая часть логики ещё находилась снаружи.
Network показывает транспорт.
DOM показывает результат.
Console показывает ошибки.
Почему требований нет (и это нормально).
Думаю, каждому читателю‑тестировщику знакома картина, когда ты приходишь на работу, завариваешь кофе, садишься за Jira, а там на тест упала задача, в которой из контекста только название. Причем что‑то вроде «Улучшить авторизацию».
Требования очень редко полностью попадают под характеристики:
полные
измеримые
прослеживаемые
тестируемые и тд
Привет! Меня зовут Александр и я Flutter-разработчик. В этой статье хочу рассказать о том как я подружил ИИ-агентов с интеграционными тестами Flutter, какой инструмент пришлось для этого написать и что вообще из этого вышло. Летс гоу.
Представьте, что вы попросили агента написать для вас интеграционный тест. На моих проектах очень часто это выглядело следующим образом:
Агент изучает код
Пишет тест
Запускает flutter test
Тест не проходит
Агент пытается понять в чем дело, делает фикс
Переходит к пункту 3
Статья рассказывает о внедрении автоматизированных тестов для CROSSOUT.
В статье описан процесс создания тестового окружения и обоснован выбор инструментов, которые позволили нам справиться с требованиями проекта.
Сегодня я расскажу о нашем опыте создания и внедрения автоматизированных тестов в разработку Crossout.
Если вдруг кто-то вдруг еще не поиграл, вот пара слов о ней. Crossout - многопользовательская онлайн-игра в жанре постапокалиптического экшена.

В подразделении, где я работаю, есть традиция - новичку при онбординге вручается ссылка на WikiЧитать полностью »

Всем привет! Меня зовут Алексей Караванов, я руководитель отдела тестирования программного обеспечения Читать полностью »
Привет! Я QA-инженер с 5+ годами опыта. За последний год прошёл около 15 собеседований в крупные продуктовые компании. Заметил закономерность: кандидаты отлично пишут автотесты, но сыпятся на тест-дизайне. Хочу разобрать пять техник, которые спрашивают чаще всего, — с реальными примерами задач.
Суть: делим входные данные на группы (классы), в которых поведение системы одинаково. Из каждого класса берём одно значение — этого достаточно.
Задача с собеседования:
Информация из этой статьи явно пригодится вам, если вы планируете или уже участвуете в соревнованиях, олимпиадах из перечня РСОШ или ВСОШ по предмету информатика (программирование).
Я расскажу о самых популярных и удобных способах тестирования, которые должен знать каждый, а также дам пару практических советов о том, что делать, когда вердикт вашего решения WA (wrong answer) или TL (time limit).
Основная идея – сравнение ответов, которые выдает ваше решение и медленная реализация, в то время как входные данные подбираются случайным образом.
Такой способ используется, когда: