Home

Автор: Джоэп Шууркс (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 тестирование, но всегда ли нужен такой подход?

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Тестировщики часто задают мне два вопроса:

Как мне продемонстрировать ценность тестирования менеджменту?

Как получить больше времени на тестирование?

Начнем со второго вопроса. Чувствуете ли вы себя очумевшим от объема продукта, который вам надо покрыть, в сравнении с выделенным на это временем? Беспокоитесь ли вы, что вам не хватит времени на поиск значимых проблем?

Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я наткнулся на твит Бена Доуэна (известного как Full Snack Tester, основателя сайта Tester Of The Day). В твите был опрос:

Как вы относитесь к тест-планам?

- необходимы всегда (21,3%)

- опциональны, но полезны (50%)

- пустая трата времени (15,7%)

- просто покажите мне результаты опроса (13%)

Как правило, я не обращаю внимания на неформальные опросы в Твиттере, потому что выборка там невелика, и результаты не заслуживают доверия. Однако этот опрос меня слегка удивил. Из более чем сотни проголосовавших 70% считает тест-планы важными или полезными, и всего 15% полагает, что это пустая трата времени.