Автор: Тоби Стид (Toby Steed) Оригинал статьи Перевод: Ольга Алифанова
Cypress – очень впечатляющий тест-инструмент. Последние лет 13 я работал на C# и Selenium, но недавно, стараясь идти в ногу со временем, я рассмотрел более популярные JavaScript-инструменты.
Я вначале отбросил Cypress, потому что предпочитаю работать с библиотеками, а не фреймворками. Мне нравится, когда я свободен в построении своего собственного фреймворка вокруг выбранных мною для решения проблемы библиотек. Cypress – готовый фреймворк "из коробки", и со временем я понял, как он хорош. Он очень мощен прямо с момента установки, и в нем можно быстро и легко написать хорошие, устойчивые тесты – кривая обучения у него довольно пологая.
Если вы ранее не пользовались Cypress, то эта серия статей поможет вам легко установить Cypress и начать писать тесты. Мы даже разовьем этот опыт, воспользуясь Page Object, создадим свои собственные вспомогательные классы, и напишем кастомные команды для расширения возможностей фреймворка. В первой части цикла мы установим новый проект Cypress, настроим его и напишем наш первый тест.
Вот выдали нам (тестировщикам) функционал и сказали:
— Держи, тестируй!
А с чего начать? Для новичка это может быть целой проблемой. Особенно когда нет подробного ТЗ. Поэтому я решила создать эту подборку, где можно поискать вдохновение! ツ
Автор: Кристин Джеквони (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 веских причин для создания детальных тест-кейсов". Статья утверждает, что дает "значимое обоснование для создания детальных тест-кейсов", и идет дальше, пытаясь "вдохновить вас писать более детализированные кейсы в будущем". Мы категорически не согласны как с предпосылкой, так и с "вескими причинами", и в этой серии статей мы обоснуем свою точку зрения.
