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

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

Автор: Гаурав Синх (Gaurav Singh)
Оригинал статьи
Перевод: Ольга Алифанова

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

Шутки в сторону – эта роль была впервые популяризирована крупными техническими компаниями вроде Microsoft и Amazon, и сейчас ее часто можно встретить в описаниях вакансий по всему миру.

Автор: Антон Синькин

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

Дисклеймер

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

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

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

У менеджеров, разработчиков и даже тестировщиков часто появляются нуждающиеся в ответе вопросы о тестировании:

• Почему мы не нашли этот баг до релиза?
• Почему мы не предотвращаем проблемы вместо того, чтобы тестировать?
• Тестирование улучшилось бы при использовании практики Х – прямо как у компании Y!

Автор статьи: Глеб Саркисов (Gleb Sarkisov)
Оригинал статьи

Всем привет, меня зовут Глеб! Я — Head of QA в Mayflower. В последние несколько лет мне стали интересны метрики QA — особенно такие, которые позволяют искать проблемы в процессах, вести переговоры с бизнесом, показывать пользу тестирования для проекта и использовать показатели в качестве KPI.

За время работы в различных компаниях я видел разные подходы для решения этих задач и среди множества метрик я сконцентрировался на defect density. В результате ее изучения, я кастомизировал ее и запилил свою dd “со звездочкой”. Если вы тоже находитесь в поиске метрики, учитывающей чистоту релизов, их объем и скорость, вам может быть полезна моя статья.

По классике, метрика defect density — это доля дефектов, приходящаяся на отдельный модуль в течение итерации или релиза; считается на тысячу строк кода. Идея метрики заключается в том, чтобы определить отношение дефектов в вашем коде к его объему и постепенно уменьшать его. Идея, надо признать, отличная, но нюансы внедрения метрики могут сделать ее достаточно неудобной для использования.

1. Если ваш проект написан на нескольких языках, имеет много модулей, отдельных сервисов, механизм подсчета этой метрики будет непросто прикрутить.
2. Интерпретация значений может быть затруднена: для кого-то соотносить баги и количество строк может показаться неудобным, нелогичным и неприменимым, например, при тестировании “на стороне”, когда к коду вообще может не быть доступа, а данные о его качестве хочется получать.

Хочется взять самое лучшее от этой метрики, модифицировав ее для удобства и большей информативности. Если оттолкнуться от идеи, добавить производительность команды, критичность разных дефектов, то можно посчитать defect density ”со звездочкой” — отношение дефектов различных приоритетов на продакшне к фактической пользе, которую донесла команда за спринт. Так можно учесть сразу и чистоту тестирования внутри спринта, и скорость доставки через доставленный объем задач и багфиксов. Такой показатель можно понятно объяснять бизнесу и на него можно подвязываться как на качество релизного процесса — как на уровне отдельной команды, так и на уровне всего продукта.

Автор: Грегори Пачига (Gregory Paciga)
Оригинал статьи
Перевод: Ольга Алифанова

Сегодня я поучаствовал в онлайн-дискуссии о тестировании, где спросили что-то вроде "А каково соотношение автоматизированного и исследовательского тестирования в вашей компании?"

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

Статья компании SimbirSoft

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

Экономия затрагивает самые разные сферы проекта и специалистов. В этой статье рассмотрим обеспечение качества (QA). Бизнес нередко считает, что тестирование – та часть проекта, на которой можно сэкономить, что за качество должны отвечать разработчики, а QA-специалистов иногда можно и не привлекать. Наш коллега Андрей на конкретных примерах покажет, к каким последствиям приводят наиболее популярные случаи экономии на QA.

Автор: Катарина Дурдевич (Katarina Durdevic)
Оригинал статьи
Перевод: Ольга Алифанова

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