Home

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

Рамиль Аминов — технический директор в SmartHead

Говоря о качестве, обычно имеют ввиду некое соответствие требованиям. Часто под требованиями подразумевают те, что явно выдвинул заказчик, аналитик или кто-то другой, кто ставит задачи. Хуже, если они трактуются как неоспариваемые, и это неявно ведёт к самоцели — удовлетворить требования заказчика. Это часто происходит в аутсорсе, и такой фокус внимания негативно влияет на конечный результат — то, что видят и с чем работают пользователи.

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

Качество — это про «сделать классно» с точки зрения многих сторон: разработки, заказчика и конечного пользователя.

Как это сделать? Сложно. Начать стоит с формирования mindset на «встроенное» качество. Расскажу о принципах, которые могут помочь в этом.

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно мне задали вот такой вопрос (я его перефразировал для ясности):

Хорошая ли практика – одновременно использовать несколько тест-фреймворков? К примеру, я работаю над Python-проектом. Я хочу применять BDD c behave для фича-тестирования, но pytest лучше подойдет для юнит-тестирования. Можно ли использовать и то, и другое? Если можно, как мне структурировать мой проект?

Краткий ответ: да, нужно использовать фреймворки, наилучшим образом подходящие под конкретные цели. Обычно применение нескольких фреймворков несложно настроить. Разберемся подробнее.

Автор: Ольга Назина (Киселёва)

Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинации условий из ТЗ.

Чем проще и понятнее требования, тем меньше будет разночтений. И тем меньше исправлений после реализации. И тем проще нам, тестировщикам, писать тест-кейсы по таким требованиям ))

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

Автор: Виталий Котов

Опубликован выпуск рассылки за первую половину апреля.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Автор: Алан Ричардсон (Alan Richardson)
Оригинал статьи
Перевод: Ольга Алифанова

Краткое содержание: вариация – полезная тактика для тестирования. Зачастую это случайная вариация внутри класса эквивалентности. Варьировать можно также и при исследовательском тестировании. Подумайте над варьированием порядка, данных, состояний, времени.

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

Автор: Яковлев Станислав — Team Lead команды тестирования сервиса Юла, телеграмм канал t.me/qa_chillout

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

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

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

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

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