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

Там, где есть разработчики, рядом должны быть и тестировщики. И чем сложнее система, тем важнее роль последних. Но не все тестировщики выполняют одну и ту же функцию одинаково, и сегодня мы хотим рассказать о появлении особого подразделения в М.Видео-Эльдорадо, которое занимается кросс-системным тестированием. О том, почему мы решили создать отдельную касту тестеров, каким образом это помогло бизнесу и как мы пришли к такому решению, читайте под катом.

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

Методология agile вносит свои правила в процесс тестирования ПО, и каждая команда самостоятельно разрабатывает, проверяет и деплоит свои сервисы. Однако в сложных системах, когда для поддержки бизнес-процесса необходима слаженная работа десятков сервисов, возникает потребность в дополнительном уровне тестирования. Поэтому мы в «М.Видео — Эльдорадо» создали специальный отдел кросс-системного тестирования. О том, как он формировался, чем занимаются кросс-системные тестировщики и каким образом организованы процессы тестирования, читайте здесь.

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

Автор статьи: Юлия Колесникова, Mobile QA в компании Vivid Money, телеграм канал — t.me/vivid_tech

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

Меня зовут Юля, и я Mobile QA в компании Vivid Money.

В тестировании уже давно — столько всего интересного видела. ​ Но как показывает практика, проблемы и заботы у всех одинаковые. Разница только в анализе, подходах и реализации решений.

В этой статье я расскажу, КАК ОБЛЕГЧИТЬ ЖИЗНЬ ТЕСТИРОВЩИКУ ВО ВРЕМЯ РЕГРЕССА!

Расскажу по порядку:

1. Наши процессы (для полноты картины)

2. Основную проблему

3. Анализ

4. Методы решения, с полученными результатами

Автор: Джоэл Монтвелиски (Joel Montvelisky)
Оригинал статьи
Перевод: Ольга Алифанова

Не удваиваете ли вы усилия без нужды?

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

Но ЗАЧЕМ?

Когда я спросил тест-сообщество о причинах, то получил вот такие ответы:

Автор: Хьюиб Шутц (Huib Schoots)
Оригинал статьи
Перевод: Ольга Алифанова

Первая версия этой статьи была опубликована на LinkedIn 5 февраля 2020 с заголовком "Нужны ли нам тестировщики? Нет! Нужно ли нам грамотное тестирование? Да!" В эту статью я добавил дополнительные умозаключения.

На прошлой неделе я делал доклад на конференции Agile, Testing & DevOps Showcase в Амстердаме. Темой доклада было "Современное тестирование".

Девиз Agile и особенно DevOps-подходов – "автоматизируй все!" Компании вроде Facebook заявляют, что у них вообще нет тестировщиков. У Microsoft есть только SDET (инженер по разработке ПО в тестировании), другие команды перепрофилируют разработчиков, чтобы тестировали они. Новичок на районе – искусственный интеллект и машинное обучение, и, по слухам, они уж точно заменят тестировщиков. Что же действительно происходит в мире?

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

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

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

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

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

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

Автор: Иан Динвуди (IanDinwoodie)
Оригинал статьи
Перевод: Ольга Алифанова

Что я сделал не так и как это исправить? Именно это хочет знать пользователь, сталкивающийся с сообщением об ошибке в ходе использования ПО. Сообщения об ошибке – форма прямой коммуникации с конечным пользователем, которую зачастую недооценивают. Они играют важную определяющую роль в пользовательском опыте. Исследователи пользовательского опыта команды MozillaFirefox выяснили, что "после замены сообщения об ошибке на новый вариант количество пользователей, заявляющих, что воспользуется другим браузером, снижается на 29-60%" (Walkington, 2019). Другими словами, сообщения об ошибках могут сильно влиять на удовлетворенность и удержание пользователей. Гайдлайны сообщений об ошибках, как правило, зависят от отрасли и сценариев использования. В этой статье я обрисовал основные цели, чтобы читатели могли поразмышлять о качестве сообщений об ошибках в своем контексте.

Или как получить неочевидные последствия, если отказаться от команды тестирования.
Автор: Евгений Иванченко

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

Полтора года назад мы разрушили команду тестирования: отказались от регресса, передали E2E автотесты на Selenium в поддержку разработчикам и разошлись по командам, которые пилят фичи, чтобы предотвращать ошибки «в зародыше». В розовых мечтах нам казалось, что так будет больше пользы: QA работают над качеством, тестирование начинается рано, а разработчики пишут автотесты сами и никто им не мешает.



Но не фартануло получилось не совсем так. Розовые мечты окрасились дополнительными оттенками: никто не думает о качестве, автотесты всё хуже, а у разработчиков без команды QA (внезапно) стало больше работы. Так проявились последствия второго порядка, к которым мы не были готовы. Сейчас мы их исправляем и можем рассказать, что это за последствия, как они возникают, какой урон наносят и как попробовать их предугадать, чтобы не было так больно.

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

Каждый проект уникален и у каждой команды свои запросы. Однако всех нас объединяет желание работать с качественными инструментами, которые экономят время и позволяют QA-специалистам тестировать качественнее и быстрее, в идеале чтобы TMS могла в автотесты.

Мы вновь проанализировали проверенные временем и новые системы управления тестированием, которые сейчас популярны на рынке. Выбрали функции, которые должны быть в Test Management System нашей мечты, сравнили возможности продуктов и изучили отзывы пользователей. Делимся списком инструментов, один из которых точно подойдёт вашей команде.

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