Home

Автор: Яковлев Станислав — 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 нашей мечты, сравнили возможности продуктов и изучили отзывы пользователей. Делимся списком инструментов, один из которых точно подойдёт вашей команде.

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

Ирина Соколова,
Senior QA Engineer
qualsolife.ru

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

Одна, дополненная другой, мои статьи получились возможным руководством к действию для тех, кто еще не нашел «свой стиль» и не уверен с чего начать.

Кое-кто отозвался, что я пишу о «прописных истинах», но при этом я получила хороший отклик в комментариях и личных сообщениях из разряда «было полезно», «то, что мне сейчас нужно» и т.п. Но были и вопросы. Вопросы, по большей части, сводились к той «боли», которая не минует ни одного QA за его карьеру:

• как эффективно взаимодействовать с разработчиками?
• как выстраивать работу с ними так, чтобы они приняли: на проекте есть еще одно мнение, мнение QA, и оно тоже важно?
• как побудить их взаимодействовать, например, при построении совместной автоматизации тестирования, когда они не настроены к совместной работе?
• как действовать в том случае, когда твоих технических навыков в стеке используемых технологий просто не хватает?

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

Автор: Всеволод Егоров, QA Engineer, Wrike

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

Четыре из пяти соискателей-QA хотят научиться работать с автотестами. Не все компании могут осуществить такие желания ручных тестировщиков в рабочее время. Wrike провёл школу автоматизации для сотрудников и реализовал это желание для многих. Я в этой школе участвовал именно как ученик-QA.

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

Публикуем доклады с конференции SQA Days 25, посвященные вопросам обучения.

• Buzzword Driven Management – Сергей Атрощенков, EPAM.
• 4 цвета команды - простые основы – Петра Бускова, Tesena s.r.o.
• Грабли вхождения в автоматизацию – Анастасия Заречнева, Noveo (Санкт-Петербург).
• Хиромантия джуна или линии погружения новичка в распределенную команду – Роман Буданов, ООО "Лаборатория Качества" (Буденновск).
• Создание программно-ориентированной программы для тестировщиков – Пол Джеррард, Gerrard Consulting (Мейденхед).
• Взгляд изнутри на курс по тестированию или как самому создать эту машину – Ольга Изюрьева, АО "ПФ "СКБ Контур" (Екатеринбург).

 Записи докладов ниже

Публикуем доклады с конференции SQA Days 25, посвященные тонкостям тест-менеджмента.

• Памятка молодого QA менеджера – Антон Семенченко, COMAQA.by; CoreHard.by; DPI.Solutions; EPAM (Минск).
• Карта компетенций – Андрей Бельских, Playkey (Пермь).
• Подбор инструмента Test Case Management в JIRA – Алексей Вершинский, Унитарное предприятие "Велком" (Минск).
• Тестирование в жизни проекта: непоправимая польза раннего подключения тестировщиков – Галина Вострикова, CorePartners (Воронеж).
• Трансформация процесса найма на этапе скоростного роста команды с 3 до 25 человек за год – Руслан Остропольский, DocDoc (Москва).
• Мексиканские страсти по мидлу. Или как среди юниоров и сеньоров найти золотую середину? – Алексей Петров, FunCorp (Москва).
• OKR и QA - практические советы – Андрей Ладутько, PandaDoc (Минск).
• QA Team: Адвокат или судья? – Владимир Мордовин, Wargaming | Lesta Co Ltd (Санкт-Петербург).

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

Я работаю QA-инженером в Miro. Расскажу о нашем эксперименте по передаче разработчикам части задач по тестированию и трансформации роли тестера в роль QA (Quality assurance).

Сначала коротко о нашем процессе разработки. У нас ежедневные клиентские релизы и от 3 до 5 серверных релизов в неделю. В команде разработки 60+ человек, которые поделены на 10 функциональных scrum-команд.

Я работаю в команде Integration, задача которой — интеграция нашего сервиса во внешние продукты и интеграция внешних продуктов в наш сервис. Например, мы интегрировали таск-трекер Jira. Jira Cards — визуальное отображение задач, с которыми можно удобно работать на доске, не заходя в Jira.