При тестировании Android-приложений можно часто столкнуться с проблемами, возникающими при переходе приложения из одного состояния в другое. Так, например, нередки утечки памяти при сворачивании и разворачивании приложения, или краши после ухода телефона в спящий режим.
Конечно, такие баги так или иначе находятся, даже если их не искать специально. Однако для обеспечения действительно высокого качества тестируемых приложений нужно чётко осознавать, почему подобные ошибки возникают, и как их искать. А для этого необходимо понимать, как происходит процесс изменения состояний в Android.
Android-программистам эта тема хорошо известна под названием Android Activity Lifecycle, или жизненный цикл операции. Конечно, тестировщикам, даже продвинутым, вовсе необязательно разбираться в данном вопросе полностью, однако базовое его понимание может сильно упростить жизнь и ускорить тестирование. Для того, чтобы показать, как это работает, мы записали небольшое видео.
Если бы я не был фанатом шопинга через сеть ранее, я стал бы им несколько лет назад, стоя в очереди в большом универсальном магазине в час пик леденящей Черной Пятницы в районе западных гор. Мы с женой прибыли незадолго до полуночи, чтобы избежать основной толпы у дверей, уверенные, что то, что нам нужно, еще будет в магазине.
Этого не было.
В попытке оправдать ночное стояние у дверей, лед, снег и агрессивных водителей по дороге к магазину, мы купили пару дешевых детских пижам, уродливые носки, и куклу в помятой коробке. С нашим грузом мы проследовали в конец магазина и встали в бесконечную очередь ожидать расплаты за покупки, которые мы на самом деле не хотели совершать.
Мы ждали час или два, и я понял, что я прекрасно мог воспользоваться онлайн-магазином через свой Android-телефон. Еще до того, как мы дошли до кассы, я заказал все, что нам было изначально нужно. На будущий год я провел Черную Пятницу, завернувшись в одеяло, с кружкой горячего шоколада в одной руке и ноутбуком в другой. Мои ожидания насчет опыта работы онлайн постоянно растут.
Ожидания от онлайн-опыта постоянно растут
Вспоминая этот опыт, я понимаю, что опыт покупок онлайн был очевидно лучше, нежели физически в магазине, но он не был идеален. Сайт не был оптимизирован для мобильных телефонов, и несколько раз мне приходилось начинать все сначала, потому что сайт выдавал мне ошибку.
Сегодняшние потребители, конечно, чувствуют себя намного лучше, когда делают покупки онлайн – сайты чисты от лишней информации, в них легко ориентироваться, и они оптимизированы под мобильные устройства. Если ожидания не оправдываются, то найти сайт, который их оправдает, займет всего несколько кликов мыши. Это особенно верно в праздники, когда покупатель не любит ждать и ожидает, что все будет работать как следует.
Мы, как разработчики, дизайнеры и тестировщики, обязаны как профессионалы предоставлять нашим пользователям наилучший возможный опыт, когда они взаимодействуют с нашим онлайн-представительством. Если мы не можем этого добиться, особенно во времена высокого трафика (например, в праздники) – это неизбежно выльется в отток потребителей и повлияет на доходы компании.
очень маленькое (0,00000000000000000000000000001);
...
Тестировщики кивают головами и говорят — «Все понятно!». А потом им предлагают строковое поле и все, ступор о_О
Что вводить в строку? Символы русские, английские, спецсимволы, циферки, перемешал — готово! Но так и робот может проверить, тестировщик то зачем?)) И как вы отловите баги, когда имя “Иван” считается некорректным, потому что распространенное? (А такое бывает — пруфлинк, поиск по «Иванов Иван Иванович»)
Тренер Ольга Назина подготовила пример тестирования поля «Имя» для своих студентов — смотрите и вдохновляйтесь! :) Столько уникальных для поля тестов, а ведь казалось бы, простая строка...
Это выдержка из лекции про классы эквивалентности курса «Техники и инструменты поиска и оформления дефектов». Без знания о классах эквивалентности и граничных значениях никуда, особенно при поиске багов. Поэтому мы сделали отдельную тему для отработки навыка. Приходите, будет интересно :)
После каждого тренинга мы просим участников написать отзыв -- что понравилось, что не понравилось. Это помогает нам в следующих тренингах не повторять ошибок и делать их лучше.
С отзывами учеников первой группы курса можно познакомиться по ссылке.
Кроме того, по уже сложившейся традиции после создания нового тренинга и завершения работы первой учебной группы Алексей Баранцев пишет “отзыв” со стороны тренера. И это тоже позволяет проанализировать возникшие проблемы, чтобы в следующий раз их избегать и делать тренинги ещё качественнее.
По нашим планам должно было получиться 12 занятий по 45 минут. Но на самом деле объём записанного материала получился в полтора раза больше. Информации действительно так много.
Но цену мы решили пока не поднимать :)
2. В начале курса мы даём участникам анкету, в которой среди прочего предлагается оценить свои навыки программирования по пятибалльной шкале. Результат оказался неожиданным -- средняя оценка примерно 3 балла.
При этом та же самая анкета показала, что почти 70% участников имеют практический опыт использования Selenium. Это вызвало некоторые опасения при подготовке заданий для самостоятельной работы. С одной стороны, они должны были быть достаточно сложными, потому что большинство участников уже работало с инструментом и простые задания будут скучны. С другой стороны, они не должны были требовать хороших навыков программирования. Насколько можно судить по результатам выполнения заданий и обсуждению в чате учебной группы -- это сделать удалось. Задания достаточно сложные, для их выполнения нужно хорошо знать Selenium (то есть внимательно смотреть и слушать лекции), но с точки зрения программирования они весьма просты.
На конференции CAST 2015 Иоана Сербан читала доклад про "Взять под контроль ваше тестовое окружение". Это захватывающая и интересная история ее личного опыта с тест-окружениями. Посмотрите запись доклада, если еще ее не видели.
Я выбрала презентацию Иоаны как основу для недавней сессии по обмену знаниями о тестировании в своей организации. Так как мы все еще работаем как распределенная команда, не очень-то практично собирать всех тестировщиков в одном месте физически, чтобы делиться идеями. Взамен я попросила их посмотреть доклад Иоаны в свободное время, а потом обсудить его во время дискуссионной сессии через онлайн-групповой чат.
За нашими обсуждениями иногда трудно уследить – множество людей печатает одновременно, однако мы подняли ряд любопытных вопросов. Мы покрыли четыре темы: стабильность нашего билда, техники для автоматизации тестов, ключевые особенности наших окружений, и люди, с которыми мы работаем над тестовыми окружениями.
Для тех, кто еще новичок в написании тестовой документации, будет интересно посмотреть выступления, в которых докладчики рассказывают об особенностях роли тест-дизайнера.
Вы можете узнать о методиках, которые используют в работе более опытные коллеги, посмотрев видеозаписи докладов с конференции QA Fest 2016.
Неплохая идея – определить и отслеживать метрики, чтобы держать автоматизационные усилия под контролем и принять меры, если метрики скажут вам, что ваши действия не приносят нужных результатов. Еще важнее возможность купаться в славе, если они-таки их приносят! Но что такое хорошие метрики тест-автоматизации? В этой статье я рассмотрю некоторые метрики, которые считаю полезными, и некоторые, без которых мир автоматизаторов вполне может обойтись. Отмечу, что я не собираюсь перечислять ВСЕ метрики, которые используются в автоматизации, но надеюсь, что упомянутые мной укажут вам верное направление.
Итак, что, с моей точки зрения, может быть полезной метрикой для отслеживания эффективности и/или результатов усилий по автоматизации?
Все ли вы знаете о техниках поиска багов? Как найти то, что мелькнуло лишь раз? Как воспроизвести проблему по невнятному описанию пользователя «У меня все сломалось»? Какие предположения строить? Что уточнять?
В рамках курса мы создали специальный «бажный» сайт для тестирования. Внедрили туда 20 разных по типу ошибок. Чтобы их найти, придется применять разные техники и инструменты:
— Собрать логи.
— Проверить консоль JS.
— Найти граничные значения.
— Пройтись по туру, отмененному из-за дождя.
— Проверить разные браузеры.
— Убрать ограничение, установленное на клиенте.
— …
Сервер поднят на linux-е, куда у студентов есть доступ на чтение логов. Это позволяет применить полезные в будущем инструменты:
Putty — снять статистику, последить за логом
WinSCP — забрать лог с сервера
Grep — найти нужный стек в логе (linux)
Cygwin — найти нужный стек в логе (windows)
Еще на курсе будут использоваться:
Postman — послать POST-запрос на сервер
Perlclip — сгенерить большую строку текста
Курс запускался в два этапа — год назад вышла первая версия на 4 занятия. Мы рассказывали только то, что не зависит от “веб — не веб, линукс — не линукс” итд. Как искать, локализовывать и оформлять задачи. Материала было много! По отзывам студентов:
Ого, сколько материалов и заданий! Скучать не придется. А текст задания: "Меня обманули и обесчестили, я разворачиваюсь и ухожу." развеселил))
Но курс должен не только веселить, но и учить. Общаясь с ребятами, мы поняли просто “найти и локализовать” неинтересно. Это ведь все умеют, мы занимаемся этим каждый день.
Интересно другое:
— Как понять, кто именно сломался, если системы интегрированы?
— Как доказать подрядчику, что проблема именно на его стороне?
— Что делать, если ошибку уже пропустил?
Или технические штуки, которые пригодятся в дальнейшем:
— Залезть на сервер linux, найти нужный лог, изучить стек-трейс. — Перехватить сообщение в консоли разработчика. — Прочитать ответ, пришедший с сервера. — Найти баг кеширования на сервере.
Все это теперь есть! Мы расширили курс, теперь там девять уроков вместо четырех. И 27 домашних задания — чтобы как следует закрепить материал. Приходите к нам, если хотите взглянуть на “обычный” процесс поиска и локализации багов по новому.
Друзья, поздравляем вас с чудесным и даже немного волшебным праздником - с Новым годом!
Желаем вам всего самого лучшего в следующем году. Пусть все хорошее, что не успело произойти в 2016-м, обязательно случится в 2017-м. Желаем вам здоровья, удачи, любви и пусть самые близкие всегда будут рядом!
Новый год - это всегда планы, мечты и надежды. Мы желаем, чтобы в 2017-м вы могли воплотить в жизнь даже самые дерзкие начинания. Пусть для этого всегда найдутся силы и желание! А мы со своей стороны надеемся еще больше помогать вам в реализации профессиональных планов.
С наилучшими пожеланиями, команда Software-Testing.Ru
Время идет, появляются новые инструменты автоматизации тестирования. Влияет ли это на рабочий процесс? Конечно!
Что делать в таком случае: переписывать тесты с нуля или достаточно только немного подправить их? А как это сделать, ничего не сломав? Сколько времени придется потратить на доработку? Вопросов немало.
Коллеги на конференции QA Fest 2016 рассказали об эволюции автоматизации и поделились своим опытом актуализации автотестов:
Дмитрий Химион - Векторы развития систем автоматизации тестирования
Яков Крамаренко - Укрощаем фреймворки-динозавры используя NSelene
Иван Пашко - Теория Дарвина в тестах. Эволюция Wait-ов
Все ли вы знаете о техниках поиска багов? Как найти то, что мелькнуло лишь раз? Как воспроизвести проблему по невнятному описанию пользователя «У меня все сломалось»? Какие предположения строить? Что уточнять?