Поговорим про интернет вещей. Согласно Gartner, в мире уже уже используется более 7 миллиардов IoT-устройств, а к 2020 году превысит 20 миллиардов. Как тестировать эти устройства, такие как холодильники, самостоятельно заказывающие продукты через интернет, или самоуправляемые автомобилями — вот вопрос, который будут задавать себе их производители ближайшие несколько лет.
В Перфоманс Лаб этим вопросом тоже задались и провели тестирование простого IoT устройства на платформе Renesas. Получилось очень интересно, решили снять небольшое видео, на котором Дмитрий Химион, подробно рассказывает о нашей технологии и показывает крутые мигающие лампочки.
Надеемся, что этот материал поможет многим командам, найти свой подход к тестированию умных устройств.
Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.
Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:
Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).
Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно здесь и здесь).
Тестировщик всегда работает в условиях недостатка времени: беклог не уменьшается, релиз на носу, а протестировать нужно еще многое. Чтобы обеспечить качество продукта, нужно постоянно повышать эффективность собственной работы. Один из способов - освоить некоторые инструменты, облегчающие рутинные действия в тестировании.
Когда вы отчитываетесь о тестировании, используя метрики, это может привести к незапланированным последствиям. Какие метрики мы регулярно используем для отчетов, и какую информацию почерпнут из них заинтересованные лица? Давайте детально рассмотрим несколько реальных примеров.
95% тестов прошло, 1% упал, 4% не прогонялись
Метрики "прошло/упало" очень популярны в традиционных отчетах о прогрессе тестирования. Представьте на минутку, что вы продакт-оунер, и ваше слово – решающее в вопросе, выпускать ли продукт в релиз.
Четыре месяца назад мы запустили курс “Автоматизатор мобильных приложений” о том, как построить фреймворк тестирования мобильных приложений на Android и iOS с нуля без значительного опыта в мобильной автоматизации. На тот момент в нем было всего пять уроков. В них описывались создание и конфигурация фреймворка тестирования на JUnit и Appium, а также базовые моменты настройки окружения. Для начала этого объема было достаточно, но у курса был явно больший потенциал.
И действительно, он оказался востребованным, а в своих отзывах и личном общении ученики сообщили нам множество идей для развития. Поэтому мы стали расширять курс в соответствии с их запросами.
В первую очередь мы получили очень много просьб о создании урока по Continuous Integration, поэтому мы занялись им сразу же во время первого запуска. К концу курса мы создали урок об интеграции нашего фреймворка с Jenkins — популярным инструментом CI. Как оказалось, многим ученикам не хватало именно этих знаний для того, чтобы применить навыки тренинга в реальной жизни — и теперь они смогли их получить.
Затем мы поработали над слишком объемным уроком по iOS. Он был в полтора раза больше остальных уроков, а закрытость системы Apple добавила сложностей в конфигурации. Ученики тратили много времени на то, чтобы настроить фреймворк — и часто не успевали перейти к написанию кода. Поэтому мы разделили этот урок на два, чтобы дать ученикам больше времени на работу. В результате количество успешно сданных домашних работ выросло, и ученики остались довольны.
Многие спрашивали нас о тестировании Mobile Web — ведь зачастую у мобильного приложения есть и веб-версия. Мы сделали отдельный урок, в котором рассказываем, как подключить к нашему фреймворку Selenium WebDriver, как переключаться между ним и Appium, а также описываем некоторые специфические моменты работы с веб-приложениями на мобильных устройствах.
Наконец, очень много вопросов поступало от новичков, которые интересуются темой автоматизации мобильного тестирования. Изначально курс создавался для опытных автоматизаторов, ведь для написания фреймворка требуются специфические навыки. Но при более детальном рассмотрении выяснилось, что этот тренинг не требует значительных знаний в области автоматизации или программирования — достаточно объяснить несколько базовых концепций, чтобы ученики смогли ими руководствоваться. Поэтому мы выпустили специальный урок, где подробно рассматриваем все моменты, необходимые для работы с JUnit, Java и Appium. Теперь на курс могут записываться и люди без опыта автоматизации вовсе — что, конечно, значительно расширяет его аудиторию.
Как видите, мы постоянно ищем новые возможности для развития курса, и часто обращаемся за идеями к нашим ученикам.
Посмотреть программу курса “Автоматизатор мобильных приложений” и записаться на него можно по ссылке. Очередная улучшенная и расширенная по результатам отзывов версия курса стартует уже 31 октября.
Погуглите "как писать тест-план" – и вы увидите множество шаблонов, обязательных атрибутов и обучающих статей. Создать тест-план можно множеством способов, а учесть в нем надо множество факторов, и очень легко еще больше запутаться в вопросе. В итоге люди вставляют в тест-план информацию просто для того, чтобы максимально обезопаситься: ведь лучше включить ее туда, чем нет, не так ли? Она же может быть важна для кого-то правда же? Но когда план написан, ревью пройдено, он отредактирован, финализирован и отправлен заинтересованным лицам – зачастую оказывается, что практически никто его и не читал.
Очень раздражает, когда тратишь кучу времени на длинную подробную тест-документацию, которую в результате никто не читает и не использует. Проблема в том, что у менеджмента зачастую нет времени на чтение гигантских документов – менеджмент хочет знать только самое важное.
Джеймс Уиттакер писал о "Десятиминутном тест-плане" несколько лет назад, описывая задачу, которую он ставил перед своей командой. Цель задания состояла в том, чтобы добиться полезной тест-документации как можно быстрее. Давайте посмотрим на это с другой точки зрения, но с похожей целью. В этот раз минимизируем не время, а масштаб. Как же сократить тест-план до одной странички?
В нашем блоге, равно как и внутри компании, большую часть времени мы обсуждаем одну тему: тестирование и его организацию. Мы часто пишем, как применять те или иные подходы к анализу качества продукта, много времени уделяем автоматизации тестов, постоянно следим за различными конференциями — в общем, все время пытаемся понять, как улучшить нашу работу и принести больше пользы конечным пользователям. Нам интересно писать про эти задачи, а статистика посещений материалов показывает, что и читать их тоже бывает полезно.
Исходная ситуация: крупный клиент со сложным ПО, тестированием которого занимается команда в 20+ специалистов. Клиент хочет, чтобы каждый месяц мы отчитывались о состоянии его продукта и проделанной нами работе. В общем, стандартная для рынка ситуация. Но в какой-то момент заказчик решил изменить формат отчетности. Вместо одного свободного, нас попросили разбить его на сложные категории, позволяющие сразу восьми разным департаментам понять, какая работа, важная именно для них, была проделана за отчетный период. В итоге мы имеем не один отчет, а сразу восемь, на подготовку которых уходит от 25 до 40 часов. Так стандартная для рынка ситуация превратилась в ночной кошмар.
Наше решение: вспомнить, что автоматизировать можно не только тест-кейсы, но и бизнес-процессы. В июле отчет, на который обычно уходило несколько дней и, примерно, 100 кружек кофе для разъяренных менеджеров и тестировщиков, мы подготовили за 10 минут. И решили, что впредь на всех крупных проектах бизнес-процесс «клиент — тестирование — отчетность» должен быть автоматизирован. Хотите узнать, какой эффект оказывает отказ от бесконечных таблиц, справок, сводных табелей на процесс тестирования и отношения с клиентами? Тогда следуйте за нами. Но начнем мы с короткого рассказа-утопии…
Размышляя о новом наборе автотестов, вы наверняка начнете с вопроса, что именно вы собираетесь автоматизировать. Неважно, требует ли автоматизации ваш менеджер, или за нее боретесь вы – прежде чем выбирать инструмент, вам нужно разработать стратегию тестового покрытия.
На решение, что конкретно автоматизировать, влияет множество факторов. Если вы пытаетесь определить масштаб автоматизации изолированно, вы, возможно, наделаете ошибок. Ниже – ряд советов, которые помогут вам мыслить шире и вовлечь в такое обсуждение широкую аудиторию.
