Comments 32
визуализация позволяет сэкономить кучу времени, поэтому мы решили попробовать использовать mind maps
По мне она тратит много времени на то, чтобы придумать, нарисовать в редакторе блок-схему, соединить линиями, выбрать цвет и т.д.
Вот если бы процесс был более менее автоматизированным, была бы интеграция, скажем:
— схема позволяет создать тест и прогнать его
— тест позволяет дополнить схему
или что-то подобное.
https://heisenbug-piter.ru/talks/2018/spb/6feubdtqqwqocya2w4cwq2/ Тут есть инструмены, которые Вам могут помочь. Видео пока не в общем доступе (есть только слайды), но должны быть доступные где-то в ноябре судя по предыщему опыту
Добрый вечер! Спасибо за ваш комментарий, интересное мнение.
z3us поделился отличной презентацией об интеграции автоматизации и mind map.
Признаться, по задумке схему нужно нарисовать всего раз. При тестировании новой фичи вам не нужно будет каждый раз пересоздавать mind map. Это не рационально. Как правило одна фича будет затрагивать всего несколько секций. И нужно будет выбрать только актуальные проверки.
По поводу автоматизации, согласна, если фичи на вашем проекте однотипны и вы можете автоматизировать все быстро и по стандартному шаблону — вперед! Можно с помощью TestRail или любого подобного приложения настроить синхронизацию между схемой и автотестами. Можно даже пойти дальше и трекать тестовое покрытие автотестов по подобной схеме)
Все зависит от вашего проекта. Мне удобно иметь такую карту, с достаточно абстрактными пунктами, потому что каждая новая фича в Badoo не похожа на предыдущую. Если вы способны поставлять тесты сразу с фичей — вы круты! У нас часто руки до автоматизации доходят тогда, когда проект уже продвинулся дальше.
z3us поделился отличной презентацией об интеграции автоматизации и mind map.
Признаться, по задумке схему нужно нарисовать всего раз. При тестировании новой фичи вам не нужно будет каждый раз пересоздавать mind map. Это не рационально. Как правило одна фича будет затрагивать всего несколько секций. И нужно будет выбрать только актуальные проверки.
По поводу автоматизации, согласна, если фичи на вашем проекте однотипны и вы можете автоматизировать все быстро и по стандартному шаблону — вперед! Можно с помощью TestRail или любого подобного приложения настроить синхронизацию между схемой и автотестами. Можно даже пойти дальше и трекать тестовое покрытие автотестов по подобной схеме)
Все зависит от вашего проекта. Мне удобно иметь такую карту, с достаточно абстрактными пунктами, потому что каждая новая фича в Badoo не похожа на предыдущую. Если вы способны поставлять тесты сразу с фичей — вы круты! У нас часто руки до автоматизации доходят тогда, когда проект уже продвинулся дальше.
Уже несколько лет пользуюсь freemind, её карты хранятся как XML файлы и есть встроенная возможность прогнать его через xslt. Используя это я много генерил разных артефактов из одной большой карты по проекту.
Например, ddl инструкции для базы данных по простому списку таблиц и полей.
Либо сводный excel (csv, конечно, но бизнес открывал его в excel и радовался) со статусами открытых вопросов/комментариев.
View Your Mind — сам часто пользуюсь.
если кто NetBeans IDE или IntelliJ Idea IDE пользуется, то там майнд мапы вообще в проектах держать можно при помощи плагинов, маиндмапами и проекты документировать можно, а не только процессы
Как то совершенно не очевидно, чем это лучше чек листов. Тем что оно не линейное, а разбросано по всему листу и разных цветов? Нууу ok.
А галочки там можно ставить, что эта ветка уже протестирована?
А галочки там можно ставить, что эта ветка уже протестирована?
Добрый день! Спасибо за ваш комментарий.
Согласна, проставлять галочки по чеклисту это конечно удобно в пане тестирование регрессии, не покрытой автотестами. Но в этой статье речь идет о тестировании новой фичи, для которой такая схема будет намного более наглядной (на одну такую страницу с mind map умещается чеклист на четыре страницы). Как правило, люди проще воспринимают структурированную и хорошо визуально оформленную информацию. Плюс совершенно не обязательно проставлять галочки. Но если сильно хочется — то такая возможно у вас безусловно будет.
Взаимодействие с сильно формализованной документацией отнимает много времени. Дело в том что чеклисты нужно постоянно актуализировать и заполнять. На это нужно тратить ресурсы.
Согласна, проставлять галочки по чеклисту это конечно удобно в пане тестирование регрессии, не покрытой автотестами. Но в этой статье речь идет о тестировании новой фичи, для которой такая схема будет намного более наглядной (на одну такую страницу с mind map умещается чеклист на четыре страницы). Как правило, люди проще воспринимают структурированную и хорошо визуально оформленную информацию. Плюс совершенно не обязательно проставлять галочки. Но если сильно хочется — то такая возможно у вас безусловно будет.
Взаимодействие с сильно формализованной документацией отнимает много времени. Дело в том что чеклисты нужно постоянно актуализировать и заполнять. На это нужно тратить ресурсы.
По сути первые пять веток это HLTC с небольшим спусканием до чек-листов.
Сколько примерно времене ушло на создание такой карты на одну фичу?
Сколько примерно времене ушло на создание такой карты на одну фичу?
Добрый день! Спасибо за ваш комментарий.
Да, структурные элементы данной mind map действительно можно охарактеризовать как high level test cases. Построение такой mind map первый раз заняло несколько часов. Кастомизация под каждую фичу -нужно просто скрывать определенные ветки — занимает меньше минуты.
Да, структурные элементы данной mind map действительно можно охарактеризовать как high level test cases. Построение такой mind map первый раз заняло несколько часов. Кастомизация под каждую фичу -нужно просто скрывать определенные ветки — занимает меньше минуты.
Когда то я пришел к именно такому выводу: делать mind map вместо бесконечной писанины. Проект у нас большой, документации получилось бы выше крыши, а в тест отделе только я :) Именно майнд мап как метод спасла мне всю работу в тестировании. И как вы правильно заметили — создавать всю долго, а отдельные элементы на раз-два. Пара минут и у тебя готовый кейс и его легче воспринять визуально. Есть еще несколько фишек, с помощью которых можно круто прокачать карту (но это наверное уже не сюда). Так что я вас полностью поддерживаю.
Да, это удобный таймсейвер, и с програмками которые все сами строят очень приятно работать.
Пожалуйста, поделитесь фишками, которые могут прокачать карту. Уверенна, это будет очень полезно.
Пожалуйста, поделитесь фишками, которые могут прокачать карту. Уверенна, это будет очень полезно.
1. В комментариях к каждой ветке описываю список багов со ссылкой на баг-трекер (в формате номер бага — заголовок).
2. По элементу ветки ставлю прогресс тестирования (спец иконка с заполнением содержимого по клику). Так с лету определяю, на каком этапе процесс.
3. В особо сложных местах ставлю на элементах ветки номера приоритетов для тестирования (1-супер важно,… 4-не важно).
4. Использую перекрестные ссылки на другие ветки (связи одних элементов с другими, если те идут не от родительского) — так проще понять логические связи, если они децентрализованы.
5. Использую смайлы и палец вверх/вниз, чтобы визуально определить, куда направить свое внимание.
6. Ввел для себя термин bpo (bug per option) в виде числа, чтобы охватив взглядом карту я мог понять концентрацию багов в тех или иных местах.
И многое другое :) Это универсальная система, в том числе для учета багов, оценки прогресса тестирования по всем фронтам, оценки концентрации багов, контроля внесенных в ПО изменений и всё такое. наверное такие вещи лучше живьем показывать.
2. По элементу ветки ставлю прогресс тестирования (спец иконка с заполнением содержимого по клику). Так с лету определяю, на каком этапе процесс.
3. В особо сложных местах ставлю на элементах ветки номера приоритетов для тестирования (1-супер важно,… 4-не важно).
4. Использую перекрестные ссылки на другие ветки (связи одних элементов с другими, если те идут не от родительского) — так проще понять логические связи, если они децентрализованы.
5. Использую смайлы и палец вверх/вниз, чтобы визуально определить, куда направить свое внимание.
6. Ввел для себя термин bpo (bug per option) в виде числа, чтобы охватив взглядом карту я мог понять концентрацию багов в тех или иных местах.
И многое другое :) Это универсальная система, в том числе для учета багов, оценки прогресса тестирования по всем фронтам, оценки концентрации багов, контроля внесенных в ПО изменений и всё такое. наверное такие вещи лучше живьем показывать.
как контейнер с информацией MM превосходит обычное отображение «стены текста» примерно как iPhoneX аппарат Белла
к сожалению чаще всего попытки внедрить ММ даже в прогрессивных сообществах встречают синдром автоваза, из серии что мы тут уже 25 годиков работаем, и слава б-гу текстовые странички нас еще ни разу не подводили
хотя, наверное, так или иначе это к всему CIS региону относится
вся надежда на тех кто родился в новом тысячелетии
к сожалению чаще всего попытки внедрить ММ даже в прогрессивных сообществах встречают синдром автоваза, из серии что мы тут уже 25 годиков работаем, и слава б-гу текстовые странички нас еще ни разу не подводили
хотя, наверное, так или иначе это к всему CIS региону относится
вся надежда на тех кто родился в новом тысячелетии
Добрый день!
Огромное спасибо за ваш комментарий. Абсолютно полностью согласна.
Да, всегда можно сказать «зачем что-то менять, мы уже так привыкли?». Но здесь как и с любой другой идеей — нужно попробовать, а вдруг заработает и станет намноооого круче? Может стоит рискнуть? Вдруг из автоваза удастся сделать mercedes?
Огромное спасибо за ваш комментарий. Абсолютно полностью согласна.
Да, всегда можно сказать «зачем что-то менять, мы уже так привыкли?». Но здесь как и с любой другой идеей — нужно попробовать, а вдруг заработает и станет намноооого круче? Может стоит рискнуть? Вдруг из автоваза удастся сделать mercedes?
Не думал, что в такой огромной компании, которая еженедельно релизит "… от трёх до семи новых фич..." встречаются фичи, "… которая должна попасть в следующий релиз."
При еженедельном выпуске новых версий правильно ли это, что есть какие-то срочные (и судя по всем очень важные) фичи, на которые есть всего "… пара часов ..." на тестирование?
Иными словами — может лучше не пороть горячку и «засунуть» фичу в следующий релиз вместо того, чтобы впопыхах тестировать её?
При еженедельном выпуске новых версий правильно ли это, что есть какие-то срочные (и судя по всем очень важные) фичи, на которые есть всего "… пара часов ..." на тестирование?
Иными словами — может лучше не пороть горячку и «засунуть» фичу в следующий релиз вместо того, чтобы впопыхах тестировать её?
ну мы же не знаем, как они запускают эти фичи.
Мы например иногда выкладываем такие срочные фичи и тестируем на 1-2х клиентах, если все норм, то раскатываем дальше
Мы например иногда выкладываем такие срочные фичи и тестируем на 1-2х клиентах, если все норм, то раскатываем дальше
Доброе утро! Спасибо за ваш комментарий.
Дело в том что Badoo — продуктовая компания на очень стремительно развивающемся рынке. Каждая новая фича — это не только возможность принести пользу нашим дорогим пользователям, но и хороший повод заявить о себе. И если бизнес считает, что следующая (практически готовая) фича это прорыв на рынке — то ждать дополнительную неделю означает риск, что конкуренты выпустят что-то подобное раньше.
Да, это повод быть гибкими и срезать углы (выпускать MPV с которым согласен и бизнес и команда). Бизнес просит эстимейшн на тестирование, которого будет достаточно. Но это не повод выкатить продукт в качестве которого мы, тестировщики, не уверенны. Поэтому мы стараемся быть гибкими и максимально эффективно использовать время которое у нас, обеспечивая при этом максимальный уровень качества.
Дело в том что Badoo — продуктовая компания на очень стремительно развивающемся рынке. Каждая новая фича — это не только возможность принести пользу нашим дорогим пользователям, но и хороший повод заявить о себе. И если бизнес считает, что следующая (практически готовая) фича это прорыв на рынке — то ждать дополнительную неделю означает риск, что конкуренты выпустят что-то подобное раньше.
Да, это повод быть гибкими и срезать углы (выпускать MPV с которым согласен и бизнес и команда). Бизнес просит эстимейшн на тестирование, которого будет достаточно. Но это не повод выкатить продукт в качестве которого мы, тестировщики, не уверенны. Поэтому мы стараемся быть гибкими и максимально эффективно использовать время которое у нас, обеспечивая при этом максимальный уровень качества.
mind map вообще применима много где
Добрый день!
Спасибо за интересную статью. Однако, возник вопрос: насколько применимы карты для использования новичками на проекте? У нас сейчас гугло-доки с чек-листами, которые содержат подробные ожидаемые результаты по каждой проверке — это позволяет практически безболезненно посадить человека на прогон регрессии. Выполняя прогон по карте, необходимо иметь уже твердые знания об ожидаемых результатах. Если впихивать эти результаты в карту, то она становится слишком перегруженной.
Заранее спасибо за ответ!
Спасибо за интересную статью. Однако, возник вопрос: насколько применимы карты для использования новичками на проекте? У нас сейчас гугло-доки с чек-листами, которые содержат подробные ожидаемые результаты по каждой проверке — это позволяет практически безболезненно посадить человека на прогон регрессии. Выполняя прогон по карте, необходимо иметь уже твердые знания об ожидаемых результатах. Если впихивать эти результаты в карту, то она становится слишком перегруженной.
Заранее спасибо за ответ!
Добрый день!
Спасибо за ваш комментарий.
Если у вас уже есть написанный чеклист, не нужно от него избавляться. Можно попросить новичка несколько раз програть регрессию по такому чеклисту. Позже, когда он ознакомится с функционалом и запомнит ожидаемые результаты, можно переходить на подобную карту в целях экономии времени.
Если чеклиста нет, ситуацию спасет ментор, который может ответить на вопросы.
Спасибо за ваш комментарий.
Если у вас уже есть написанный чеклист, не нужно от него избавляться. Можно попросить новичка несколько раз програть регрессию по такому чеклисту. Позже, когда он ознакомится с функционалом и запомнит ожидаемые результаты, можно переходить на подобную карту в целях экономии времени.
Если чеклиста нет, ситуацию спасет ментор, который может ответить на вопросы.
Сначала отверг новое, такой уж у нас менталитет, все новое воспринимается с подозрением и опасением. Взяв паузу и почитав комментарии увидел что много людей пользуются и довольны, а значит что может один то может и другой. Вообще пробовать новое позволяет не окаминеть и быть на плаву в 21 веке.
Очень понравился подход тем что можно визуально иметь представление и не линейно кучу текста перед глазами и понравился термин BPO от fxaggtest, к каждому цвету я бы добавил колонку Bugs и вносил туда баги для каждой версии, после чего у меня было бы представление где сосредоточено много багов, постараюсь использовать, минус что я один на проекте, но для новичков будет чек листы, а в дальнейшем можно использовать ММ.
Очень понравился подход тем что можно визуально иметь представление и не линейно кучу текста перед глазами и понравился термин BPO от fxaggtest, к каждому цвету я бы добавил колонку Bugs и вносил туда баги для каждой версии, после чего у меня было бы представление где сосредоточено много багов, постараюсь использовать, минус что я один на проекте, но для новичков будет чек листы, а в дальнейшем можно использовать ММ.
Спасибо за ваш комментарий.
Согласна, вы описали очень правильный подход.
Согласна, вы описали очень правильный подход.
Sign up to leave a comment.
Mind map вместо тест-кейса, или Как визуализация позволяет тестировать приложение быстрее