Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
QA создатель Mind Map: QA

1. Новая фича

1.1. Готовы требования в bitbucket

1.1.1. Утверждение QA в bitbucket

1.1.1.1. Готов дизайн - ревью дизайна, написание тест кейсов

1.1.1.1.1. Проверка дизайна

1.1.1.1.2. Написание тест кейсов в рельсе

1.1.1.1.3. Готова версия на платформах

1.1.2. Набросать разделы для тестирования в testrail

2. Точечное тестирование

2.1. При необходимости проверки уязвимых мест

2.2. С целью воспроизведения нетривиального бага

2.3. Нагрузочное тестирование

3. Проверка сервера

3.1. Свежая версия льется сразу на стейдж и тим.тм и тестируется всей командой проекта

3.2. Профилактическая проверка сервера (раз в n спринтов)

3.3. Проверка серверной части по запросу команды бекенда или продукта

3.4. Проверка тасок со статусом резолв должна проводиться регулярно

4. Emergency

5. Вопросы и уточнения от дизайна

5.1. Создать таск в To-dos в общем ноушене и списком написать вопросы. По результату ребята отпишутся там же комментами.

5.2. Для быстрого и точного ответа лучше прикреплять скрины с проблемными местами и ссылки на экраны в zeplin

6. Цикл жизни бага

7. Работа с багрепортами

7.1. Осуществляется дежурным по emergency

7.1.1. Сбор репортов на проде и тим.тм (чат "Bug reports")

7.1.1.1. Репорты от разработчиков

7.1.1.1.1. Проставить лейбл "bug-report" в таске

7.1.1.1.2. Проставить лейбл раздела бага https://product.oktos.io/11/component/structure.html#

7.1.1.1.3. В дискрипшне указать дату репорта и имя зарепортевшего, текст сообщения

7.1.1.1.4. При необходимости прикрепить скрины и логи

7.1.1.1.5. Проверка и подтверждение воспроизведения. Указать в дискрипшне удалось/не удалось

7.1.1.2. Репорты с помощью формы zapier

7.1.1.2.1. Проставить лейбл "bug-report" в таске

7.1.1.2.2. Проставить лейбл раздела бага https://product.oktos.io/11/component/structure.html#

7.1.1.2.3. Проверка и подтверждение воспроизведения. Указать в дискрипшне

8. Триаж багов

8.1. Проверка багов на свежайшей версии на предмет актуальности

8.2. Уточнение приоритетов и закрытие неактуального

9. Написание тест кейсов

9.1. Разделы и наброски тест кейсов после утверждения требований

9.1.1. Тест кейсы по готовому дизайну

9.1.1.1. В разделах указать ссылки на дизайн и название экранов в дизайне

9.1.1.2. Положительные проверки

9.1.1.3. Отрицательные проверки

9.1.1.4. Рекомендации разработчиков и корнер кейсы

9.1.1.5. Проставление приоритетов

9.1.1.6. Ревью команды

10. Отчет в багрепорт

10.1. Отписать в чате по шаблону из трех пунктов

10.1.1. Количество багов

10.1.2. Ссылка на фильтр с багрепортами за последнюю неделю в жире

10.1.3. Скрин списка для просмотра превью в чате

11. Дополнения тест кейсов

11.1. После изменения функционала разработчики должны указать ключевые детали. В соответствии с этим QA изменяет\дополняет тест кейсы

11.2. В ходе приемок и точечных проверок выявляются корнер кейсы. Нужно дополнять тест кейсы и поддерживать приоритеты актуальными

12. Ведение статистики крашей приложения