Comments 25
Понятно, что статистику по платформам можно посмотреть на сайтах, а как вы руководствуетесь, какую именно модель тлф и ОС выбрать?
На самом деле, тот же самый сайт Statcounter содержит информацию по моделям устройств и процентам используемой ОС. В любом из случаев, мы стараемся “загуглить” эту инфу, почитать форумы и статьи, сайты со статистикой перед началом проекта. В данном случае, мы можем просто использовать комбинацию, совмещая самую популярную ОС с самой популярной моделью и т.д вниз до менее популярных. Пример в статье на той основе.
В случае, когда проект уже в релизе, и есть продуктовая аналитика по устройствам, важно собрать эту инфу и обновить свою табличку, руководствоваться уже реальными данными. Тут как раз можно и сверить, как точно мы спланировали наши изначальные данные.
«тестировщик не завёл баг-репорт, попросил разработчика исправить его на словах» - классика)
гифки не грузятся(((
По оценке задач ощущение, что смотрите на мир в “розовых очках“. В agile всегда все меняется, оценки по времени потеряли актуальность.
у постмана есть проблема бесплатной версии, нельзя часто гонять авто-тесты. У вас платная версия?
Мне кажется это пустая трата времени документировать каждую новую сборку на отслеживание версий. А если их в день выходит 10 штук, и то минимум, все время потратишь на сбор этой инфы, еще и забудешь
Да, работа звучит рутинной и бесполезной, каждый раз собирать чейндж-лог... Но нужно не забывать о том, что разработчики могут уже владеть этой инфой у вас на проекте (в своем же репозитории). Главное не сам факт того, будем ли мы плодить документацию, а то, куда мы сможем за ней обратиться. И владея этой инфой в любом из ее видов, мы сможем оперативно оценивать и планировать ситуацию.
Насколько вообще важно и полезно проводить ревью тест-кейсов? Я просто не могу представить, чтобы человек, который еще не знает функционал пришел и посмотрев на мои тест-кейсы сказал, что у меня где-то проблемы. Это же значит, что ему тоже надо сначала прочитать требования, поспрашивать, потом только проводить ревью, а это займет время. В чем вообще польза?
Все верно. Если мы хотим очень тщательное ревью, то нужно потратить чуть больше времени на подготовку: изучить все необходимые материалы. Но в нашем случае, даже если второй человек подметит опечатки, логические несостыковки между шагами, какие-то рекомендации по структуре тестовой документации и данных, для нас это уже будет плюсом :)
могу добавить:
Мало смотреть на то, какими устройствами в основном пользуются люди в мире, стоит оценивать вашу целевую аудиторию. Например, если ваша ЦУ - состоятельные люди 25-40 лет, то смысла тестировать на старых версиях Андроид с низким разрешением экрана мало толку.
Автотесты можно начать писать до полной готовности приложения. Мы начинаем писать автотесты примерно в тот же момент, когда разработка начинает писать свой код.
Если есть зависимости от сторонних сервисах, можно использовать моки. Они ускорят ваши тесты и сделают их более стабильными. Большую часть кейсов можно замокать и выделить несколько интеграционных сценариев. Подробнее про использование моков с примерами можно почитать в статье https://habr.com/ru/amp/publications/812163/
О, еще добавлю, что если вашеме приложение не только что вышло в свет, возможно уже прикручена какая-то аналитика, например, Яндекс метрика. Там можно глянуть какими устройствами пользуются люди. В самом Гугле и AppStore тоже есть статистика по устройствам ваших пользователей
Да, это как раз тот пункт, который мы стараемся отследить в 4 элементах, изучая клиента.
Мы стараемся не начинать слишком рано, потому что код все еще может меняться в зависимости от этапа разработки, тут нужно помнить, что это может повлиять на поддержку авто-тестов и время, которое придется на это потратить. Идеально, если код для фичи прошел все ревью и переведен на стэйдж, напимер.
Тут да, полностью согласен, моки тоже стараемся использовать.
Про продуктовую аналитику тоже полностью поддерживаю. У нас этот кейс также работает, обновляем наши данные:
https://habr.com/ru/articles/821209/comments/#comment_26925863
Вы пробовали оценить, есть ли у вас и вправду баги на разных телефонах и версиях ОС?
И насколько часто такие баги происходят и насколько они важны?
Я в конце концов пришел к вот такой схеме:
Проверяем новую мажорную версию ОС на бете/релизе целиком
Четко понимаем какие особенности девайса играют роль в нашем приложении (например, вырезы на экране, наличие фейсайди, реализация нужных нам алгоритмов сжатия, битность процессора и прочее) - проверяем это целенаправленно
Всё остальное (99% тестов) тестим на чем угодно
Вообще это касается всего остального, что вы написали в том числе. Оцениваете ли вы итог изменений и если да, то как и какие результаты? Потому что на примере с девайсами - буквально в каждой статье пишут про необходимость подбора девайсов и их перетряхиванию, но на практике подавляющее большинство проблем актуально для всех девайсов. И достижение качества на условный 1% выше путем увеличения стоимости тестирования в два три раза - не имеет смысла для большинства проектов.
Баги в любом случае встречаем да, в соответствии с комбинациями. Что касается оценки разных версий ОС и моделей, то саму запись данных не ведём, но изменения видим. В большинстве своем это те самые вырезы на экранах, динамичная верстка, определенные краши и прочее. И да, эту встряску девайсов мы дополнительно стараемся покрыть симуляторами, чтобы не раздувать бюджет на реальные устройства, тут вы правы, что нет смысла увеличивать в разы стоимость тестирования, если учитывать статистику и продуктовую аналитику.
В нашем случае, мы стараемся на старте проекта покрыть статистику по девайсам, но потом уже приходим к продуктовой аналитике и стараемся работать с устройствами, которые реально используют пользователи.
Баги недостаточно "встречать". Важно ведь, что это за баги, на что они влияют, какие проблемы у бизнеса и сколько они ему стоят. Просто так абстрактные баги - никому кроме тестировщиков не интересны.
Всё то что вы перечислили вполне покрывается эмуляторами и с этим даже быстрее будет работать, чем с реальным девайсом. Так что с высокой долей вероятности могу предположить, что если вы оставите себе по одному девайсу на проекте/у тестировщика, вы ничего особо не потеряете в качестве, зато сильно ускоритесь в тестировании.
Естественно мы не просто "встречаем" баги, в этом как раз и суть адекватного отслеживания контроля качества и использования инструментов, которые я перечислил в статье. У нас ведь как раз есть конкретная цель поиска отклонений в зависимости от модели и ОС. В данном случае, ни один из багов не будет абстрактным.
Оставить по одному девайсу у тестировщика можно, но например если у всех тестеров будет одни и те же девайсы с неизменной ОС, это менее продуктивно для нас. Даже в таком случае, оставьте у тестера по одному девайсу, но сделайте это максимально эффективно, опираясь то, как широко можно покрыть наше тестирование в зависимости от моделей и ос.
Мы все же используем и предлагаем возможности комбинации, так как определенный пул девайсов (как реальных, так и симуляторов) позволяет покрывать конкретные проверки и ничем нам конкретно не замедляет тестирование. Наоборот кое-где заранее ускоряет выявлять определенные сценарии и эдж-кейсы. Опять же, все зависит от специфики проекта. Но спасибо за совет :)
Тестирование мобильных и веб-приложений: как избежать фейлов при планировании