Мелочи

Я хочу рассказать о тех мелких приемах и мелочах которыми я пользуюсь и на которые обращаю внимание при тестировании приложений на iOS:

Начнем с клавиатуры

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

так как для ввода e-mail'a (если он не содержит цифр) не потребуется переключатся на цифровую клавиатуру чтобы набрать "@"

Если же требуется воод цифровых значений то и клавиатура должна быть цифровой:

Так же когда планируется ввод данных в несколько полей по порядку то достаточно удобным решением являются кнопки переключения между полями над клавиатурой:

при этом, клавиатура не должна закрывать активное поле вводе.

Так же, иногда, бывает что кнопка Return на клавиатуре выполняет функцию кнопки Done - это не совсем правильно.

Итог: нужная клавиатура в нужном месте, мелочь а приятно!)

Нахождение Steps to replicate для багов

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

Итог: находит тот кто ищет!

Нахождение багов

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

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

Итог: будьте рациональны, используйте свой свой user experience!

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

Вспомню еще что то - дополню.

Пока всё) 

Тестирование апдейта приложений на iPhone/iPad

Здравствуйте!

Темой первого поста будет наболевшее… Тестирование апдейта приложений. До того как приложение попадает на App Store мы тестируем билд приложения которые сразу заливаем к себе на девайс, ну а что если это, например, версия 1.1? Мы кидаем себе на девайс этот билд и тестируем, потом тестируем еще и еще, вот вроде бы все хорошо, билд релизится и начинают приходить отзывы в духе "У меня удалились все данные, ужас!!!" - а как известно такие отзывы плохо влияют на нервную систему тестировщиков, PM'ов и еще многих людей, не говоря уже о рейтинге продукта и репутации.

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

В интеренетах я нашел крайне мало информации по этому поводу, так что попробую написать свой вариант мануала.

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

Итак сам процес апгрейда:

1. Сначала мы устанавливаем более раннюю версию приложения (v. 1.0)

2. Запускаем его на девайсе и дальше уже в зависимости от приложения вносим определенные данные.

Предположим что у нас какой нибудь Task Manager, то есть у нас есть какие то таски - выполненные и невыполненые, напоминания - сработавшие или которые еще должны сработать, возможно еще какие то специфические настройки самого приложения - все это нужно добавить в наше приложение v. 1.0  чтобы увидеть остается ли все на местах после апдейта. 

3. Устанавливаем апдейт - просто перетаскиваем билд v. 1.1 в iTunes, появится окно в котором нужно нажать "Заменить"

4. Теперь просто синхронизируем iTunes библиотеку с девайсом 

Если все прошло хорошо то на девайсе уже должна быть версия 1.1 

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

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

Есть еще одна ситуация связанная с апдейтами и In-App Purchase. Вы тестируете приложение у которого есть Lite версия с возможность купить через In-App Purchase Про версию. Допустим пользователь скачал Lite версию, в ней же купил Pro версию и потом выходит апдейт Lite версии приложения, он апдейтится и все что он покупал пропадает, пользователь расстроен и зол (и вполне понятно почему)!

Как воспроизвести это в тестовой среде:

1. Устанавливаем приложение v. 1.0

2. Покупаем Pro версию

3. Кидаем в iTunes билд v. 1.1 Lite версию!

4. Синхронизируем

5. Проверяем остался ли в приложении функционал Pro версии

Ну вот пока и все)

Спасибо за внимание!