Естественно мы не просто "встречаем" баги, в этом как раз и суть адекватного отслеживания контроля качества и использования инструментов, которые я перечислил в статье. У нас ведь как раз есть конкретная цель поиска отклонений в зависимости от модели и ОС. В данном случае, ни один из багов не будет абстрактным.
Оставить по одному девайсу у тестировщика можно, но например если у всех тестеров будет одни и те же девайсы с неизменной ОС, это менее продуктивно для нас. Даже в таком случае, оставьте у тестера по одному девайсу, но сделайте это максимально эффективно, опираясь то, как широко можно покрыть наше тестирование в зависимости от моделей и ос.
Мы все же используем и предлагаем возможности комбинации, так как определенный пул девайсов (как реальных, так и симуляторов) позволяет покрывать конкретные проверки и ничем нам конкретно не замедляет тестирование. Наоборот кое-где заранее ускоряет выявлять определенные сценарии и эдж-кейсы. Опять же, все зависит от специфики проекта. Но спасибо за совет :)
Баги в любом случае встречаем да, в соответствии с комбинациями. Что касается оценки разных версий ОС и моделей, то саму запись данных не ведём, но изменения видим. В большинстве своем это те самые вырезы на экранах, динамичная верстка, определенные краши и прочее. И да, эту встряску девайсов мы дополнительно стараемся покрыть симуляторами, чтобы не раздувать бюджет на реальные устройства, тут вы правы, что нет смысла увеличивать в разы стоимость тестирования, если учитывать статистику и продуктовую аналитику.
В нашем случае, мы стараемся на старте проекта покрыть статистику по девайсам, но потом уже приходим к продуктовой аналитике и стараемся работать с устройствами, которые реально используют пользователи.
Да, это как раз тот пункт, который мы стараемся отследить в 4 элементах, изучая клиента.
Мы стараемся не начинать слишком рано, потому что код все еще может меняться в зависимости от этапа разработки, тут нужно помнить, что это может повлиять на поддержку авто-тестов и время, которое придется на это потратить. Идеально, если код для фичи прошел все ревью и переведен на стэйдж, напимер.
Тут да, полностью согласен, моки тоже стараемся использовать.
Все верно. Если мы хотим очень тщательное ревью, то нужно потратить чуть больше времени на подготовку: изучить все необходимые материалы. Но в нашем случае, даже если второй человек подметит опечатки, логические несостыковки между шагами, какие-то рекомендации по структуре тестовой документации и данных, для нас это уже будет плюсом :)
Да, работа звучит рутинной и бесполезной, каждый раз собирать чейндж-лог... Но нужно не забывать о том, что разработчики могут уже владеть этой инфой у вас на проекте (в своем же репозитории). Главное не сам факт того, будем ли мы плодить документацию, а то, куда мы сможем за ней обратиться. И владея этой инфой в любом из ее видов, мы сможем оперативно оценивать и планировать ситуацию.
Нет, мы тоже пользовались бесплатной до этого момента, когда ограничили прогоны. Сейчас ищем возможность перейти на более поддерживаемый и простой вариант. Но для простых нужд, если нам нужно раз в день запускать какой-то прогон тестов, мне кажется он до сих пор вполне подходит :)
Да, работая по agile иногда трудно сразу приметить и учесть все, чтобы точно дать оценку, но опять же, если не давать ее вообще, то и результат не оценить (удалось ли нам попасть во время). Поэтому да, не стоит забывать корректировать себя и здесь, пересматривать свои результаты, если нужно.
На самом деле, тот же самый сайт Statcounter содержит информацию по моделям устройств и процентам используемой ОС. В любом из случаев, мы стараемся “загуглить” эту инфу, почитать форумы и статьи, сайты со статистикой перед началом проекта. В данном случае, мы можем просто использовать комбинацию, совмещая самую популярную ОС с самой популярной моделью и т.д вниз до менее популярных. Пример в статье на той основе.
В случае, когда проект уже в релизе, и есть продуктовая аналитика по устройствам, важно собрать эту инфу и обновить свою табличку, руководствоваться уже реальными данными. Тут как раз можно и сверить, как точно мы спланировали наши изначальные данные.
Да это просто шутка, я понимаю суть SNES порта :)
Ну чтож, где только Doom не запускали уже. Раз такие новости, жду запуска Doom на салфетке :)
Естественно мы не просто "встречаем" баги, в этом как раз и суть адекватного отслеживания контроля качества и использования инструментов, которые я перечислил в статье. У нас ведь как раз есть конкретная цель поиска отклонений в зависимости от модели и ОС. В данном случае, ни один из багов не будет абстрактным.
Оставить по одному девайсу у тестировщика можно, но например если у всех тестеров будет одни и те же девайсы с неизменной ОС, это менее продуктивно для нас. Даже в таком случае, оставьте у тестера по одному девайсу, но сделайте это максимально эффективно, опираясь то, как широко можно покрыть наше тестирование в зависимости от моделей и ос.
Мы все же используем и предлагаем возможности комбинации, так как определенный пул девайсов (как реальных, так и симуляторов) позволяет покрывать конкретные проверки и ничем нам конкретно не замедляет тестирование. Наоборот кое-где заранее ускоряет выявлять определенные сценарии и эдж-кейсы. Опять же, все зависит от специфики проекта. Но спасибо за совет :)
Баги в любом случае встречаем да, в соответствии с комбинациями. Что касается оценки разных версий ОС и моделей, то саму запись данных не ведём, но изменения видим. В большинстве своем это те самые вырезы на экранах, динамичная верстка, определенные краши и прочее. И да, эту встряску девайсов мы дополнительно стараемся покрыть симуляторами, чтобы не раздувать бюджет на реальные устройства, тут вы правы, что нет смысла увеличивать в разы стоимость тестирования, если учитывать статистику и продуктовую аналитику.
В нашем случае, мы стараемся на старте проекта покрыть статистику по девайсам, но потом уже приходим к продуктовой аналитике и стараемся работать с устройствами, которые реально используют пользователи.
Про продуктовую аналитику тоже полностью поддерживаю. У нас этот кейс также работает, обновляем наши данные:
https://habr.com/ru/articles/821209/comments/#comment_26925863
Да, это как раз тот пункт, который мы стараемся отследить в 4 элементах, изучая клиента.
Мы стараемся не начинать слишком рано, потому что код все еще может меняться в зависимости от этапа разработки, тут нужно помнить, что это может повлиять на поддержку авто-тестов и время, которое придется на это потратить. Идеально, если код для фичи прошел все ревью и переведен на стэйдж, напимер.
Тут да, полностью согласен, моки тоже стараемся использовать.
Да, действительно, про него подумаем. Спасибо :)
Добавил в отдельный плейлист себе :)
Все верно. Если мы хотим очень тщательное ревью, то нужно потратить чуть больше времени на подготовку: изучить все необходимые материалы. Но в нашем случае, даже если второй человек подметит опечатки, логические несостыковки между шагами, какие-то рекомендации по структуре тестовой документации и данных, для нас это уже будет плюсом :)
Да, работа звучит рутинной и бесполезной, каждый раз собирать чейндж-лог... Но нужно не забывать о том, что разработчики могут уже владеть этой инфой у вас на проекте (в своем же репозитории). Главное не сам факт того, будем ли мы плодить документацию, а то, куда мы сможем за ней обратиться. И владея этой инфой в любом из ее видов, мы сможем оперативно оценивать и планировать ситуацию.
Нет, мы тоже пользовались бесплатной до этого момента, когда ограничили прогоны. Сейчас ищем возможность перейти на более поддерживаемый и простой вариант. Но для простых нужд, если нам нужно раз в день запускать какой-то прогон тестов, мне кажется он до сих пор вполне подходит :)
Да, работая по agile иногда трудно сразу приметить и учесть все, чтобы точно дать оценку, но опять же, если не давать ее вообще, то и результат не оценить (удалось ли нам попасть во время). Поэтому да, не стоит забывать корректировать себя и здесь, пересматривать свои результаты, если нужно.
На самом деле, тот же самый сайт Statcounter содержит информацию по моделям устройств и процентам используемой ОС. В любом из случаев, мы стараемся “загуглить” эту инфу, почитать форумы и статьи, сайты со статистикой перед началом проекта. В данном случае, мы можем просто использовать комбинацию, совмещая самую популярную ОС с самой популярной моделью и т.д вниз до менее популярных. Пример в статье на той основе.
В случае, когда проект уже в релизе, и есть продуктовая аналитика по устройствам, важно собрать эту инфу и обновить свою табличку, руководствоваться уже реальными данными. Тут как раз можно и сверить, как точно мы спланировали наши изначальные данные.
"Ущерб от сбоя сервисов СДЭК может составить от 300 млн до 1 млрд рублей" - уфф :(
Уже поднялся :)
Звучит грустно...