Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Пользовались ли вы когда-нибудь JWT? Скорее всего, да, если вы хоть раз тестировали продукт с аутентификацией или авторизацией! Термин JWT произносится как "джот" и расшифровывается как JSON Web Token. JWT создаются компанией Auth0, чья цель – предоставить продуктам метод определения, есть ли у пользователя необходимые права для доступа к ресурсу. Чем хороши JWT? Они позволяют приложению проверить авторизационные данные, не передавая логин, пароль или куки. Перехватить можно любые запросы, но JWT не содержит персональных данных и зашифрован, поэтому его перехват не принесет особой пользы (чтобы узнать больше о разнице между токенами и куки, см. статью). Давайте посмотрим, как создаются JWT.
Автор: Пол Симан (Paul Seaman) Оригинал статьи Перевод: Ольга Алифанова
На днях было интересно следить за постами в LinkedIn. Популярными темами были "ручное тестирование" и "не все могут тестировать". Хоть меня и раздражает термин "ручное тестирование", на данный момент меня утомила эта дискуссия. Давайте рассмотрим тезис "не все могут тестировать". Я не уверен, что не впадаю сейчас в тест-ересь, но приступим!
Локатор — это путь к элементу в интерфейсе, с помощью которого автоматизированный тест (автотест) сможет его найти. Локаторы используются в автотестах, имитирующих работу пользователя в интерфейсе, в любых системах, но мы сегодня будем говорить только о web-системах. Для других систем виды локаторов будут другими, но к ним можно применять тот же подход поиска, как и в вебе. Локаторы подразделяют на простые и сложные. Простые локаторы называются так, потому что они соответствуют простым атрибутам элементов: id, name, class и др. В сложных локаторах используются совокупности атрибутов или близлежащие элементы. В вебе 2 вида таких локаторов: css и xpath.
В прошлой статье мы говорили о том, как достать данные из дерева JSON-объекта. Но что делать, если в ответе пришел XML? На самом деле, все довольное просто — используем snippet по конвертации XML в JSON:
var jsonObject = xml2Json(responseBody);
А дальше работаем, как привыкли!
Единственная проблема — по XML непонятно, что у нас пришло, массив или объект. Чтобы понять это, выводим ответ на консоль и проверяем там. Подробнее см в видео:
Один из наиболее популярных вопросов от новичков в
тестировании — как устроиться на работу, если никто не зовет после прочтения
резюме? По большей части такой вопрос возникает, если резюме составлено не
очень грамотно и не отражает всех навыков специалиста. Это неудивительно —
навык составления резюме не берется из воздуха, ему тоже нужно учиться. Но вот
если подходить к составлению резюме с умом и избегать популярных ошибок - можно
значительно увеличить свои шансы на собеседование, а значит - быстрее найти
работу.
В этом видео тренер Арсений Батыров представил топ-5 ошибок в резюме junior qa, которые чаще
всего встречаются в резюме новичков, и подсказал способы их исправить.
Допустим, что вы решили начать писать автотесты в Postman-е. Взяли пример из документации:
pm.expect(X).to.eql.;
«Мы ожидаем, что X = Y». Так можно проверить число, строку, и даже объект!
Но как «достать» этот самый X из ответа от сервера? Я видела, как это делают новички — они просто подставляют в переменную Х название нужного поля. Но тест при этом, увы, не работает. Потому что Postman не делает поиск по дереву json в поисках такого названия. Вам нужно указать точный путь к нужному параметру.
И сегодня я научу вас, как это делать. Пойдем от простого к сложному:
Как обычно тестировщик ищет границы в поле? Если в ТЗ есть ограничения, то тестирует их. А если их нет? С нижней границей все понятно — это пустое поле. А как найти верхнюю? Вставляем большую строку и смотрим, сколько символов сохранится. И всё…
И тестировщик должен проверить их все. Почему? Потому что когда мы одно значение дублируем несколько раз в разных местах, велик шанс ошибиться. При этом границу на клиенте очень легко снять. Что будет, если пользователь обойдет границу на клиенте? Не сломает ли он нам сайт большой строкой?
В этой статье я расскажу, как искать границы для поля в веб-формочке. Возьмем для примера форму редактирования пользователя в бесплатной системе Users.
Автор: Пол Симан (Paul Seaman) в соавторстве с Ли Хокинсом (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Недавно мы прочитали статью на сайте QA Revolution под названием "7 веских причин для создания детальных тест-кейсов". Статья утверждает, что дает "значимое обоснование для создания детальных тест-кейсов", и идет дальше, пытаясь "вдохновить вас писать более детализированные кейсы в будущем". Мы категорически не согласны как с предпосылкой, так и с "вескими причинами", и в этой серии статей мы обоснуем свою точку зрения.
Загрузить через любой сервис конвертирования изображения в base64 строку, например, https://www.base64-image.de/
Скопировать полученную строку целиком, включая начало: «data:image/png;base64,iVBORw0KG...»
Вставить в параметр для передачи фото в формате base64
Профит! Инструкция одинаковая для REST и SOAP.
Но смысл этого поста, разумеется, не в инструкции. А в том, чтобы сразу ее применить! Попробовать пощупать самостоятельно. Сделать это можно в API бесплатной системы Shop, метод create или update.
О задачах автоматизации тестирования и случаях, когда она необходима, мы уже писали. А для выбора необходимых проверок удобно иметь под рукой наглядное пособие, не ограничиваясь знаменитой пирамидой автотестов. Предлагаем перевод статьи Кристин Джеквони (Kristin Jackvony), где графически показан еще один метод – колесо автоматизации.
Автоматизация тестирования, как правило, наиболее необходима в масштабных приложениях с большим количеством бизнес-функций, при внедрении CI/CD и регулярных релизов. Подробнее об этом мы рассказывали в статье «Что даёт автоматизация тестирования».
С разрешения Кристин Джеквони – автора блога Think Like a Tester и ряда популярных материалов о тестировании – мы перевели статью «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel). В конце статьи рассмотрим пример проверок из практики наших специалистов по автоматизации тестирования (SDET).
Автор: Кристин Джеквони (Kristin Jackvony)
Автор: Пол Симан (Paul Seaman)
Автор: Пол Симан (Paul Seaman) в соавторстве с Ли Хокинсом (Lee Hawkins)