Автор: Блейк Норриш (Blake Norrish)
Оригинал статьи: Tea-Time With Testers, #03/2021
Перевод: Ольга Алифанова

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

Автор: Филип Фрейр (Filipe Freire)
Оригинал статьи: Tea-Time With Testers, #03/2021
Перевод: Ольга Алифанова

Никто не разделяет мою любовь к этой бессмысленной тест-библиотеке, но я сделаю ее обязательной для всех.

Среднестатистический инженер-тестировщик

Проблема

Сравнение инструментов (или фреймворков) тестирования и реальный выбор инструмента могут быть болезненным и чересчур сложным делом для современной технической организации:

• Этот процесс страдает от множества длительных и утомительных споров о рисках между «узкоспециализированными» защитниками различных инструментов, никогда не пользовавшимися инструментами-конкурентами.
• В некоторых случаях крайне легко поддаться на сладкие речи нечестных продавцов тест-инструментария.
• Легко впасть в такой антипаттерн, как «медовый месяц»: первичное впечатление/период адаптации не обнаруживает глубинных проблем, которые выходят на поверхность только при длительном использовании.
• И, наконец, инструменты сильно зависят от своего контекста – скажем, степенью знакомства с ним, правил и стандартов на уровне команды, организации и отрасли, расширений и плагинов, и т. п. А это значит, что «один инструмент, чтобы всех отыскать, воедино собрать и единою черною волей сковать», просто не существует.

Это зачастую верно вне зависимости от области применения инструмента – UI, API, нагрузка и производительность…

Перевод: ProQuality Community, телеграмм-канал
Автор оригинала: Sona Gamaryan

Сегодня специалистам по тестированию и менеджменту необходимо достичь оптимального баланса между скоростью и качеством при поставке программного обеспечения для современного бизнеса. Если вы стремитесь пересмотреть процесс обеспечения качества с целью ускорить выпуск продукта и внедрить непрерывное тестирование (Continuous Testing), то эта статья для вас.

Привет! В этом посте мы хотим рассказать о том, как мы в МКБ построили тестирование. 

Про наши процессы, путь новичка, технологии, планы и про то, почему скрам-команду на самом деле можно собрать не из 8-10, а из 20-40 человек — под катом.

Автор: Копцова Екатерина, руководитель служб тестирования в Яндексе
Оригинальная публикация

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

Зрелым командам такие метрики ощутимо помогают:

• замечать периоды низкого перформанса команды и нехватку ресурсов;

• следить за такими показателями, как общая забагованность сервиса, время реагирования на различные события, количество задач, которые одновременно может обрабатывать команда, и за другими важными моментами;

• сравнивать показатели работы команд в подразделении перед предстоящим периодом ревью.

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

Автор: Маарет Пюхяярви (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Мухаммад Саад написал на LinkedIn про интересный сценарий. Приведу его курсивом и прокомментирую.

Представьте, что вы первый день как вышли работать тестировщиком. Вам показывают приложение, которое нужно протестировать. Это ERP-приложение, содержащее сотни форм и тысячи отчетов. Вы начинаете исследовательское тестирование, открывая форму, в которой около 50 разных полей.

Автор: Дарина Майорова, телеграмм

Привет! Меня зовут Дарина Майорова, я работаю в тестировании в Яндексе, и хочу рассказать, как в Яндекс Афише я за полгода вырастила команду саппорта тестирования.

Весной 2021 года у нас была проблема: в Афише было две команды разработки (Афиша и виджет продажи билетов; далее для простоты я буду часто объединять их в одно понятие Афиша), и был недобор тестировщиков . Мы столкнулись с большой нагрузкой, отсутствием времени на ведение документации, и тестирование выступало в роли “бутылочного горлышка” в командах. А в случае ухода хотя бы одного тестировщика в отпуск (или увольнения) — мы рисковали получить еще больший завал.

Какие решения можно было тут придумать? Желательно — дающие быстрый результат (найм и онбординг нового сотрудника — это не быстро).

Автор: Юлия Поттингер (Julia Pottinger)
Оригинал статьи
Перевод: Ольга Алифанова

Автоматизация тестирования все шире внедряется в компаниях для решения проблем и сокращения сроков вывода продукта на рынок. Однако усилия по внедрению автоматизации не должны быть бессистемными и должны окупать затраты на нее – команде нужно совместно проработать стратегию тест-автоматизации.

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

В январе 2022 мы подводили командные итоги 2021 и обнаружили, что у нас довольно много приемочных багов при тестировании новых фич. Мириться с этим было нельзя, и за дело принялся знающий человек — наш тимлид. Он собрал команду и поставил задачу: снизить количество приемочных багов до минимально возможного значения, желательно разика в три. Это был челлендж, который казался невыполнимым. Но сдюжили! Расскажу, как мы всего добились и почему это хорошо.