За последние пять лет, по данным Google Trends, значительно вырос интерес к тестированию API. Такая тенденция отражает сдвиг парадигмы в сторону web и мобильных приложений, а также разделение серверных служб и пользовательских интерфейсов.
Тестирование API - это тестирование, которое включает в себя проверку и валидацию API и веб-служб. В отличие от традиционного тестирования, в котором основное внимание уделяется функциональности графического интерфейса и взаимодействию с конечным пользователем, тестирование API проверяет программные интерфейсы, находящиеся на среднем уровне приложения, которые используются разработчиками (например, headless или GUI-less компоненты, обычно невидимые для конечных пользователей).
В обычном web или мобильном приложении, Web-API могут объединять между собой различные компоненты, такими компонентами могут быть особенные представления или пользовательский интерфейса c веб-сервером. Тем самым, автоматизация тестирования API становится все более привлекательным выбором в современном тестировании программного обеспечения. (Подробнее о тестировании API)
Что бы успешно реализовать тестирование API, команды должны иметь хороший набор инструментов, соответствующих конкретным требованиям. Однако это сложная задача, согласно нашему опросу более чем 2200 профессионалов в области программного обеспечения. Отчасти проблема заключается в том, что выбранный инструмент по началу вроде бы и справлялся со своей задачей, однако, проблемы начинаются, когда приходит время интегрировать его с уже существующими инструментами и процессами в долгосрочной перспективе.
Чтобы помочь вам разобраться, какие же все-таки инструменты лучше всего подходят для автоматизации тестирования API, в этой статье для вас будет представлены обзор и сравнение трех популярных инструментов для тестирования API: SoapUI, Postman и Katalon Studio. SoapUI и Postman специализируются исключительно на тестировании API, в то время как, Katalon Studio предоставляет полный набор инструментов для тестирования API, Web и мобильных приложений. (Подробнее о 5 лучших и бесплатных инструментах для тестирования API)
Поговорим про интернет вещей. Согласно Gartner, в мире уже уже используется более 7 миллиардов IoT-устройств, а к 2020 году превысит 20 миллиардов. Как тестировать эти устройства, такие как холодильники, самостоятельно заказывающие продукты через интернет, или самоуправляемые автомобилями — вот вопрос, который будут задавать себе их производители ближайшие несколько лет.
В Перфоманс Лаб этим вопросом тоже задались и провели тестирование простого IoT устройства на платформе Renesas. Получилось очень интересно, решили снять небольшое видео, на котором Дмитрий Химион, подробно рассказывает о нашей технологии и показывает крутые мигающие лампочки.
Надеемся, что этот материал поможет многим командам, найти свой подход к тестированию умных устройств.
В нашем блоге, равно как и внутри компании, большую часть времени мы обсуждаем одну тему: тестирование и его организацию. Мы часто пишем, как применять те или иные подходы к анализу качества продукта, много времени уделяем автоматизации тестов, постоянно следим за различными конференциями — в общем, все время пытаемся понять, как улучшить нашу работу и принести больше пользы конечным пользователям. Нам интересно писать про эти задачи, а статистика посещений материалов показывает, что и читать их тоже бывает полезно.
Исходная ситуация: крупный клиент со сложным ПО, тестированием которого занимается команда в 20+ специалистов. Клиент хочет, чтобы каждый месяц мы отчитывались о состоянии его продукта и проделанной нами работе. В общем, стандартная для рынка ситуация. Но в какой-то момент заказчик решил изменить формат отчетности. Вместо одного свободного, нас попросили разбить его на сложные категории, позволяющие сразу восьми разным департаментам понять, какая работа, важная именно для них, была проделана за отчетный период. В итоге мы имеем не один отчет, а сразу восемь, на подготовку которых уходит от 25 до 40 часов. Так стандартная для рынка ситуация превратилась в ночной кошмар.
Наше решение: вспомнить, что автоматизировать можно не только тест-кейсы, но и бизнес-процессы. В июле отчет, на который обычно уходило несколько дней и, примерно, 100 кружек кофе для разъяренных менеджеров и тестировщиков, мы подготовили за 10 минут. И решили, что впредь на всех крупных проектах бизнес-процесс «клиент — тестирование — отчетность» должен быть автоматизирован. Хотите узнать, какой эффект оказывает отказ от бесконечных таблиц, справок, сводных табелей на процесс тестирования и отношения с клиентами? Тогда следуйте за нами. Но начнем мы с короткого рассказа-утопии…
Размышляя о новом наборе автотестов, вы наверняка начнете с вопроса, что именно вы собираетесь автоматизировать. Неважно, требует ли автоматизации ваш менеджер, или за нее боретесь вы – прежде чем выбирать инструмент, вам нужно разработать стратегию тестового покрытия.
На решение, что конкретно автоматизировать, влияет множество факторов. Если вы пытаетесь определить масштаб автоматизации изолированно, вы, возможно, наделаете ошибок. Ниже – ряд советов, которые помогут вам мыслить шире и вовлечь в такое обсуждение широкую аудиторию.
Я начал этот цикл статей с программирования, и сделал наиболее распространенную ошибку, которую делают все автоматизаторы – углубился в объяснения, как автоматизировать, вместо того, чтобы рассказать, почему это важно и выгодно для нас (спасибо Джиму Хейзену за то, что он обратил на это мое внимание).
На самом деле я рад, что все произошло именно так, потому что это лишняя демонстрация того, как люди, включая меня, подходят к автоматизации – они просто учатся программировать и ныряют в код, не зная, что они, черт возьми, делают. Делаем шаг назад, переосмысляем…
Еще несколько лет назад к организации автоматизированного тестирования предъявлялось, по сути, лишь одно требование — исключить из большинства рутинных проверок труд человека. Активнее всего автоматизацию внедряли крупные компании, для которых производительность и скорость прохождения тестов редко являлись критическими показателями. Они без особых проблем могли «залатать» деньгами любую дыру в структуре тестов, подключив несколько дополнительных мощных серверов или расширив парк тестовых устройств.
Но рынок быстро меняется: число профессиональных автоматизаторов растет с каждым днем, поэтому не удивительно, что у многих QA-компаний появились выгодные предложения для среднего и малого бизнеса. Сегодня заказать создание 100-200 автотестов могут позволить себе владельцы практически любого небольшого приложения или сервиса. А вот заставить их работать эффективно, не «проглатывая» дорогостоящие ресурсы и не тратя десятки часов на выполнение, — и есть настоящий вызов. В этой статье мы поделимся двумя историями из нашей борьбы за производительность, не упуская трудностей, с которыми столкнулись во время путешествия сквозь мрачный лес прожорливых автотестов.
«Как начать автоматизировать» - первая тема в серии статей. Так как я обещал, я разъясню как для себя, так и для читателей, то, что я знаю про автоматизацию как специфически направленную деятельность со своими целями, поддерживающую тестирование.
Эта серия статей будет:
Короткой, примерно 5 минут на чтение, хотя это очень сложно для меня.
Практической – без воды, только эмпирические, полезные советы.
Основанной на личном опыте и плохих решениях. Я думаю, это очень полезно.
Автор: доктор Vu Nguyen, преподаватель, директор Инженерной службы KMS Technology
Перевод: Колесникова Виктория, инженер-тестировщик компании Bercut, Telegram: t.me/lifeoftesting
Определяющий фактор для успешного применения автоматизации тестирования программного обеспечения - выбор и использование правильного набора средств автоматизации тестирования. Это сложная задача, особенно для тех, кто раньше не сталкивался с автоматизацией тестирования, поскольку на рынке существует очень много инструментов, каждый из которых имеет разные сильные и слабые стороны. Нет инструмента, который бы соответствовал всем требованиям автоматизированного тестирования. Это затрудняет поиск подходящего решения. Узнайте, как правильно выбрать средство автоматизации для вашего проекта из приведенного ниже подробного сравнения Katalon Studio с другими популярными инструментами для автоматизации тестирования на рынке.
В Твиттере широко обсуждалось, кто должен отвечать за создание кода автотестов. Судя по тому, что я читал, люди разбились на два лагеря:
Группа, выступающая за то, что разработчики должны отвечать за создание большей части (если не всего целиком) кода автоматизации. Их основной аргумент в том, что разработчики лучше знают, как программировать, больше знают о структуре кода и его внутренней кухне, и поэтому лучше всего разбираются, как подцепить к нему код автотестов (в отличие от слепых попыток сделать это через пользовательский интерфейс).
Группа, ратующая за то, что тест-автоматизация требует отдельных, занимающихся только этим, инженеров-автоматизаторов, особенно для тестов выше юнит-уровня. Аргументируют это они тем, что для создания и поддержки хороших автотестов нужны специфические навыки, простирающиеся дальше навыков разработки.
В конце позапрошлого года я опубликовал статью, посвященную примерно этой же тематике. Перечитывая ее, я все еще согласен с собственным же мнением (что, безусловно, хорошо). Но пока я размышлял об этом, читал об этом и обсуждал этот вопрос с другими, я выявил несколько тонких (и не только) нюансов – а это тема для отдельной статьи.
Тест-автоматизация очень много для меня значит. Я выбрал эту специальность из множества доступных в поле разработки ПО. Когда я вижу, что она неверно применяется, или когда люди просто не понимают, что это такое – меня это бесит. У меня много вопросов к плохим процессам автоматизации, и сейчас вы узнаете об этом все!
Говорить «Это просто тест-сценарии»
Автоматизация тестирования – это не просто набор тест-сценариев. Это целый арсенал технологий, требующий дизайна, интеграции, и опыта. Разработка тест-автоматизации – это отдельная область. Когда вы говорите, что это всего лишь набор тест-сценариев – вы унижаете и оскорбляете ее. Это обесценивает те усилия, которых требует автоматизация, ведет к плохому масштабированию работы и отношениям «они против нас» между разработкой и QA.
