Home

Меня зовут Александр Пронин, я занимаюсь тестированием более пяти лет, последние полгода из которых — в QIWI, проект ContactPay. Мы делаем платежную систему для международного рынка, она состоит из микросервисов, которые написаны на Python и живут в Google Cloud. Проект существует на рынке более двух лет, на данный момент среди наших клиентов уже есть компании-единороги. 

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

Так что в этом посте мы рассмотрим изменения процессов тестирования и доставки новых фич, проделанные нами за полгода, с точки зрения того, как в ContactPay это было раньше, что изменили и к каким результатам это привело.

Заходит тестировщик в бар, а бармен ему говорит: сегодня не работаем, у меня инвентаризация просроченного пива.

Всем привет! Меня зовут Алиса, я — ведущий тестировщик в компании Constanta, и сегодня расскажу вам о простых QA метриках, помогающих отслеживать качество продукта.

Если мы вобьем в поисковой строке незамысловатое словосочетание “метрики QA”, то увидим, что почти все ссылки ведут на классические метрики: процент покрытия требований кейсами, коэффициент регрессии, скорость работы QA команды и т. д. Если вы их не видели — то можете легко найти. Большинство из них полезны, и некоторые будут использованы в статье, но немного в другом формате. Подобные метрики обычно выглядят как n/m, где n и m — количество какого-либо параметра. Например: количество переоткрытых дефектов, общее количество дефектов и время исправления найденных дефектов. Я же хочу рассказать о чуть более аналитической работе: мы будем смотреть не только сухие цифры, но и делать выводы о том, откуда эти цифры взялись. Ближе к концу статьи я поделюсь некоторыми идеями о том, как решать возникшие проблемы.

Автор: Джоэп Шууркс (Joep Shuurkes)
Оригинал статьи
Перевод: Ольга Алифанова

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

Если не на основе рисков, то на основе чего?

Перевод: Сообщество ProQuality Community, https://t.me/proquality_community

Автор оригинала: Gipil Quddus

Когда мы слышим термин "Quality Gates" (QGS), мы склонны думать о них довольно недальновидно на уровне проекта как об этапах и предпосылках для перехода к следующему этапу реализации проекта. На проектах, особенно на тех, которые работают с использованием любой гибкой методологии, часто можно обнаружить что показатели качества более низкого уровня (например, критерии входа и выхода из теста, а также определение Definition of Done) часто обсуждаются/документируются, но затем упускаются из виду или вообще не используются.

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

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

Автор: Павел Петров

Поговорим о метриках тестирования: какие из них будут наиболее эффективны для внедрения в ваш процесс тестирования, как они снимаются и подсчитываются. На примерах покажу, как этот процесс организован в «Иннотех».

Для чего нужно снимать метрики

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

Автор: Костуров Георгий, СберМаркет

Меня зовут Георгий Костуров, я лид фронта в одной из команд СберМаркета. Хочу рассказать про виды тестов и рассмотреть несколько подходов к тестированию. В основном здесь примеры из frontend, но идеи подойдут и для backend. В статье нет конкретных примеров кода (хотя присутствуют ссылки на материалы, где они есть), но изложены идеи и общие правила написания тестов.

Автор: Иван Чечиков, QA-инженер в МТС Digital, проект WASD.TV.

Всем привет! Меня зовут Иван Чечиков, я QA-инженер в МТС Digital, работаю над проектом WASD.TV. В этой статье я моделирую стратегию тестирования для Agile/Scrum-проекта. Она может быть полезна небольшим командам, работающим по такой методологии. Стратегия проста, но не универсальна, вы можете дополнить ее на свое усмотрение.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Но как добиться того, чтобы за качество отвечала вся команда? Один из способов – это создание стратегии качества. Стратегия качества – это документ, с которым согласна вся команда. Это контракт, описывающий, как будет разрабатываться, тестироваться и выпускаться качественное ПО. В этой статье я обсужу ряд вопросов, на которые нужно дать ответы, создавая стратегию качества.

Автор: Максим Бугров, начальник отдела тестирования Департамента разработки клиентских систем и сервисов, Московская биржа

Для организации разработки и тестирования сегодня принято выстраивать пирамиду тестов, это считается мейнстримом. Существуют десятки, если не сотни, вариаций пирамиды, опубликовано много докладов и статей о том, как она должна выглядеть. И почти все эти материалы помогут ответить на вопрос «Как мне построить пирамиду тестирования в новом проекте?».

Но что делать, если вы приходите в проект, в котором исторически применялся подход «мороженки» тестирования, когда основную часть проверок закрывали ручным тестированием? При этом компания проходит трансформацию, и от вас ждут, что вы приведёте процессы в соответствие современным практикам и ускорите их?

Меня зовут Максим Бугров, я больше 8 лет работаю в тестировании ПО. На Московскую биржу я пришел летом 2021 года на позицию начальника отдела тестирования. Наш департамент преимущественно разрабатывает софт, который связывает клиентов и торгово-клиринговые системы Биржи. И я расскажу, как мы начали превращать мороженку в пирамиду — нас ждал огромный ледник задач.

Автор: Владислав Тарасенко

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

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

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