Перейти к содержимому

Публикации nadezhda_potaenko

7 публикаций создано nadezhda_potaenko (учитываются публикации только с 30 марта 2023)


#152643 Ruby для тестирования мобильных приложений

Отправлено автор: nadezhda_potaenko 13 июля 2016 - 02:12 в Автоматизированное тестирование

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

 

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

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




#152613 Ruby для тестирования мобильных приложений

Отправлено автор: nadezhda_potaenko 12 июля 2016 - 10:23 в Автоматизированное тестирование

Уважаемые форумчане, имеющие опыт разработки автотестов на ruby под Android и IOS, поделитесь, пожалуйста, полезными ресурсами, ссылками на книги, если таковые имеются, именно по данной специфике применения языка. 

Нагуглила много информации по ruby, в целом, в классическом подходе, но есть надежда, что существует информация о его применении в тестировании.




#150644 Диаграмма состояний и переходов

Отправлено автор: nadezhda_potaenko 20 апреля 2016 - 10:45 в Тест-дизайн и ручное тестирование

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

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

 

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

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

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

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

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

— ....

 

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

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




#150635 Диаграмма состояний и переходов

Отправлено автор: nadezhda_potaenko 20 апреля 2016 - 09:08 в Тест-дизайн и ручное тестирование

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

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




#150631 Диаграмма состояний и переходов

Отправлено автор: nadezhda_potaenko 20 апреля 2016 - 07:21 в Тест-дизайн и ручное тестирование

Добрый день!

Буду признательна за совет по построению диаграммы состояний и переходов.

У меня есть весьма объемный процесс, который требуется проанализировать и декомпозировать при помощи диаграммы состояний и переходов. Диаграмма, в моем случае, тоже получилась весьма объемной. Но уже после построения я вспомнила о важном факторе, который на ней не отразила. У меня мобильное приложение на android, соответственно, для каждого из состояний будет доступен переход на шаг назад, в предыдущее состояние, по нажатию аппаратной кнопки "Назад". Попыталась отразить это на диаграмме: получилось большое количество стрелок, путающихся друг с другом. В общем, читабельность диаграммы пострадала.

Как бы вы поступили на моем месте: оставили кучу стрелок "Назад" или не стали их отрисовывать, но в чек-листе написали, что для каждого из состояний проверить переход на 1 состояние назад по нажатию кнопки "Назад"?

Может, у кого-то есть практический опыт?

 




#149930 Как вовремя остановиться?

Отправлено автор: nadezhda_potaenko 30 марта 2016 - 15:45 в Тест-дизайн и ручное тестирование

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

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

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

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

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




#149928 Как вовремя остановиться?

Отправлено автор: nadezhda_potaenko 30 марта 2016 - 15:09 в Тест-дизайн и ручное тестирование

Уважаемые гуру тест - дизайна, нужна помощь.

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

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

Сначала я подумала: "Чего проще?" - но чем дольше думала, тем больше путалась. Наверное, я слишком привыкла к знанию всех важных для анализа моментов. А теперь у  меня вызывает бурю сомнений такая вещь: текстовое поле для ввода e-mail. Сначала я кинулась составлять кучу кейсов, с содержанием в имени типографских символов и с нестандартно - длинными доменными частями и т.п. Но потом задумалась.... В реальности, как часто я в жизни сталкиваюсь с тем, что при регистрации в форуме автомобилистов проверяется мой e-mail на корректность так дотошно? Ну, не получу письмо со ссылкой о подтверждении регистрации - сама себе сделаю хуже... И вот с точки зрения здравой логики, мне не кажутся нужными эти 30 проверок несчастного e-mail...
Да, я знаю, правило, что раз ящик черный, то проверять надо все. Но где границы этого "все"?

Как бы вы подошли к такому ящику, чтобы не скатываться до абсурда?