Роль QA инженера с точки зрения PM USS Nimitz CVN-68

advertisement
QA в мобильных проектах
Роль QA инженера с точки зрения PM
2013
USS Nimitz CVN-68
Он большой
4 года строительство
+ 3 годя отладка
Что у них общего?
Требуется помощь зала….
В обоих случаях хочется
уверенности, что оно не сломается.
В обоих случаях это важно.
В чем разница
• Размер (бюджет, объем в человеко-часах, …)
• Требования (стабильность требований,
детализация, ожидаемая надежность, …)
• Различная структура и размер команды
• Разная индустрия и как следствие разная
культура
• …
Не забываем, что для мобильных приложений
angry birds это довольно большой проект
О чем доклад?
Все мобильные проекты сильно разные, но
так получается, что работа QA инженера от
проекта к проекту меняется мало.
The Plan
– Метрика, для начала чтобы не было скучно.
– «Рецепт успеха» 
– Типичные «грабли»
Метрика для разминки
Метрика «Враг у ворот»
или количество кликов до крэша
рис. «Мишень» 
Чем меньше кликов до бага
тем больше он раздражает
• «У меня ушло 5 минут на то, чтобы найти крэш,
а ведь я не профессионал в QA, почему ваши
тестеры не смогли найти баг?»
• А и правда почему? – Домашнее задание
ДАНО: QA Lead до этого успешно выступавший 5
лет в 7-и не мобильных проектах
ВОПРОС: Почему могло так случиться что
заказчик нашел крэш за 5 минут после того как
мы тестировали это 6 часов.
Пример успешной работы QA
cook book receipt
Роль QA
•
•
•
•
•
Старт на ранней стадии проекта
Уточнение требований
Прямые коммуникации с заказчиком
Закрытие сделанных issues
Составление и поддержание в актуальном
состоянии check list-а
• Сигнал об окончании стабилизации
Менеджмент
требований
Кто может управлять требованиями в мобильных проектах?
• Бизнес аналитик – ха-ха – не смешно
• Тим лид, ему и так есть чем развлечься, не будет
тим лид выяснять требования в деталях, у него дел
полно
• PM – у него еще 2-3 проекта, дай ему бог хотя бы не
путать имена заказчиков
• Кто остался на трубе – QA – тем более что ему надо
верифицировать issues и вообще чтобы заводить
баги он должен понимать что от него хотят.
Check list
- Простой
- По нему можно быстро пройти
- Все действия очевидны
- Q: что делать если не понятно “как перейти к контакту” п.3)
- А: менять дизайн приложения
- Скорость прохождения checklist – ключевой фактор для сходимости на фазе
стабилизации
Прямые коммуникации
с заказчиком
• Коммуникации наиболее эффективны,
когда человек, собрающий требования,
общается напрямую с business owner
• Proxy слои == испорченный телефон
• Язык заказчика must have (Учите
английский)
Пару слов про наш опыт fail-ов в этой
области
Критерий сходимости
при стабилизации
Можно ли по-другому?
• Наверное можно
• Но рецепт простой, логичный и пока осечек
не давал
• У кого есть какие идеи – давайте обсуждать
Типичные грабли
Для чего все это
делается?
• Часто бывает, что мы узнаем, для какого
устройства/версии ОС разрабатывается
приложение только на этапе сдачи.
• Очень важно знать и иметь возможность
протестить для всех платформ, на которых
будет тестить заказчик
история о телефоне с железной кнопкой
“back”
Я не знаю как это в
iPad
• Современные мобильные
платформы так популярны
в том числе и потому, что
они очень простые
• Учите матчасть 
– Где тут версия ОС
– Как посмотреть UUID
– Как поставить приложение
и не снести все остальное
(iTools)
–…
Написание больших
документов
• Проверено в 3-х проектах: документ, на
написание которого QA потратил более 4-х
часов – расстраивает заказчика.
• Вообще, в мобильных проектах в силу
культурных традиций очень не любят
документы. Большие и обстоятельные
документы особенно.
• Любой документ сложнее check list-а и списка
Q&A, уточняющих требования, имеет право на
жизнь, только если это Ваша личная магия,
которую Вы никому не показываете
Pixel perfect
Коллеги специально просили сказать,
не забывайте про Pixel perfect!!!
И не дай вам бог сдавать продукт
японцам
Не пропадайте
надолго
• Заказчик часто меряет производительность QA по
следующим метрикам
1. За сколько минут ему самому удалось найти баг
приложении
2. Сколько багов QA инженер запостил в JIRA
• 5 мин & 1 баг – ПЛОХО
• 2 часа & 20 багов в день - ХОРОШО
Если вы хотите целый день посвятить поиску бага с
нестабильной обработкой больших массивов данных,
согласуйте это заранее
Вопросы
Email: lc@yandex.ru
Skype: denis.tsyplakov
Спасибо
Download