Добрый день, спасибо за ваш комментарий.
Главный посыл в том, чтобы быть в курсе проблем в бета-версии и отслеживать их статус ближе к GM. Не нужно чинить все сразу.
В описанном вами случае оцените критичность бага — и если он не критичен — ждите GM.
Если критичен — скорее всего бизнес поддержит идею «костылить». В таком случае, если Apple починит проблему до GM версии, прийдется «раскостылить». Но объем проверок будет минимальный, так как бета установлена у малого количества пользователей. Если же Apple починит проблему после GM, прийдется не просто «раскостылить», но и проверить на версиях с проблемой, без проблемы и, собственно, обновление.
Добрый вечер! Спасибо за ваш комментарий.
Да, действительно, Apple вынуждает пользователей быстро обновляться и нам необходимо поддерживать официальные релизы новой ОС как можно скорее.
Но это совсем не означает что мы перестаем поддерживать старые версии ОС. Так, например, в течении следующего года все новые релизы Badoo будут актуальны и для пользователей с iOS 11. Что касается пользователей с iOS 10 и ниже, они все еще смогут скачать приложение с AppStore и активно им пользоваться. Но им будут не доступны новые фичи.
Добрый день!
Спасибо за ваш комментарий.
Если у вас уже есть написанный чеклист, не нужно от него избавляться. Можно попросить новичка несколько раз програть регрессию по такому чеклисту. Позже, когда он ознакомится с функционалом и запомнит ожидаемые результаты, можно переходить на подобную карту в целях экономии времени.
Если чеклиста нет, ситуацию спасет ментор, который может ответить на вопросы.
Доброе утро! Спасибо за ваш комментарий.
Дело в том что Badoo — продуктовая компания на очень стремительно развивающемся рынке. Каждая новая фича — это не только возможность принести пользу нашим дорогим пользователям, но и хороший повод заявить о себе. И если бизнес считает, что следующая (практически готовая) фича это прорыв на рынке — то ждать дополнительную неделю означает риск, что конкуренты выпустят что-то подобное раньше.
Да, это повод быть гибкими и срезать углы (выпускать MPV с которым согласен и бизнес и команда). Бизнес просит эстимейшн на тестирование, которого будет достаточно. Но это не повод выкатить продукт в качестве которого мы, тестировщики, не уверенны. Поэтому мы стараемся быть гибкими и максимально эффективно использовать время которое у нас, обеспечивая при этом максимальный уровень качества.
Спасибо, интересный опыт.
Оказывается mind maps можно использовать не только как удобный способ шарить знания среди тестировщиков, но и как понятный документ для бизнеса (а таких не много, знаете ли)
Да, это удобный таймсейвер, и с програмками которые все сами строят очень приятно работать.
Пожалуйста, поделитесь фишками, которые могут прокачать карту. Уверенна, это будет очень полезно.
Добрый день!
Огромное спасибо за ваш комментарий. Абсолютно полностью согласна.
Да, всегда можно сказать «зачем что-то менять, мы уже так привыкли?». Но здесь как и с любой другой идеей — нужно попробовать, а вдруг заработает и станет намноооого круче? Может стоит рискнуть? Вдруг из автоваза удастся сделать mercedes?
Да, структурные элементы данной mind map действительно можно охарактеризовать как high level test cases. Построение такой mind map первый раз заняло несколько часов. Кастомизация под каждую фичу -нужно просто скрывать определенные ветки — занимает меньше минуты.
Согласна, проставлять галочки по чеклисту это конечно удобно в пане тестирование регрессии, не покрытой автотестами. Но в этой статье речь идет о тестировании новой фичи, для которой такая схема будет намного более наглядной (на одну такую страницу с mind map умещается чеклист на четыре страницы). Как правило, люди проще воспринимают структурированную и хорошо визуально оформленную информацию. Плюс совершенно не обязательно проставлять галочки. Но если сильно хочется — то такая возможно у вас безусловно будет.
Взаимодействие с сильно формализованной документацией отнимает много времени. Дело в том что чеклисты нужно постоянно актуализировать и заполнять. На это нужно тратить ресурсы.
Добрый вечер! Спасибо за ваш комментарий, интересное мнение.
z3us поделился отличной презентацией об интеграции автоматизации и mind map.
Признаться, по задумке схему нужно нарисовать всего раз. При тестировании новой фичи вам не нужно будет каждый раз пересоздавать mind map. Это не рационально. Как правило одна фича будет затрагивать всего несколько секций. И нужно будет выбрать только актуальные проверки.
По поводу автоматизации, согласна, если фичи на вашем проекте однотипны и вы можете автоматизировать все быстро и по стандартному шаблону — вперед! Можно с помощью TestRail или любого подобного приложения настроить синхронизацию между схемой и автотестами. Можно даже пойти дальше и трекать тестовое покрытие автотестов по подобной схеме)
Все зависит от вашего проекта. Мне удобно иметь такую карту, с достаточно абстрактными пунктами, потому что каждая новая фича в Badoo не похожа на предыдущую. Если вы способны поставлять тесты сразу с фичей — вы круты! У нас часто руки до автоматизации доходят тогда, когда проект уже продвинулся дальше.
Главный посыл в том, чтобы быть в курсе проблем в бета-версии и отслеживать их статус ближе к GM. Не нужно чинить все сразу.
В описанном вами случае оцените критичность бага — и если он не критичен — ждите GM.
Если критичен — скорее всего бизнес поддержит идею «костылить». В таком случае, если Apple починит проблему до GM версии, прийдется «раскостылить». Но объем проверок будет минимальный, так как бета установлена у малого количества пользователей. Если же Apple починит проблему после GM, прийдется не просто «раскостылить», но и проверить на версиях с проблемой, без проблемы и, собственно, обновление.
Да, действительно, Apple вынуждает пользователей быстро обновляться и нам необходимо поддерживать официальные релизы новой ОС как можно скорее.
Но это совсем не означает что мы перестаем поддерживать старые версии ОС. Так, например, в течении следующего года все новые релизы Badoo будут актуальны и для пользователей с iOS 11. Что касается пользователей с iOS 10 и ниже, они все еще смогут скачать приложение с AppStore и активно им пользоваться. Но им будут не доступны новые фичи.
Согласна, вы описали очень правильный подход.
Спасибо за ваш комментарий.
Если у вас уже есть написанный чеклист, не нужно от него избавляться. Можно попросить новичка несколько раз програть регрессию по такому чеклисту. Позже, когда он ознакомится с функционалом и запомнит ожидаемые результаты, можно переходить на подобную карту в целях экономии времени.
Если чеклиста нет, ситуацию спасет ментор, который может ответить на вопросы.
Дело в том что Badoo — продуктовая компания на очень стремительно развивающемся рынке. Каждая новая фича — это не только возможность принести пользу нашим дорогим пользователям, но и хороший повод заявить о себе. И если бизнес считает, что следующая (практически готовая) фича это прорыв на рынке — то ждать дополнительную неделю означает риск, что конкуренты выпустят что-то подобное раньше.
Да, это повод быть гибкими и срезать углы (выпускать MPV с которым согласен и бизнес и команда). Бизнес просит эстимейшн на тестирование, которого будет достаточно. Но это не повод выкатить продукт в качестве которого мы, тестировщики, не уверенны. Поэтому мы стараемся быть гибкими и максимально эффективно использовать время которое у нас, обеспечивая при этом максимальный уровень качества.
Оказывается mind maps можно использовать не только как удобный способ шарить знания среди тестировщиков, но и как понятный документ для бизнеса (а таких не много, знаете ли)
Пожалуйста, поделитесь фишками, которые могут прокачать карту. Уверенна, это будет очень полезно.
Огромное спасибо за ваш комментарий. Абсолютно полностью согласна.
Да, всегда можно сказать «зачем что-то менять, мы уже так привыкли?». Но здесь как и с любой другой идеей — нужно попробовать, а вдруг заработает и станет намноооого круче? Может стоит рискнуть? Вдруг из автоваза удастся сделать mercedes?
Да, структурные элементы данной mind map действительно можно охарактеризовать как high level test cases. Построение такой mind map первый раз заняло несколько часов. Кастомизация под каждую фичу -нужно просто скрывать определенные ветки — занимает меньше минуты.
Согласна, проставлять галочки по чеклисту это конечно удобно в пане тестирование регрессии, не покрытой автотестами. Но в этой статье речь идет о тестировании новой фичи, для которой такая схема будет намного более наглядной (на одну такую страницу с mind map умещается чеклист на четыре страницы). Как правило, люди проще воспринимают структурированную и хорошо визуально оформленную информацию. Плюс совершенно не обязательно проставлять галочки. Но если сильно хочется — то такая возможно у вас безусловно будет.
Взаимодействие с сильно формализованной документацией отнимает много времени. Дело в том что чеклисты нужно постоянно актуализировать и заполнять. На это нужно тратить ресурсы.
raydac спасибо, возьму на вооружение
z3us поделился отличной презентацией об интеграции автоматизации и mind map.
Признаться, по задумке схему нужно нарисовать всего раз. При тестировании новой фичи вам не нужно будет каждый раз пересоздавать mind map. Это не рационально. Как правило одна фича будет затрагивать всего несколько секций. И нужно будет выбрать только актуальные проверки.
По поводу автоматизации, согласна, если фичи на вашем проекте однотипны и вы можете автоматизировать все быстро и по стандартному шаблону — вперед! Можно с помощью TestRail или любого подобного приложения настроить синхронизацию между схемой и автотестами. Можно даже пойти дальше и трекать тестовое покрытие автотестов по подобной схеме)
Все зависит от вашего проекта. Мне удобно иметь такую карту, с достаточно абстрактными пунктами, потому что каждая новая фича в Badoo не похожа на предыдущую. Если вы способны поставлять тесты сразу с фичей — вы круты! У нас часто руки до автоматизации доходят тогда, когда проект уже продвинулся дальше.