Be mobile

В последнее время в России появляется все больше и больше приложений для мобильных телефонов, написанных серьезными компаниями. Конечно же, не стоит в стороне и Яндекс, предлагающий своим пользователям целый веер мобильных приложений для различных платформ. А если есть программисты, пишущие приложения, то должны быть и тестировщики этих приложений. В Яндексе, например, существует целый отдел тестирования мобильных приложений. А меж тем, видя в условиях вакансии «тестирование мобильных приложений», многие закрывают ее, не вчитывась: кому-то кажется неинтересным ограничиваться несложными программами для телефонов, а кому-то страшно пробовать что-то настолько новое. И совершенно зря: мобильное ПО не менее интересно в тестировании, чем обычное, а новая предметная область – это всего лишь новая предметная область. Хотя в ней, конечно же, есть свои подводные камни.

Казалось бы, ничего кардинально отличающегося в работе тестировщиков десктопных и мобильных приложений быть не должно: вот тебе программа, вот тебе требования – сиди и тестируй. Но не тут-то было. Простая настройка интернета на каком-нибудь Sony Ericsson или, не дай Бог, Blackberry может оказаться для новичка настоящим квестом. Рискну проанализировать те особенности тестирования мобильного ПО, с которыми так или иначе придется столкнуться любому тестировщику, решившему перейти от десктопов к мобильникам. Для удобства и простоты изложения буду называть далее смартофоны и коммуникаторы – телефонами.

Итак, что стоит иметь в виду, берясь за тестирование мобильного ПО:
1. Множество платформ: Windows Mobile, Symbian, iOS, Blackberry, Android, Bada, Linux, Maemo, старые добрые java-мобильники... и у каждой платформы множество версий, и на каждой платформе работают разные телефоны (каждый со своей хитрой прошивкой), и даже если у вас есть два одинаковых телефона – у них могут быть разные версии прошивки или разные особенности «железа» (скажем, если одна и та же модель была выпущена дважды с разницей в год, и оба телефона были прошиты одинаково – это не гарантирует их одинакового поведения в работе). Сложность конфигурационного тестирования по сравнению с десктопами поражает воображение – и количественно, и качественно.
2. Баги сложнее локализовать. Представьте себе – использовать дебаггер как правило невозможно, так что отлов «случайного» бага может занять куда больше времени, чем кажется на первый взгляд. К тому же, телефоны имеют свойство «глючить» независимо от ваших действий. И если баг повторяется только на одной конкретной модели телефона – то остается лишь надеяться, что он повторится на аналогичном телефоне у программиста. Или что программист сумеет понять по коду, что здесь может пойти не так. Потому что – сюрприз! – второго точно такого же телефона в тестовом стенде у вас, скорее всего, нет.
3. Следует уделять повышенное внимание юзабилити. Мобильники – это то, что часто используется на ходу, в не слишком подходящих для того местах. У пользователя не всегда есть возможность задействовать обе руки на управление программой. К тому же, у любого телефона экран ощутимо меньше, чем у самого маленького монитора. Если приложение будет неудобным в использовании, то вряд ли пользователи станут тратить на него свое время и место в памяти своего телефона.
4. Ваше официальное рабочее место выглядит особенно забавно. :-) Куча проводов, телефонов, зарядок, USB-хабов, GPS-навигаторов, сим-карт, переходников... уф! Вставай осторожнее, товарищ тестер, иначе все это богатство улетит вместе с тобой.
5. Зато неофициальным рабочим местом может стать что угодно. Конечно, Яндексу вообще в этом плане свойственна мобильность: ноутбук и WiFi сеть по всем офисам позволяют работать хоть в коридоре. Но когда основной необходимый инструмент – мобильник, подвижность возрастает в разы. Тестировать можно где угодно, включая дом и общественный транспорт. Более того – стоит переместиться в новое место – как срабатывает ассоциативность мышления, и в голову начинают приходить свежие идеи. Очень удобно. :-)
6. Менее сложные алгоритмически приложения, более завязанные на конкретное железо. Выписываю это отдельно от конфигурационного тестирования (первый пункт), поскольку даже тестируя на одном единственном телефоне, следует помнить о зависимости поведения программы от этого самого железа: проверять реакцию на все клавиши, на принятие звонка или сообщения во время работы программы, на обрыв связи, на включение фотокамеры, и т.д. и т.п. в зависимости от конкретного телефона.
7. Сложность автоматизации тестирования. Конечно, можно писать юнит-тесты. Конечно, какие-то отдельные алгоритмические решения можно проверить на эмуляторе – и написать к эмулятору фреймворк для тестирования. Но в итоге привязанность к железу все равно вынудит перепроверить совершенно всю функциональность на настоящих телефонах – так что существенного сокращения рутинного тестирования такая автоматизация не принесет. А писать полноценные автотесты и запускать их непосредственно на телефонах либо невозможно, либо слишком трудозатратно, чтоб оно того стоило.

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

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

(с) циркуляр Морского технического комитета №15 от 29 ноября 1910 года

Философия JIT

Вообще, это подход к управлению чем-либо, то есть, штука достаточно универсальная.
JIT - Just In Time, вкратце может быть описана как "делать только то, что нужно, с наименьшими затратами". Минус перфекционизм и прочее метание понтов - сюда же. На фоне кризиса и необходимости постоянно повышать эффективность труда - штука крайне актуальная. Впору распечатывать и на стенку вешать.

JIT включает в себя:
- постоянное улучшение:

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

- сведение издержек к минимуму. Издержки бывают семи видов:

• издержки перепроизводства (сиречь тот самый перфекционизм)
• издержки на время ожидания между разными фазами процесса
• издержки на транспортировку
• издержки на обработку
• издержки на инвентаризацию
• издержки на перемещение
• потери от дефектов в конечном продукте.

(с) переведено-пересказано с сайта Кэмбриджского Университета