Автор: Мэтт Хойссер (Matt Heusser) Оригинал статьи Перевод: Ольга Алифанова
"Не можем ли мы в сообществе разделять функциональное/исследовательское/юзабилити-тестирование и регрессионные проверки?"
(твиттер Мэтта Хойссера)
Недавно я побывал на SauceCon, ежегодной конференции Sauce Labs. Sauce предоставляет платформу (и облачные мобильные устройства при необходимости) для запуска скриптов Selenium. Слушая, как докладчик говорил о "тестировании", не проводя черту между регрессом и функциональным тестированием, я написал об этом твит.
Знаю, знаю, есть множество типов тестирования, а не только эти два, как мог я забыть про тестирование производительности, безопасности, и так далее, и тому подобное! Вот он, ужасный я, "всего лишь" упоминающий "функциональное" тестирование. Ладно, хорошо, но я так-то не об этом.
Я хочу рассказать о двух тонких различиях и объяснить, почему они важны.
Привет! Меня зовут Мария Лещинская, я QA-специалист в Surf. Наша компания разрабатывает нативные приложения с 2011 года, а с 2018-го мы занимаемся ещё и разработкой под Flutter.
В этом материале сравним возможности тестирования нативных и кроссплатформенных приложений. Я поделюсь впечатлениями от работы с Flutter и расскажу, какие инструменты мы в Surf используем при тестировании, чем Flutter удобен и с какими проблемами мы столкнулись.
Автор: Ноэми Феррера (Noemi Ferrera) Оригинал статьи Перевод: Ольга Алифанова
В ходе карьеры мне задавали массу вопросов о тест-архитектуре: как начать тестировать, если ничего не делалось годами? Сколько тест-проектов должно быть? Сколько различных типов тестирования нам нужно? Кто должен отвечать за тестирование в процентном соотношении? Как масштабировать тестирование? Как разобраться с большими приложениями? Как разобраться с существующими тестами, если в них черт ногу сломит? Какими инструментами пользоваться? В каком количестве браузеров надо тестировать (их что, больше двух?!)
Начнем с начала: все приложения уникальны, каждая компания имеет свою структуру, свои ресурсы и бюджет, и все компании находятся на разных стадиях зрелости (это не значит, что они должны стремиться на следующую ступень – возможно, они находятся именно там, где должны). Тут не существует универсальных решений, и поэтому я рекомендую проконсультироваться с экспертом. Но я хочу поделиться своим прошлым опытом на случай, если вам это поможет.
В современном мире программных разработок важность API-интерфейсов является очевидной практически для любого специалиста. Данные интерфейсы дают возможность любым двум отдельным приложениям легко обмениваться данными друг с другом, а также упрощают пользователям приложения выполнение привычных действий без использования графического интерфейса приложения.
Автотесты под Android — это непросто. Чтобы выстроить процесс автотестирования, надо запланировать и решить множество задач. Но самая большая беда заключается в том, что нигде нет полного описания, что вообще включает в себя автотестирование под Android, каковы его основные стадии. Отсутствует цельная картина. Этой статьей мы хотим восполнить пробел.
Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Пользовались ли вы когда-нибудь JWT? Скорее всего, да, если вы хоть раз тестировали продукт с аутентификацией или авторизацией! Термин JWT произносится как "джот" и расшифровывается как JSON Web Token. JWT создаются компанией Auth0, чья цель – предоставить продуктам метод определения, есть ли у пользователя необходимые права для доступа к ресурсу. Чем хороши JWT? Они позволяют приложению проверить авторизационные данные, не передавая логин, пароль или куки. Перехватить можно любые запросы, но JWT не содержит персональных данных и зашифрован, поэтому его перехват не принесет особой пользы (чтобы узнать больше о разнице между токенами и куки, см. статью). Давайте посмотрим, как создаются JWT.
Автотесты — модная, но довольно затратная история. Автоматизаторы стоят дороже, чем ручные тестировщики, а сами автотесты требуют больше времени на разработку, причем разрабатывается не функционал продукта, а его проверка, которая окупается не явно и не сразу. Требует затрат и поддержка автотестов. Однако каждую из этих статей расходов можно минимизировать, сделав автотестирование намного эффективнее.
Меня зовут Мария Снопок, я менеджер направления автоматизации в Отделе тестирования Департамента разработки и сопровождения продуктов больших данных X5 Retail Group. В этой статье я расскажу о нашем опыте внедрения автотестов и сокращении связанных с ними издержек. Надеюсь, эта информация окажется полезной для команд, которые сталкиваются с трудностями при переходе на автоматизированное тестирование.
Автор: Пол Симан (Paul Seaman) Оригинал статьи Перевод: Ольга Алифанова
На днях было интересно следить за постами в LinkedIn. Популярными темами были "ручное тестирование" и "не все могут тестировать". Хоть меня и раздражает термин "ручное тестирование", на данный момент меня утомила эта дискуссия. Давайте рассмотрим тезис "не все могут тестировать". Я не уверен, что не впадаю сейчас в тест-ересь, но приступим!
Всем привет! Агеева Нина, автор курса «Погружение в тестирование. Jedi Point» продолжает тему визуального менеджмента в тестировании и знакомит вас с техниками тест-анализа и тест-дизайна: ДПЗ, тестированием на основе диаграммы состояний и переходов, блок-схемами и классами эквивалентности. В своем видео Нина расскажет, почему стоит прибегать к визуальному менеджменту и что это даёт тестировщику.
Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова
Хотите, я расскажу вам рождественскую сказку? Кто-то, возможно, скажет, что Рождество давно прошло, но знаете, что не пройдет никогда? Глупости, которые делают люди и называют это рабочим процессом. Не слышали, как разработчики (а может, и тестировщики) говорят "Надо поправить CI-билд, чтобы все тесты прошли"? Или что-то вроде "Мой CI-билд снова упал, как быть с этими плавающими, нестабильными тестами?" Знакомо звучит? Мне кажется, разработчики убеждены, что цель билда – быть вечно зеленым. Я называю это "вечнозеленым CI-билдом" (и поэтому это рождественская сказка), или, чтоб покороче, Эвергринчем. Эвергринч – это на самом деле монстр, который хочет украсть ваше качество и убить ваш проект. Это жуткая рождественская сказка.
