Автор: Томаш Балог (Tamás Balog)
Оригинал статьи
Перевод: Ольга Алифанова

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

В ходе моей карьеры значительная часть моей тест-автоматизации включала применение какого-либо BDD-фреймворка – например, инструменты вроде Cucumber или JBehave. Как человек, который программирует, я всегда интересовался рефакторингом, сокращающим количество стандартного или дублирующего кода – кода становится меньше, и он становится понятнее. Это включает и сокращение стандартного кода в методах определения шагов и прочем связующем коде. Как их упростить? Или вообще от них избавиться?

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

Только как быть, если в вашей команде уже не 5 человек, а 15, и вручную отслеживать данные стало непросто?

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

Под катом рассказываем, как мы начали (и продолжаем) централизованно мониторить эффективность нашего QA-направления. Поэтапно и с практическими советами. 

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

Автор: Сарит Вакрат (Sarit Vakrat)
Оригинал статьи
Перевод: Ольга Алифанова

Javascript – прекрасный язык программирования: он легок, быстр, и располагает ресурсами для решения практически любых приходящих в голову вопросов. Он профессионально управляется с бэкендом через Node.js. Однако если в вашем javascript-коде попался баг, дебаг может сильно выматывать и раздражать, а иногда это глупые, легко предотвратимые баги.

TypeScript пользуется всеми преимуществами JavaScript и NodeJS и усиливает их – он поможет писать код, который легче читать и проще поддерживать. У него статическая типизация, классы, интерфейсы, типы, декораторы и поддержка IDE в режиме реального времени вроде Visual Studio Code.

Автор: Михаил, специалист по тестированию в компании ITFB Group

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

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

Автор: Ашутош Мишра (Ashutosh Mishra)
Оригинал статьи
Перевод: Ольга Алифанова

Все больше компаний обзаводится собственными мобильными приложениями, и многие экс-веб-тестировщики переходят в мобильное тестирование. Совершая этот переход, тестировщики иногда полностью игнорируют вроде бы мелкие проблемы вроде нестабильного интернета при использовании мобильного приложения пользователями (ниже я буду называть это «путем потребителя»).

Знаете ли вы, как ваше приложение справляется с ошибками или проблемами задержек, вызванными нестабильным соединением с Интернетом?

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

Вы когда‑нибудь оказывались в неловком положении на собеседовании, когда вас спрашивают: «Может, у вас есть к нам вопросы?» Это момент, которому не учат в университетах или на курсах по тестированию, но он может стать критической развилкой на вашем профессиональном пути. Если вы только пробиваете себе дорогу в мире IT и это ваше второе или третье собеседование, то умение задать правильные вопросы может стать вашим личным компасом в определении, находитесь ли вы на пороге мечты или очередной галеры? На просторах Хабра можно найти множество статей на подобные темы, большая их часть сосредоточена на обсуждении таких аспектов, как зарплаты, отпуска, бонусы и так далее.

Меня зовут Влад Бубнов (@vladbubnov), я работаю в VK на позиции QA Engineer. Хочу поделиться своим топом вопросов для собеседования на позицию тестировщика, которые я собрал благодаря прохождению не одного десятка собеседований. Они помогут вам понять, с какой компанией вам предстоит иметь дело.

Автор: Эди Стоукс (Ady Stokes)
Оригинал статьи
Перевод: Ольга Алифанова

Введение

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

Теперь, когда ИИ-инструменты широко распространяются, начинают появляться и инструменты тестирования доступности на основе ИИ.

Как правило, они делятся на три категории:

• Инструменты оценки: подсвечивают все, что кажется им проблемой.
• Инструменты оценки и рекомендаций: подсвечивают найденные проблемы и предлагают способы подхода к ним или их исправления.
• Инструменты оценки и исправления: напрямую применяют исправления к тестируемому коду на основании своих находок.

Эти инструменты, особенно те, которые просто правят все за вас, выглядят прекрасной идеей! Но решат ли они все проблемы? К сожалению, нет. Помогут ли они? Да, в правильных условиях и в разумном масштабе.

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

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

Всем привет! Меня зовут Ксения Лопатина. В предыдущей статье я рассказывала вам о своем подходе к построению карты компетенций для команды тестирования. Там я описала зачем нужна карта компетенций, как можно подойти к ее построению и как провести оценку.

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