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

nadezhda_potaenko

Регистрация: 04 июн 2014
Offline Активность: 23 дек 2017 13:59
-----

Мои темы

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

12 июля 2016 - 10:23

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

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


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

20 апреля 2016 - 07:21

Добрый день!

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

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

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

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

 


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

30 марта 2016 - 15:09

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

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

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

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

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