Да, это как раз тот пункт, который мы стараемся отследить в 4 элементах, изучая клиента.
Мы стараемся не начинать слишком рано, потому что код все еще может меняться в зависимости от этапа разработки, тут нужно помнить, что это может повлиять на поддержку авто-тестов и время, которое придется на это потратить. Идеально, если код для фичи прошел все ревью и переведен на стэйдж, напимер.
Тут да, полностью согласен, моки тоже стараемся использовать.
Все верно. Если мы хотим очень тщательное ревью, то нужно потратить чуть больше времени на подготовку: изучить все необходимые материалы. Но в нашем случае, даже если второй человек подметит опечатки, логические несостыковки между шагами, какие-то рекомендации по структуре тестовой документации и данных, для нас это уже будет плюсом :)
Да, работа звучит рутинной и бесполезной, каждый раз собирать чейндж-лог... Но нужно не забывать о том, что разработчики могут уже владеть этой инфой у вас на проекте (в своем же репозитории). Главное не сам факт того, будем ли мы плодить документацию, а то, куда мы сможем за ней обратиться. И владея этой инфой в любом из ее видов, мы сможем оперативно оценивать и планировать ситуацию.
Нет, мы тоже пользовались бесплатной до этого момента, когда ограничили прогоны. Сейчас ищем возможность перейти на более поддерживаемый и простой вариант. Но для простых нужд, если нам нужно раз в день запускать какой-то прогон тестов, мне кажется он до сих пор вполне подходит :)
Да, работая по agile иногда трудно сразу приметить и учесть все, чтобы точно дать оценку, но опять же, если не давать ее вообще, то и результат не оценить (удалось ли нам попасть во время). Поэтому да, не стоит забывать корректировать себя и здесь, пересматривать свои результаты, если нужно.
На самом деле, тот же самый сайт Statcounter содержит информацию по моделям устройств и процентам используемой ОС. В любом из случаев, мы стараемся “загуглить” эту инфу, почитать форумы и статьи, сайты со статистикой перед началом проекта. В данном случае, мы можем просто использовать комбинацию, совмещая самую популярную ОС с самой популярной моделью и т.д вниз до менее популярных. Пример в статье на той основе.
В случае, когда проект уже в релизе, и есть продуктовая аналитика по устройствам, важно собрать эту инфу и обновить свою табличку, руководствоваться уже реальными данными. Тут как раз можно и сверить, как точно мы спланировали наши изначальные данные.
Да, это как раз тот пункт, который мы стараемся отследить в 4 элементах, изучая клиента.
Мы стараемся не начинать слишком рано, потому что код все еще может меняться в зависимости от этапа разработки, тут нужно помнить, что это может повлиять на поддержку авто-тестов и время, которое придется на это потратить. Идеально, если код для фичи прошел все ревью и переведен на стэйдж, напимер.
Тут да, полностью согласен, моки тоже стараемся использовать.
Да, действительно, про него подумаем. Спасибо :)
Добавил в отдельный плейлист себе :)
Все верно. Если мы хотим очень тщательное ревью, то нужно потратить чуть больше времени на подготовку: изучить все необходимые материалы. Но в нашем случае, даже если второй человек подметит опечатки, логические несостыковки между шагами, какие-то рекомендации по структуре тестовой документации и данных, для нас это уже будет плюсом :)
Да, работа звучит рутинной и бесполезной, каждый раз собирать чейндж-лог... Но нужно не забывать о том, что разработчики могут уже владеть этой инфой у вас на проекте (в своем же репозитории). Главное не сам факт того, будем ли мы плодить документацию, а то, куда мы сможем за ней обратиться. И владея этой инфой в любом из ее видов, мы сможем оперативно оценивать и планировать ситуацию.
Нет, мы тоже пользовались бесплатной до этого момента, когда ограничили прогоны. Сейчас ищем возможность перейти на более поддерживаемый и простой вариант. Но для простых нужд, если нам нужно раз в день запускать какой-то прогон тестов, мне кажется он до сих пор вполне подходит :)
Да, работая по agile иногда трудно сразу приметить и учесть все, чтобы точно дать оценку, но опять же, если не давать ее вообще, то и результат не оценить (удалось ли нам попасть во время). Поэтому да, не стоит забывать корректировать себя и здесь, пересматривать свои результаты, если нужно.
На самом деле, тот же самый сайт Statcounter содержит информацию по моделям устройств и процентам используемой ОС. В любом из случаев, мы стараемся “загуглить” эту инфу, почитать форумы и статьи, сайты со статистикой перед началом проекта. В данном случае, мы можем просто использовать комбинацию, совмещая самую популярную ОС с самой популярной моделью и т.д вниз до менее популярных. Пример в статье на той основе.
В случае, когда проект уже в релизе, и есть продуктовая аналитика по устройствам, важно собрать эту инфу и обновить свою табличку, руководствоваться уже реальными данными. Тут как раз можно и сверить, как точно мы спланировали наши изначальные данные.
"Ущерб от сбоя сервисов СДЭК может составить от 300 млн до 1 млрд рублей" - уфф :(
Уже поднялся :)
Звучит грустно...