Не буду долго рассказывать про важность исследований целевой аудитории в тестировании — этому посвящена крутая статья в блоге Лаборатории качества. Действительно, можно потратить часы и дни на проверку сценариев, которые не воспроизведутся у конечных пользователей, а важные особенности взаимодействия, напротив, пропустить.
Способов получения информации о ЦА много (например, поговорить с техподдержкой, проанализировать метрики, изучить отчеты рынка и т.д.), но какой бы ни выбрали, в итоге у вас будет набор статистической информации:
Первая категория — мужчины в возрасте 27-35 лет, жители города-миллионника, работающие в сфере ИТ, выходящие в сеть с мобильного устройства марки Pear, увлекающиеся гаджетами, планирующие взять кредит на автомобиль;
Вторая категория — женщины 23-25 лет, матери 1-го или 2-х детей, в декретном отпуске, выходящие в сеть с ноутбука ОС Door, имеющие опыт работы до года, проводящие 35% времени на форумах, планирующих взять кредит на ремонт в ванной комнате.
Запуск коллекции тестов в Postman – это отличный способ быстро протестировать ваше API. Но еще более быстрым способом будет автоматический запуск! Чтобы автоматизировать ваши Postman-тесты, нужно разобраться, как запускать их из командной строки.
Postman использует инструмент запуска командной строки Newman. Это модуль NodeJS, который легко установить через npm (Node Package Manager). Если у вас еще не установлен Node, это легко сделать через https://nodejs.org. Node содержит npm, поэтому после установки Node установить Newman очень легко. Просто откройте командную строку и наберите там следующее:
Меня зовут Елена Расторгуева, я отвечаю за продукт «Фактор» в HFLabs. «Фактор» — чертовски сложный алгоритмический enterprise, он обрабатывает данные в промышленных масштабах.
В статье я расскажу, как мы начинали тестировать «Фактор», как развивали автотесты и почему пришли к самописным фреймворкам.
Раньше, покидая квартиру, вы убеждались, что ваши ключи и бумажник при вас. Сегодня вы в первую очередь проверите, а взяли ли вы смартфон. На него возложено столько ежедневных задач, что мы без него буквальным образом неполноценны.
Согласно данным GSMA, 5 миллиардов людей в мире пользуются смартфонами и мобильными телефонами – это 2/3 населения планеты. Ни одно устройство в истории человечества не может похвастать таким стремительным проникновением на рынок. Мобильные устройства влияют на целые области жизни, а приложения сейчас (явно или неявно) встраиваются в автомобил, часы, браслеты, домашние приборы.
Мобильные устройства вездесущи, и множество ежедневных задач неразрывно связано с идеальной работой приложений, поэтому пользователи мобильных устройств имеют высочайшие ожидания в вопросе качества этих приложений. Компании это осознают, начиная выставлять мобильным приложениям наивысший приоритет. Я набросал трехшаговую инструкцию, как создать стратегию тестирования вашего мобильного приложения.
Публикуем видео доклада спикера Григория Петрова, прозвучавшего на конференции TestCon Moscow в прошлом году.
Вот о чем в своем докладе «Тестирование кросс-платформенных звонков» говорил Григорий.
Мы в Voximplant занимаемся автоматикой голосовых и видео звонков. Наше облако управляет звонками между телефонной сетью, веб страницами с нашим Web SDK и мобильными приложениями с нашими native SDK. И все это надо тестировать: инициация и прием звонков в разных комбинациях, кодеки, качества звука и еще десятки специфичных для телефонии штук. В докладе я расскажу про особенности тестирования такой системы: разные комбинации версий браузера и мобильных приложений, голосовые данные в реальном времени, интеграция с традиционной телефонией. Что и как можно протестировать, ручное тестирование и автоматика, существующие решения и наши велосипеды.
Напоминаем, что конференция TestCon Moscow 2019 начнется через 7 дней. Зарегистрироваться можно здесь.
В прошлый раз мы говорили о том, что такое межсайтовый скриптинг (XSS) и приводили несколько примеров. Однако недостаточно просто знать, что это такое – нам нужно уметь убедиться, что наше приложение не подвержено XSS-атакам! Сегодня мы обсудим три стратегии тестирования на XSS-уязвимости.
Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова
Эта часть ретроспективных уроков автоматизации логично вытекает из предыдущей. Обсудим, какие тесты автоматизировать, какие тесты этого достойны, и какие тесты будут хорошими кандидатами на автоматизацию.
Я постараюсь быть честным, основываться на личном опыте и не лить воду. Я легко привлеку в свой блог тысячи читателей, просто повторяя всю ту чушь, которую несут в сети, но у меня есть принципы. Поэтому скажу так:
"Какие тесты автоматизировать" – неверный вопрос
Любой, проработавший в тестировании больше полугода, знает, что мы не "автоматизируем тестирование" – мы не можем и не будем этим заниматься. На самом деле мы автоматизируем часть процесса исполнения тестов, и это очень крошечная часть по сравнению со всем спектром деятельности, которой мы занимаемся в ходе тестирования. Думаю, я потратил достаточно букв, объясняя, что автоматизация – это не превращенное в код человеческое тестирование. Это два раздельных и очень различных типа тестирования, имеющих разные цели. Они не взаимозаменяемы – они дополняют друг друга (см. "Горькая правда об автоматизации", "Не-ручной неавтоматизированный тестировщик").
Учитывая это, неверно говорить о том, "какие тесты автоматизировать" – такой вопрос предполагает, что мы автоматизируем то, что уже делаем вручную.
Тестировать веб-приложения в современном мире нужно не только на десктопе, но и на мобильных браузерах. Естественно, в Chrome есть режим работы с мобильными девайсами. Однако далеко не все проблемы в этом режиме будут видны. Поэтому стоит проверять свои сайты и на реальных устройствах. Благо, Google позаботился о возможности подключения Android-девайсов напрямую к браузеру Chrome. Конечно, это нетривиальная задача, и требуется пара хитростей. Зато вкладка Devices дает доступ к некоторым интересным функциям браузера. О том, как ей пользоваться, мы рассказываем в этом видео:
Это и другие видео вы можете увидеть на нашем youtube-канале. Подписывайтесь, чтобы регулярно получать новые видео по тестированию!
Публикуем видео доклада спикера прошлогодней конференции TestCon Moscow 2018 - Ивана Катунова «Тест дизайн и автоматизация REST API».
Вы приходите на проект, где вам необходимо организовать тестирование RESTful API сервиса. Впервые столкнувшись с подобным типом приложения у вас может возникнуть множество вопросов. Чем тестирование RESTful API сервисов схоже и чем отличается от тестирования других типов приложений? Какое покрытие тестами является достаточным? Какие лучшие практики существуют для автоматизированного тестирования REST API? В рамках доклада мы сравним RESTful API сервисы с другими типами приложений, рассмотрим как учитывать эти отличия при тестировании. Вспомним базовые техники тест дизайна, которые можно применять для тестирования REST API. Определимся с тем, какое покрытие тестами является достаточным и от каких факторов оно может зависеть. Рассмотрим какие подходы существуют к автоматизации тестирования RESTful API сервисов и к хранению тестовых данных, какой набор инструментов и технологий поможет нам в эффективном тестировании.
Напоминаем, что в этом году конференция TestCon Moscow 2019 пройдет 2, 3 и 4 апреля.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Мне очень нравится, что в тестировании API очень легко организовывать тесты и переменные окружения. Я люблю, когда тест-наборы моментально готовы к использованию, и их можно запустить одной кнопкой при регрессионном тестировании, или же запускать автоматически как часть процесса непрерывной интеграции.
В этот раз мы поговорим о паттернах организации тестов, которые можно использовать для тестирования API. Я обсуждаю их в контексте Postman, но эти концепции останутся неизменными, какой бы платформой для API-тестирования вы ни пользовались.
Для начала давайте поговорим об окружениях. Если вы помните из прошлой статьи, то окружение – это коллекция переменных в Postman. Настраивать окружения можно двумя способами, и чтобы их разъяснить, я буду пользоваться сценариями. В обоих сценариях мы предположим, что у меня есть приложение, которое начинает свой жизненный цикл в разработке, затем переезжает в QA, подготовку и, наконец, в релиз.
В моем первом сценарии у меня есть API, которое получает и обновляет информацию о пользователях моего сайта. В каждом продуктовом окружении (Dev, QA, Staging, Prod) тест-пользователи различаются. У них будут разные ID, имена и фамилии. Ссылки на окружения также будут различными. Однако мои тесты не изменятся: во всех окружениях я буду получать информацию о пользователе (GET) и обновлять ее (PUT).
