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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем привет! Меня зовут Николай, я ведущий инженер по производительности в Т-Банке, более 15 лет работаю с различными утилитами НТ для нагрузочного тестирования. Мы с командой выстраиваем процессы проведения тестов производительности.

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

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

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

В динамическом мире разработки ПО очень важна способность эффективно масштабировать и оптимизировать процессы. Работая над улучшением инфраструктуры нашей автоматизации в Glassbox, мы пришли к применению возможностей DevOps, Groovy, скриптов DSL и AWS EC2 Jenkins-агентов. Эта комбинация позволила создать масштабируемую и устойчивую систему, способную на запуск более чем 1000 задач в день, что дает нам высокую производительность и надежность.