Привет! Меня зовут Катя, и я работаю тестировщиком мобильных приложений более пяти лет. Последние три года я тружусь в iOS-команде Badoo, и еженедельно мы релизим от трёх до семи новых фич, от трёх до пяти технических тасков и от пяти до 13 багфиксов. Как вы понимаете, приложение меняется с такой скоростью, что поддерживать классическую тестовую документацию (test cases) неэффективно: почти всегда она будет устаревшей.
Опытным путём мы выяснили, что чек-листы в качестве тестовой документации работают лучше, так как их проще создавать и использовать. Тем не менее иногда они могут быть запутанными и слишком подробными, особенно когда есть буквально пара часов на exploratory testing фичи, которая должна попасть в следующий релиз.
В этом случае визуализация позволяет сэкономить кучу времени, поэтому мы решили попробовать использовать mind maps (или «ментальные карты»), которые так же удобны в использовании, как чек-листы, но более наглядны за счёт визуального формата.
Сегодня мы подробненько разберём созданную мной mind map для тестирования iOS-приложения (далее именуемую «моя прелесть»), а также пройдёмся по ресурсам, которые можно использовать при построении mind map для мобильного приложения, чтобы покрыть максимальное количество важных сценариев.
Из чего составить mind map
Давайте разберём структуру «моей прелести».
Как видно ниже, все идеи для тестирования разделены на десять основных категорий, каждая из которых имеет множество веток:
Функциональность
Эта категория — самая объёмная. Здесь важно убедиться, что ваша фича / продукт работает как следует. В эту категорию я отнесла следующие проверки:
Интерфейс пользователя
Категория «Интерфейс пользователя» крайне важна, ведь от того, как пользователь взаимодействует с приложением, зависят его лояльность и успех продукта. Здесь предлагаю проверить следующие пункты:
Навигация
Представьте, что вам пришло пуш-уведомление «Вы понравились нескольким людям». Открываете его — и застреваете на страничке «Мы обновили политику конфиденциальности», которую никак нельзя закрыть. Вы пробуете и так, и этак — любопытно же, кому вы там понравились, — но тщетно, подлый экран не пропадает. Во избежание подобных случаев необходимо тестировать навигацию:
Платежи
Перефразируя классика, скажу: «Тестируйте платежи так, как будто ваш личный заработок зависит от этого».
Статистика
В суровую эпоху А/B-тестов решение, была ли фича успешной, принимает команда data science. Поэтому очень важно, чтобы статистика, которую вы присылаете, была достоверной.
Сеть
Тестируя мобильное приложение в уютном офисе с хорошим Wi-Fi, важно помнить, что люди могут захотеть пользоваться приложением в лифте, общественном транспорте и других местах, где качество сигнала может быть хуже. И любое приложение должно адекватно реагировать на смену сети. Предлагаю проверить следующее:
Автоматизация
Если у вас есть автотесты, пользуйтесь ими (спасибо, Кэп).
Кросс-платформенные проверки
Если фича, которую вы тестируете, например, в iOS-приложении, уже реализована на другой платформе (скажем, Android), то обязательно убедитесь, что поведение консистентно. И не упускайте возможность избежать тех багов, с которыми столкнулись тестировщики другой платформы.
Коммуникация
Здесь рекомендую уточнить требования и убедиться, что продуктом / фичей довольны все заинтересованные стороны.
Загадочная категория «Другое»
В готовом виде «моя прелесть» выглядит следующим образом:
Более читабельный PDF-вариант можно найти по этой ссылке.
Где искать вдохновение и как визуализировать
Если такая mind map подходит для тестирования вашего приложения, забирайте. А для создания кастомной ментальной карты я бы посоветовала сделать несколько простых шагов:
1. Начните с центра — задайте идею, это может быть название как фичи, так и целого проекта.
2. Найдите как можно больше идей, относящихся к проекту:
- Самостоятельный мозговой штурм. Постарайтесь записать все идеи тестирования, которые приходят вам в голову. На этой стадии они могут быть большими или маленькими, использовать различные методологии тестирования, относиться к разным типам тестирования, а главное — основываться на вашем личном опыте и быть важными с вашей точки зрения.
- Привлеките коллег. Попросите коллег помочь с идеями, потому что одна голова хорошо, а две — лучше! Все QA-инженеры разные: кто-то более техничен, кто-то более придирчив к UI; и когда люди, обладающие знаниями в разных областях, обмениваются идеями, они получают полезный опыт и новые знания.
- Интернет. Рекомендую заглянуть на следующие сайты, чтобы дополнить список идей:
— www.ministryoftesting.com, и особенно мне нравится их iOS testing mind map? — ?хороший пример базовых идей по тестированию на iOS. MindMap?—?Heuristic Testing Strategy Model содержит множество вопросов, которые будут полезны для успешного end-to-end-тестирования.
— www.testingdiaries.com, я считаю их Mobile Testing Checklist полезным, потому что важные проверки указаны в форме ожидаемого результата и показывают, как должно выглядеть идеальное мобильное приложение.
— Классические мнемоники по мобильному тестированию: COP FLUNG GUN и LONG FUN CUP (описывают базовые особенности мобильного тестирования и очень схожи по идеям), I SLICED UP FUN — похож на первые два, но более сбалансированный, и SFDPOT, формирующий тестовые идеи в виде вопросов.
— Книги: Hands-On Mobile App Testing: A Guide for Mobile Testers and Anyone Involved in the Mobile App Business — здесь раскрываются инструменты и техническая часть нефункционального тестирования мобильных приложений, а Tap Into Mobile Application Testing даёт хорошую базу для тестирования приложений, объясняя, на что важно обратить внимание и почему.
3. Отфильтруйте идеи. Их будет много, некоторые будут повторяться. Смело выбрасывайте лишнее.
Выберите имя. Далее нужно придумать для идей хорошие названия. Короткие и аккуратные будут выглядеть гораздо лучше, чем длинные и запутанные. К тому же их будет проще найти в дальнейшем.
4. Разделяй и властвуй. После проработки списка необходимо категоризировать ваши идеи с использованием любой классификации, которая покажется вам наиболее верной, например, по области приложения, типам тестирования и т. д. В итоге вы получите список, разделённый на секции.
5. Визуализируйте. Визуализация — один из важнейших аспектов mind map. Схема должна легко и быстро читаться (мы ведь как раз для этого её и создаём, верно?). Существует множество приложений для создания mind map. Я использовала trial-версию https://simplemind.eu, но могу порекомендовать и другие:
https://coggle.it/
http://www.mindmaple.com/
http://blumind.org/
www.text2mindmap.com
http://wisemapping.com/
И ещё немного полезных советов:
- старайтесь создавать один элемент диаграммы для одного теста;
- подуровни выглядят лучше, чем длинные элементы;
- используйте бесплатное приложение, а не trial-версию платного; или сразу выбирайте то, которое вам больше нравится, иначе когда решите поправить диаграмму, придётся платить.
А напоследок я скажу
Mind map — очень годная вещь, которая позволяет быстро и качественно протестировать приложение, а также освежить в памяти проверки, на которые часто не хватает времени.
В моём случае использование mind map увеличило скорость тестирования фич в среднем на 5—15% (по сравнению с чек-листами).
Надеюсь, эта статья вдохновит вас на создание собственного полезного mind map-шедевра. Уверена, вы получите пользу как от создания ментальной карты, так и от использования. Спасибо за внимание!
Есть проверки, которые я не включала в mind map из-за неактуальности для специфики Badoo. А какие специфичные идеи для тестирования вы бы добавили для своего приложения?
Комментарии (25)
raydac
27.07.2018 07:13+1если кто NetBeans IDE или IntelliJ Idea IDE пользуется, то там майнд мапы вообще в проектах держать можно при помощи плагинов, маиндмапами и проекты документировать можно, а не только процессы
Tab10id
27.07.2018 08:05Спасибо! Раньше тоже накидывал план тестирования в "картах", но поддерживать было неудобно. С плагинами все должно быть получше.
grey_kristy
27.07.2018 12:51Как то совершенно не очевидно, чем это лучше чек листов. Тем что оно не линейное, а разбросано по всему листу и разных цветов? Нууу ok.
А галочки там можно ставить, что эта ветка уже протестирована?
katya_sp Автор
27.07.2018 13:23Добрый день! Спасибо за ваш комментарий.
Согласна, проставлять галочки по чеклисту это конечно удобно в пане тестирование регрессии, не покрытой автотестами. Но в этой статье речь идет о тестировании новой фичи, для которой такая схема будет намного более наглядной (на одну такую страницу с mind map умещается чеклист на четыре страницы). Как правило, люди проще воспринимают структурированную и хорошо визуально оформленную информацию. Плюс совершенно не обязательно проставлять галочки. Но если сильно хочется — то такая возможно у вас безусловно будет.
?Взаимодействие с сильно формализованной документацией отнимает много времени.??Дело в том что чеклисты нужно постоянно актуализировать и заполнять. На это нужно тратить ресурсы.
KraT_by
27.07.2018 14:02По сути первые пять веток это HLTC с небольшим спусканием до чек-листов.
Сколько примерно времене ушло на создание такой карты на одну фичу?katya_sp Автор
27.07.2018 14:02Добрый день! Спасибо за ваш комментарий.
Да, структурные элементы данной mind map действительно можно охарактеризовать как high level test cases. Построение такой mind map первый раз заняло несколько часов. Кастомизация под каждую фичу -нужно просто скрывать определенные ветки — занимает меньше минуты.fxaggtest
27.07.2018 16:08+1Когда то я пришел к именно такому выводу: делать mind map вместо бесконечной писанины. Проект у нас большой, документации получилось бы выше крыши, а в тест отделе только я :) Именно майнд мап как метод спасла мне всю работу в тестировании. И как вы правильно заметили — создавать всю долго, а отдельные элементы на раз-два. Пара минут и у тебя готовый кейс и его легче воспринять визуально. Есть еще несколько фишек, с помощью которых можно круто прокачать карту (но это наверное уже не сюда). Так что я вас полностью поддерживаю.
katya_sp Автор
27.07.2018 16:20Да, это удобный таймсейвер, и с програмками которые все сами строят очень приятно работать.
Пожалуйста, поделитесь фишками, которые могут прокачать карту. Уверенна, это будет очень полезно.fxaggtest
27.07.2018 16:49+11. В комментариях к каждой ветке описываю список багов со ссылкой на баг-трекер (в формате номер бага — заголовок).
2. По элементу ветки ставлю прогресс тестирования (спец иконка с заполнением содержимого по клику). Так с лету определяю, на каком этапе процесс.
3. В особо сложных местах ставлю на элементах ветки номера приоритетов для тестирования (1-супер важно,… 4-не важно).
4. Использую перекрестные ссылки на другие ветки (связи одних элементов с другими, если те идут не от родительского) — так проще понять логические связи, если они децентрализованы.
5. Использую смайлы и палец вверх/вниз, чтобы визуально определить, куда направить свое внимание.
6. Ввел для себя термин bpo (bug per option) в виде числа, чтобы охватив взглядом карту я мог понять концентрацию багов в тех или иных местах.
И многое другое :) Это универсальная система, в том числе для учета багов, оценки прогресса тестирования по всем фронтам, оценки концентрации багов, контроля внесенных в ПО изменений и всё такое. наверное такие вещи лучше живьем показывать.katya_sp Автор
27.07.2018 17:29Спасибо за достойный список улучшений. Обязательно постораюсь включить его в свою карту. Идея с BPO звучит очень полезно.
Mimus_spb
27.07.2018 15:20+1как контейнер с информацией MM превосходит обычное отображение «стены текста» примерно как iPhoneX аппарат Белла
к сожалению чаще всего попытки внедрить ММ даже в прогрессивных сообществах встречают синдром автоваза, из серии что мы тут уже 25 годиков работаем, и слава б-гу текстовые странички нас еще ни разу не подводили
хотя, наверное, так или иначе это к всему CIS региону относится
вся надежда на тех кто родился в новом тысячелетииkatya_sp Автор
27.07.2018 15:35Добрый день!
Огромное спасибо за ваш комментарий. Абсолютно полностью согласна.
Да, всегда можно сказать «зачем что-то менять, мы уже так привыкли?». Но здесь как и с любой другой идеей — нужно попробовать, а вдруг заработает и станет намноооого круче? Может стоит рискнуть? Вдруг из автоваза удастся сделать mercedes?
wkhh
27.07.2018 17:19Не думал, что в такой огромной компании, которая еженедельно релизит "… от трёх до семи новых фич..." встречаются фичи, "… которая должна попасть в следующий релиз."
При еженедельном выпуске новых версий правильно ли это, что есть какие-то срочные (и судя по всем очень важные) фичи, на которые есть всего "… пара часов ..." на тестирование?
Иными словами — может лучше не пороть горячку и «засунуть» фичу в следующий релиз вместо того, чтобы впопыхах тестировать её?
anton_tereshko
28.07.2018 07:15+1ну мы же не знаем, как они запускают эти фичи.
Мы например иногда выкладываем такие срочные фичи и тестируем на 1-2х клиентах, если все норм, то раскатываем дальше
katya_sp Автор
28.07.2018 10:57Доброе утро! Спасибо за ваш комментарий.
Дело в том что Badoo — продуктовая компания на очень стремительно развивающемся рынке. Каждая новая фича — это не только возможность принести пользу нашим дорогим пользователям, но и хороший повод заявить о себе. И если бизнес считает, что следующая (практически готовая) фича это прорыв на рынке — то ждать дополнительную неделю означает риск, что конкуренты выпустят что-то подобное раньше.
Да, это повод быть гибкими и срезать углы (выпускать MPV с которым согласен и бизнес и команда). Бизнес просит эстимейшн на тестирование, которого будет достаточно. Но это не повод выкатить продукт в качестве которого мы, тестировщики, не уверенны. Поэтому мы стараемся быть гибкими и максимально эффективно использовать время которое у нас, обеспечивая при этом максимальный уровень качества.
NYMEZIDE
По мне она тратит много времени на то, чтобы придумать, нарисовать в редакторе блок-схему, соединить линиями, выбрать цвет и т.д.
Вот если бы процесс был более менее автоматизированным, была бы интеграция, скажем:
— схема позволяет создать тест и прогнать его
— тест позволяет дополнить схему
или что-то подобное.
z3us
https://heisenbug-piter.ru/talks/2018/spb/6feubdtqqwqocya2w4cwq2/ Тут есть инструмены, которые Вам могут помочь. Видео пока не в общем доступе (есть только слайды), но должны быть доступные где-то в ноябре судя по предыщему опыту
pkuptcov
Видео есть уже давно
z3us
Супер, забыл что первый зал транслировали :)
katya_sp Автор
Добрый вечер! Спасибо за ваш комментарий, интересное мнение.
z3us поделился отличной презентацией об интеграции автоматизации и mind map.
Признаться, по задумке схему нужно нарисовать всего раз. При тестировании новой фичи вам не нужно будет каждый раз пересоздавать mind map. Это не рационально. Как правило одна фича будет затрагивать всего несколько секций. И нужно будет выбрать только актуальные проверки.
По поводу автоматизации, согласна, если фичи на вашем проекте однотипны и вы можете автоматизировать все быстро и по стандартному шаблону — вперед! Можно с помощью?TestRail или любого подобного приложения настроить синхронизацию между схемой и автотестами. Можно даже пойти дальше и трекать тестовое покрытие автотестов по подобной схеме)
Все зависит от вашего проекта. Мне удобно иметь такую карту, с достаточно абстрактными пунктами, потому что каждая новая фича в Badoo не похожа на предыдущую. Если вы способны поставлять тесты сразу с фичей — вы круты! У нас часто руки до автоматизации доходят тогда, когда проект уже продвинулся дальше.
JSas
Уже несколько лет пользуюсь freemind, её карты хранятся как XML файлы и есть встроенная возможность прогнать его через xslt. Используя это я много генерил разных артефактов из одной большой карты по проекту.
Например, ddl инструкции для базы данных по простому списку таблиц и полей.
Либо сводный excel (csv, конечно, но бизнес открывал его в excel и радовался) со статусами открытых вопросов/комментариев.
katya_sp Автор
Спасибо, интересный опыт.
Оказывается mind maps можно использовать не только как удобный способ шарить знания среди тестировщиков, но и как понятный документ для бизнеса (а таких не много, знаете ли)