Home

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

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

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

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

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

Меня зовут Георгий Костуров, я лид фронта в одной из команд СберМаркета. Хочу рассказать про виды тестов и рассмотреть несколько подходов к тестированию. В основном здесь примеры из 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% полагает, что это пустая трата времени.

В чем разница между завершением и прекращением тестирования? Как выбрать стратегию тестирования и верно рассчитать трудозатраты? Своими мыслями о разных подходах к управлению тестированием поделится Александр Александров, эксперт по управлению качеством ПО, управлению тестированием, анализу и совершенствованию инженерных процессов Luxoft, кандидат физико-математических наук.

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

Если вас просят фокусироваться на тест-кейсах и тест-инструментарии, помните: тест-кейсы не находят баги. Баг находит тестировщик, а тест-кейс может сыграть роль в нахождении бага (спасибо Прадипу Сундарараджану за четкую формулировку).

Схожим образом автоматизированные проверки тоже багов не находят. Баг находит тестировщик, а проверка может сыграть роль в поиске бага.

Тест-инструмент не находит багов. Это делает тестировщик, а инструмент может сыграть роль в нахождении бага.