Продуктовое тестирование Android приложений. Дмитрий Будько, инженер отдела тестирования и контроля качества PromWad
•Download as PPT, PDF•
0 likes•437 views
Recommended
Recommended
More Related Content
Similar to Продуктовое тестирование Android приложений. Дмитрий Будько, инженер отдела тестирования и контроля качества PromWad
Similar to Продуктовое тестирование Android приложений. Дмитрий Будько, инженер отдела тестирования и контроля качества PromWad (20)
More from Anthony Marchenko
More from Anthony Marchenko (18)
Продуктовое тестирование Android приложений. Дмитрий Будько, инженер отдела тестирования и контроля качества PromWad
- 1. Делаем продукт! Продуктовое тестирование мобильных приложений Дмитрий Будько Promwad 2012 © Promwad Innovation Company
- 2. Потребители должны любить ваш ПРОДУКТ! page 2 2012 © Promwad Innovation Company
- 3. Разработка это ПРОСТО! • Product • Product Owner • Developers • QA • Юзабилити page 3 2012 © Promwad Innovation Company
- 4. Контроль со стороны PO Нехватка времени PO “Интеграция” РО в команду Недостаточная “конкретность” page 4 2012 © Promwad Innovation Company
- 5. Качество ПО не равно качеству продукта page 5 2012 © Promwad Innovation Company
- 6. Продуктовое тестирование. Как? 1. QA инженер – микро PO 2. Анализ решений 3. Тестирование Юзерстори 4. Тестирование на ЦА 5. Проверка качества ПО page 6 2012 © Promwad Innovation Company
- 7. Что в итоге? page 10 2012 © Promwad Innovation Company
- 8. Продуктовое тестирование мобильных приложений PT=QA+UX+вовлеченность+анализ page 11 2012 © Promwad Innovation Company
- 9. Спасибо за внимание Promwad Innovation Moscow office: Company 119296 Russia Moscow, 68/16 Leningradsky Avenue Phone: +7(495)642-82-43 Email: info@promwad.ru Development center in Minsk: 220073 Republic of Belarus Minsk, 22 Olshevskogo Str., office 903 Phone: +375 (17) 312-2-46 Email: info@promwad.com page 12 2012 © Promwad Innovation Company
Editor's Notes
- Привет. Меня зовут Митя. Я расскажу вам о продуктовом тестировании. Этот термин мы сами придумали в Промвад. Так же например, как термин «контрактная разработка электроники», в чем мы сейчас являемся лидерами в СНГ. Мое выступление будет интересно тем людям, которые в результате разработки, хотят получить продукт, а не кусок программного кода. Я расскажу, что мы понимаем под продуктовым тестированием и почему это важно.
- Чтобы двигаться дальше, разберёмся в терминах: Основное отличие продукта от непродукта – продукт любят потребители. Ваше мобильное предложение скачивается миллионами и ему ставятся оценки только 5 и выше Продукт Продукт Оунер Команда Разработки Классическое тестирование Юзабилити Продуктовое тестирование - это формализованный взгляд на ваш продукт глазами пользователя. Это тестирование позволяет выявить проблемы, которые нельзя выявить при регулярном QA . Что это за проблемы?
- Чтобы двигаться дальше, разберёмся в терминах: Основное отличие продукта от непродукта – продукт любят потребители. Ваше мобильное предложение скачивается миллионами и ему ставятся оценки только 5 и выше Продукт Продукт Оунер Команда Разработки Классическое тестирование Юзабилити Продуктовое тестирование - это формализованный взгляд на ваш продукт глазами пользователя. Это тестирование позволяет выявить проблемы, которые нельзя выявить при регулярном QA . Что это за проблемы?
- Продукт оунер взаимодействует с командой разработки и QA и в итоге получает продукт. Это хорошо работает в теории. Что происходит на практике. 1 Поспешный контроль качества продукт оунера. Продукт овнер, поскольку это один человек, не может охватить проект со всех его сторон, увидеть все ньюансы. И зачастую действия продукт овнера по контролю качества происходят следующим образом – приходит заказчик, хватает девайс, делает пару нажатий, говорит – смотри какое говно, отдает и убегает. Фактически – это маленькая часть продуктового тестирования. При таком подходе какие-то дефекты могут быть пропущены, причем наверняка самые очевидные. 2 Продукт овнер может сильно слиться с командой , интегрироваться и начать воспринимать разработку с точки зрения проекта, т.е. команды, а не пользователя, т.е. продукта. В результате получится «дизайн от программистов» и вполне реалистичными начинают выглядеть заявления, что это не баг, а это фича. Например, Выпадающий список с одним элементом . Пользователь нажимает на кнопку – выбрать что-то, а там один вариант. С точки зрения проекта – это верное поведение. С точки зрения пользователя – дефект. 3 Бывают ситуации, когда и тех задание сделано грамотно и реализация его соответствует , но что получается, не является продуктом . Тут может появиться конфликт – продукт оунеор начинает доказывать, что это недостаточно удобно или красиво и вобще не нравиться, но что конкретно и как надо – сказать не могу. У разработчика вопрос – «а где критерий удобства или красоты? Мы считаем, что все отлично, говори нам в пунктах тз, что не соответсвует». Вот эти конкретизированные ощущения предоставит продуктовое тестирование.
- Т.е. фактически ПТ – это один из мускулов продукт овнера, который можно взять в аренду. Итак, что такое ПТ? ПТ – оценка качества продукта, не только программного обеспечения. Причем стоит понимать, что качество ПО – не равно качеству продукта. ПО может быть качественным с точки зрения разработчика, регулярного QA , однако продукт может совершенно не нравиться пользователю и не оправдывать его ожидания. Т.е. ПТ – это некий расширенный вариант регулярного QA , т.к. его в себя включает.
- Итак, какие методы мы используем для достижения результата? Первое, это понятие того, что QA инженер – это микро продукт овнер . Это следует четко понимать, т.к. эти люди вносят вклад в развитие проекта. Мы подбираем правильных людей. Это не человек, который подходит формально, проходит 50 тесткейсов и все, а человек, который участвует непосредственно в развитии продукта, чем снимает с продукт оунера часть обязанностей и делает их более пристально.
- Второе – это погружение . В рамках погружения производится анализ аналогов и конкурентов . Это позволяет не делать предположения, а посмотреть, что уже есть на рынке и чего ожидают пользователи. Инженеры с опытом UI \\ UX могут сразу посмотреть, что хорошо, что плох о, анализируется фидбек пользователей. Удачные практики берутся на вооружение, неудачные – отбрасываются.
- Третье – тестирование на ЦА . Не всегда получается сделать и дорогостояще, например если приложение рассчитано на корпоративного пользователя. Если приложение проще – это сделать вполне реально. Например , приложение, вызывающее такси . Самое лучшее решение – выйти на улицу и вызвать такси. И уверяю вас – вы узнаете много нового. Ну это самый простой пример
- Ну и конечно четвертое – регулярное QA . Его все же никто не отменял и оно входит в тестирование. Это аудит спецификации проекта, разработка тестовой документации (тест план, тестовая спецификация), функциональное тестирование, нагрузочное тестирование, тестирование совместимости (имеется ввиду на различных устройствах и эмуляторах) и т.д. В том числе с применением автоматизации.
- Все проведенные действия дает некое количество сущностей – дефектов, фич и т.п. они заносятся в трекер . Затем проходит фаза их приоритезации . В нашем опыте фаза приоритезации в первые несколько итераций происходит вместе с продакт оунеро м, а затем, когда у нас произошло полное погружение, приоритезацию мы начинаем делать сами. В результате получаем отчет и вывод – является ли то что мы посмотрели коммерчески пригодным проектом, и если нет – что нужно сделать что бы он таким стал. Чем это отличается от юзабилити тестинга . Наши инженеры в конце проведенного тестинга могут ответить на вопрос – какие из функций являются необходимыми, какие нет. Так же сказать, что существуют такие то и такие-то возможности. Конечно, продукт оунер наверняка о них знает, но подтверждение – это несомненно плюс. С помощью ПТ вы получаете больше пользовательского опыта, больше вовлеченности, и больше прозрачности.
- Итого получаем: ПТ = QA + UI \\ UX + вовлеченность + анализ И главный вывод – если у вас все отлично в регулярном QA – это далеко не означает, что у вас классный продукт.