nadezhda_potaenko

Ключевые слова: RSpec, Cucumber, Appium.

 

Как человек практикующий Ruby настоятельно не рекомендую использовать его для автоматизации тестирования, если есть выбор. Он прекрасен, но не распространен. Мэйнстримом нынче является Java.

Дело в том, что вместо Appium планируется использовать Calabash, а с ним в связке пойдет только Ruby. Он не мейнстримный абсолютно, это факт. Потому я и пытаюсь найти какие-то ресурсы, которые на практике помогли начать его применять для тестирования мобилок. 

Диаграмма нужна для того, чтобы наглядно показывать (подсказывать), какие состояния есть в системе и какие переходы возможны между ними.

Если читабельность падает, лучше разделить одну диаграмму на несколько (верхнеуровневая и отдельные кусочки) или что-то объединить.

 

Например, если говорить о телефонах, то есть возможность вернуться назад. Любой переход может обломать:

— входящий вызов;

— севший аккумулятор;

— оборвавшееся соединение;

— push-сообщение от игрушки;

— ....

 

Но если рисовать весь этот простор мысли, диаграмму только захламим. Причем это фактически "копипаста", то, что можно проверить на любом приложении. А вы ведь хотите отобразить именно уникальные состояния вашего ПО. Я бы рисовала именно их. "Назад" телефонную можно добавить, если этот переход важен или он возвращает нас в неожиданное место =)

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

Это как аналог кнопки Back в браузере, поэтому просто добавь в чек-лист

Так и сделаю. Тоже склоняюсь к этому варианту.

Проверять вообще все не надо :)
Вы правильно думаете, что проверять надо только наиболее приоритетное.

Надо определить ограничение и исходить из него.
Это могут быть:
1. Время
2. Пройденные бизнес-сценарии, юз-кейсы, тест-сценарии, тест-кейсы итд.
3. Требования к качеству продукта
4. Стоимость обнаружения ошибки (которая выше потенциальных убытков от ее необнаружения)
и пр.

Один из возможных вариантов действий:
1. Определяем наши ограничения по времени
2. Определяем наиболее критичные сценарии
3. Составляем по ним тесты, прогоняем.
4. Находим менее приоритетные сценарии
5. Составляем тесты прогоняем.
6. Повторяем пункты 4-5, пока не закончится время.

В ходе выполнения тестирования вы можете и не упереться в нехватку времени, если вдруг поймете, что все основные сценарии пройдены, и дальше тестировать будет уже неэффективно - мы придумаем еще 30 тестов, выполним, и вдруг выяснится, что нельзя зарегаться с иероглифами в email на портале lada-kalina-sport2.spb.ru :) Результат этого теста нам как-то не особо важен.

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