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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

Автор: Кастури Раджаманикам(Kasturi Rajamanikkam)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Автор: Гуськова Мария (работает в стриминговом сервисе, ведет свой телеграмм канал @mashaqasha и на досуге пишет статьи на Хабре), https://t.me/mashaqasha

Привет! Я — Маша, которая заваривает qaшу (и иногда крепкий кофе, когда глаза уже отказываются фокусироваться на экране).

Сегодня хочу поговорить о проблеме, с которой сталкивался, наверное, каждый тестировщик (и не только). В один «прекрасный» день ты садишься проверять фичу или делать регресс, а баги просто перестают быть видны. Ты кликаешь, прогоняешь сценарии, но будто слепнешь — всё кажется рабочим. А потом оказывается, что пропустил очевидный косяк, и по цепочке начинается: чувство вины → стресс → ещё большая усталость → ещё больше ошибок.

Знакомо? Тогда давайте разберёмся, как выбраться из этой ямы, пока она не превратилась в профессиональное выгорание.

Автор: Джеймс Уэдли (James Wadley)
Оригинал статьи
Перевод: Ольга Алифанова

Ловкость рук и никакого обмана: что такое Гейзенбаг?

Сталкивались ли вы с дефектом, который, казалось бы, отрицает логику и увиливает от всех попыток его воспроизвести?

Если ваш ответ «Да», то уверяю, вы не одиноки.

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

Из-за этого такие проблемы часто называют «невоспроизводимыми дефектами» или, как я недавно узнал, «Гейзенбагами». Одна из основных характеристик Гейзенбагов заключается в том, что любая попытка понаблюдать за ним или подебажить может потенциально изменить поведение кода приложения. Вы просто хотите понаблюдать за проблемой – и непреднамеренно меняете условия ее воспроизведения. Мы об этом еще поговорим.