Home

Опубликован выпуск рассылки за декабрь-январь.

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

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Большинство тестировщиков программного обеспечения знает, как проводить граничных значений: например, зная, что текстовое поле должно принимать не более 20 символов, тестировщик проверит ввод 19 символов, 20 символов и 21 символа, а возможно, даже 100 символов. Но я часто сталкивалась с ситуациями, когда тестировщик не проводил тестирование границ, если в критериях приёмки не было явно указано ограничение. Это опасно!

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

Оригинальная публикация

Меня зовут Екатерина Кияшева, и я занимаюсь оптимизацией тестирования. Хорошее тестирование начинается с продуманного тест-дизайна. QA важно выстроить проверки так, чтобы тесты действительно были полезными. В этой статье расскажу, как промпт-инжиниринг помогает улучшать качество тест-дизайна, и поделюсь неожиданным открытием об ИИ, вдохновившем на заголовок. Тем, кто хочет сразу к промпту, жать сюда.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Обычно, когда я изучаю что-то новое, например язык программирования или новый инструмент автоматизации, мне нравится проходить полный курс. Курсы структурированы для логичного, постепенного обучения. Но иногда, когда я хочу выучить что-то быстро, я использую то, что называю «Методом удаления кода». Не знаю, делает ли так кто-то ещё, но мне хотелось бы думать, что название придумано мной!

Метод удаления кода предполагает работу с проектом, написанным кем-то другим, с целью его понимания путём постепенного удаления строк кода, пока не останется только базовая функциональность. Вот как это работает:

Оригинальная публикация

За 8+ лет работы в тестировании я сталкивалась с разными подходами ведения базы знаний для тестировщиков на проектах. Где-то на проектах статей в базе знаний было так много, что глаза разбегались от количества информации, которую нужно было изучить на входе в проект. Но чаще попадались проекты, где базу знаний вели редкими набросками или не вели совсем. И это вызывало чувство безысходности в первые месяцы работы на проекте, так как информацию приходилось собирать буквально по крупинкам и не один месяц.

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

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

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

К сожалению, у нас не всегда есть чёткий язык для описания измеряемого. Возможно, вы слышали, как менеджер говорил о достижении «100% тест-покрытия». Но что именно он имеет в виду под этим утверждением? Вот несколько вариантов, что это может означать, и один вариант, чего это значить ни в коем случае не может.

Привет! Я Максим Кузьмин, старший инженер по автоматизации в команде Т-Путешествий. Строю и развиваю процессы автоматизации и разрабатываю инструменты тестирования.

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

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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