Условно говоря, может у кого то 20 устройств или больше, постоянно на зарядке держатся или как с ними обращаются?

У нас выключенными обычно лежат

Всем доброго вечера, подскажите, как хранить реальные устройства? Условно говоря все устройства заряжены, интернеты выключены и т.д., но за выходные они разряжаются, такой заряд-разряд постоянный как быстро скажется на устройствах?кто как делает, выключает их или просто пофиг что батарея страдает

как и говорилось выше - авиа режим спасет ситуацию, энергия будет тратиться значительно медленнее. а так для движения частиц внутри батарейки сервис рекомендует раз в месяц 1-3 полный разряд-заряд делать, чтобы не было остаточного эфекта и в последующем батарея не сокращала объем. Постоянно на зарядке не рекомендуется держать и уж особенно, если девайс что-то гоняет по WiFi или GSM сетям, т.к., перегревается, в частности WiFi модули от Broadcom'а жарят девайс будь здоров и на низкоамперной зарядке и активности девайс: геолокация/wifi/3-4G будет иногда происходить медленный разряд. а так, если за ненадобностью, то лучше отключать

как и говорилось выше - авиа режим спасет ситуацию, энергия будет тратиться значительно медленнее. а так для движения частиц внутри батарейки сервис рекомендует раз в месяц 1-3 полный разряд-заряд делать, чтобы не было остаточного эфекта и в последующем батарея не сокращала объем. Постоянно на зарядке не рекомендуется держать и уж особенно, если девайс что-то гоняет по WiFi или GSM сетям, т.к., перегревается, в частности WiFi модули от Broadcom'а жарят девайс будь здоров и на низкоамперной зарядке и активности девайс: геолокация/wifi/3-4G будет иногда происходить медленный разряд. а так, если за ненадобностью, то лучше отключать

сервис рекомендует раз в месяц 1-3 полный разряд-заряд делать, чтобы не было остаточного эфекта и в последующем батарея не сокращала объем. И часто ли такое делают люди со своими обычными гаджетами? Да и типы батарей в телефонах бывают разные

сервис рекомендует раз в месяц 1-3 полный разряд-заряд делать, чтобы не было остаточного эфекта и в последующем батарея не сокращала объем. И часто ли такое делают люди со своими обычными гаджетами? Да и типы батарей в телефонах бывают разные

да конечно же нет. но я стараюсь это делать. не скажу, что прямо это увеличивает срок службы аккума на овердохера времени, но на примере своего 5S и 5S товарища могу сказать, что все же мой разряжается медленнее спустя 4 года, чем его 2.5 годовалый. В тестах нагрузка на оба девайса одинаковая. В целом на счет типа батареи да, они все же разные, но если брать на примере стандартной литиионной

да конечно же нет. но я стараюсь это делать. не скажу, что прямо это увеличивает срок службы аккума на овердохера времени, но на примере своего 5S и 5S товарища могу сказать, что все же мой разряжается медленнее спустя 4 года, чем его 2.5 годовалый. В тестах нагрузка на оба девайса одинаковая. В целом на счет типа батареи да, они все же разные, но если брать на примере стандартной литиионной

У меня у самого 5s. Н Сравнивать свой телефон и телефон товарища не совсем корректно. У каждого свои сценарии работы (игры, интернет, беспроводные наушники, умные часы, фитнес браслеты, навигация, регулярные пуши), каждый по-своему относится к температурным режимам (кто на холоде и в жару юзает, а кто нет), кто как и на сколько по времени заряжает, роняет.

У меня у самого 5s. Н Сравнивать свой телефон и телефон товарища не совсем корректно. У каждого свои сценарии работы (игры, интернет, беспроводные наушники, умные часы, фитнес браслеты, навигация, регулярные пуши), каждый по-своему относится к температурным режимам (кто на холоде и в жару юзает, а кто нет), кто как и на сколько по времени заряжает, роняет.

сделаю оговорку на то, что телефон больше в тестах, нежели в повседневной жизни. ну и да, Вы правы, как и частично то, что я написал

сервис рекомендует раз в месяц 1-3 полный разряд-заряд делать, чтобы не было остаточного эфекта и в последующем батарея не сокращала объем. И часто ли такое делают люди со своими обычными гаджетами? Да и типы батарей в телефонах бывают разные

обычно телефон разряжается почти полностью. ну +- раз в полгода хотя бы (оказался далеко от розетки на весь день)

http://www.developsense.com/blog/2017/11/the-end-of-manual-testing/ Конец ручного тестирования

наконец-то, сколько можно было ждать

в России нам это грозит в 2030

лол. Вы бы прочитали сперва хоть про что . ?

Вкратце: у ручного тестирования нет будущего, не было прошлого и нет настоящего. Ручного тестирования не существует и не существовало никогда - существует просто тестирование. А кто будут говорить про ручное - тому рот с мылом полоскать.

Хоть горшком назовите, только в печку не ставьте

))))

http://www.developsense.com/blog/2017/11/the-end-of-manual-testing/ Конец ручного тестирования

Господи, что за буллшит?

от того хочет автор или нет, фундаментально, ручной или авто-куа, как принято и как поделил это Рыночек - говорит о том, сможет ли этот человек справиться с регрессией

Всем доброго вечера, подскажите, как хранить реальные устройства? Условно говоря все устройства заряжены, интернеты выключены и т.д., но за выходные они разряжаются, такой заряд-разряд постоянный как быстро скажется на устройствах?кто как делает, выключает их или просто пофиг что батарея страдает

на станции зарядки полдня. вторую половину ходят по людям и разряжаются. перегрева не наблюдается, но все равно будем мутить охлаждение в ящике

ведь фундаментально, это то, ради чего нужна автоматизация в тестировании, получать фидбек в сжатые сроки. Ни много ни мало.

кажется, это проблема отдельно взятого тестировщика, если он решил, что маркер "ручного" должен как-то ограничивать сферу его технологической компетенции

ага, автоматизация правда даёт только часть фидбэка. О чем в том числе и пишет автор.

рынок все реже разделяет понятия ручного тестирования и автоматизации, сейчас хотят универсального бойца (Full Stack QA)

Автор, честно говоря, похоже сам не понимает, о чем пишет. Автоматизация - это инструмент. Ну, окей. Тестирование - это вообще инструмент. Один из инструментов обеспечения качества продукта. Ну спасибо, кэп. Автоматизация тестирования существует, инструменты автоматизации существует, а автоматизированного тестирования - не существует. Ну окей, чо уж там.

Смысл автоматизации не в том, что бы заменить ручное тестирование, а в том, что бы освободить ресурсы людей от валидации, и перенаправить их на исследование.

И не понимают этого разве что идиоты.

Гы, у вас даже с Dorki разные мнения

риальне?

Я вот не вижу противоречий, честно говоря.

возможно, автоматизация обидит кого из инженера: у него хорошая память, а он запомнил весь пласт последовательных действий, неуклонно сверялся с Тестрейлом и вопроизвел поведение. Автоматизация также решит проблему человеческого фактора "потери" и фундаментальной проблемы воспроизводимости. Не переписывать переменные руками, всегда вставлять. Рефакторить при помощи "Refactor..." в IDE И еще куча вещей, которые нужно в себе воспитывать, чтобы не добавлять complexity к и без того сложной работе

"ресурсы людей от валидации" - что ?)

И я тут поддержу Dorki. Для того чтобы освободить ресурсы от валидации, нужно сначала быть идиотом, чтобы отправить ресурсы на валидацию.

"ресурсы людей от валидации" - что ?)

Освободить. Люди не должны заниматься валидацией, должны заниматься исследованием.

И я тут поддержу Dorki. Для того чтобы освободить ресурсы от валидации, нужно сначала быть идиотом, чтобы отправить ресурсы на валидацию.

Валидация, в том или ином виде, необходима. Увы.

А тот кто считает что тестирование - это в основном валидация - тому с мылом не только рот, но и моск мыть.

как автоматизация помагает проводить валидацию

автоматизация (тестов) как раз и заточена под валидацию.

прям хочу прочесть где такое написано, если можно

думать, чем заниматься люди "должны"- фундаментально неверный подход

валидация - это checking

кстати да, верификация это чекинг

checking - это всегда утрированная до простого ассерта штука

и сам иногда путаю ?

валидация - это другое

под верефикацию да

Евгений прав

но явно не под валидацию )

вот и кажется потом, что все кругом идиоты)))

Я бы даже послушал ваши размышления о разнице валидации с верификацией в данном контексте.

я согласен с Dorki про быстрые фидбэк вообще в целом. Задача тестировщика давать быстрый и квалифицированный фидбэк.

вот и кажется потом, что все кругом идиоты)))

часто встречаю подмену понятий и сам практикую ((( это на самом деле ужасно

не придирайтесь сильно к словам, пока вы понимаете суть беседы. Это всего лишь лейблы :)

это не ужасно, пока вас понимают люди.

часто встречаю подмену понятий и сам практикую ((( это на самом деле ужасно

часто неосознанно происходит, как в этом случае

иногда быстрый и квалифицированный лучше с автоматикой, иногда (и очень-очень часто) - с головой и руками.

я работаю на эмбеддед проекте тут все стараются автоматизировать, но на практике это даже вредно.

фидбек получается не полным а порою даже не верным.

Какие-то очень странные тезисы посыпались.

это зависит от того, КАК вы автоматизируете и сколько проблем автоматизация в вашей модели покрыто.

Ложное ощущение от покрытия

глупо написав Rails тест на модель в бд ожидать, что письмо пользователю придет, если еще есть RabbitMQ, из которой вычитывается очередь

а может ли эмуляторы и симуляторы точно повторить поведение реальной системы

Человек решает задачу лучше робота, когда идет речь о работе в условиях неявных (или отсутствующих) требований и всяческих субьективных категориях (насколько это удобно, насколько это решает бизнес нидс, прочее). Это, в большинстве своем, вопросы характерные для исследовательского тестирования на этапе приемки фичи. В условиях, когда реализация фичи проверена, требования провалидированы и нужно прочекать SUT целиком - руками и головой почти никогда не будет быстрее. Потому что ресурсы автоматизации отлично масштабируются, параллеллятся, да и большинство типовых задач код исполняет быстрее человека, что уж там.

> нужно прочекать SUT целиком кому нужно?

Это заблуждение, что нужно.

Конечно не нужно, зачем. В проде поднимем. :)

На основании этого заблуждение и удёт весь этот поток ерунды про то, что нужно много "ручных тестеров" ну или "регрессию автоматизировать"

Окей, какое решение предлагаешь ты, вместо того, что бы гонять регрессию?

не гонять регрессию, следить за процессом лучше, мониторить систему, иметь возможность быстрого передеплоя, включения-выключения фич

гонять регрессию это из мира водопадных проектов

когда 6 месяцев пишем, 3 месяца тестируем, потом еще 2 месяца фиксим

регрессия слишком дорогая, чтобы при современном цикле ее гонять при каждом чихе

не гонять регрессию, следить за процессом лучше, мониторить систему, иметь возможность быстрого передеплоя, включения-выключения фич

это в системе частых изменений требований?

а какая разница? требования всегда часто изменяются

Не гонять регрессию == удержать в голове всю многообразную природу продукта

Нет, это просто забить на неё до первого факапа.

? шоа. Зачем

Не разбив и не композировав ее на юз кейсы

насколько знаю, в водопаде они не изменяются. ведь "6 месяцев пишем, 3 месяца тестируем, потом еще 2 месяца фиксим"

не гонять регрессию, следить за процессом лучше, мониторить систему, иметь возможность быстрого передеплоя, включения-выключения фич

Всё перечисленное, безусловно, нужно. Тут есть только одна проблема: все перечисленные меры дают возможность откатиться с минимальным ущербом, а не предотвратить его.

И в воподаде они изменяются. Просто изменения попадают в производства на месяца позжже

конечно. Позволяют предотвратить ущерб от регрессии, который 100% ущерб, взамен вероятностного.

А дальше все уже зависит от финансовых рисков, собственно. Если у вас сайтик на полтора инвалида - то быстро откатиться это оптимальный вариант. Если у вас пол миллиарда DAU - то та минута, за которую у вас произойдет алертинг и редеплой будет стоить примерно как весь отдел разработки.

Делать полную регрессию перед релизом, это как давайте, чтобы избежать потери 10.000 от ошибке потратим 50.000 на дополнительные проверки.

а сколько стоит полная регрессия для сайтов с пол-миллиарда DAU?

Несколько зарплат QA инженеров стоит.

В месяц, всмысле.

Полная регрессия наверное где-то нужна, в медицине, космосе там, других критических отраслях

полная - это мифические 100%?

Опять же, смотря что ты подразумеваешь под полной регрессией.

Полная регрессия наверное где-то нужна, в медицине, космосе там, других критических отраслях

да в мед мы гоняем весь сет кейсов ) но на самом деле это не весь, они разбиты на категории.

Регрессия это "Давайте мы сейчас потратим N, и это нас спасет от рисков стоимостью от 0 до N^10".

Тестирование - это и анализ ситуации. Если риски от 0 до N^10, это не значит, что в среднем N^10/2

Те участки, которых не касаются изменения - не надо перетестировать

А "полная регрессия" - всегда о том, чтобы тупо все кейсики повторять. ужос-ужос

Регрессия избавляет от ложного ощущения, что то чего изменения не коснулись - не сломалось

Считайте количество "ой!" Каждый раз когда после изменения кода вы перед запуском тестов говорите "должен упасть только этот набор" а падают ещё и другие

Регрессия избавляет от ложного ощущения, что то чего изменения не коснулись - не сломалось

или даёт ложное ощущение, что ничего не сломалось, это как повезёт.

А "полная регрессия" - всегда о том, чтобы тупо все кейсики повторять. ужос-ужос

Да, только ты как-то очень эффектно подменил термин "регрессия" термином "полная регрессия".

Кажется, регрессия призвана уменьшать энтропию ;)