"Почему это не отловили в QA" – это, возможно, наиболее психологически жуткая и дисфункциональная культура тестирования, которой только может обладать компания. Я видел, как она буквально разрушала хороших людей и карьеры. Она плюет в лицо системному мышлению, сложности отказа, менеджменту рисков, и просто всему, что мы знаем о психологии тестирования. Однако культура буллинга и перевода стрелок в IT не дает ей умереть…"
Здесь есть о чем подумать. Начнем с того, что такое QA.
Если QA – это обеспечение качества, то важно выяснить, кто или что обеспечивает качество – ценность для значимых лиц.
Тестировщик — профессия, которая с каждым годом набирает все больше популярности. Но чем же она так привлекает потенциальных соискателей?
Возможность попасть в IT-сферу, высокая зарплата, перспектива работать за рубежом — заманчивые реалии специалистов по тестированию. Именно они так привлекают как желающих сменить профессию, так и вчерашних школьников.
Практически нулевой вход в профессию — не исключение при выборе новой стези. Несмотря на несколько повысившиеся требования работодателей к начинающему специалисту, стать тестировщиком с нуля в 2020 году вполне реально даже без технического образования и после 30 лет.
Если вы хотите найти свою первую работу в тестировании, но не знаете, с чего начать, — читайте наш гайд и, следуя советам, стройте успешную карьеру в IT-индустрии.
Тестов много не бывает. И речь идёт не только о наращивании их количества (что само по себе, конечно, тоже хорошо) — речь идёт о разнообразии самих видов тестов. Даже не напрягая воображение можно вспомнить несколько способов протестировать ваше приложение: Unit-тесты, интеграционные тесты, API-тесты, системные тесты… и это не вспоминая о том, что тесты ещё бывают функциональными, нагрузочными, направленными на отказоустойчивость...
Но с чего же начинать писать тесты для новых проектов? Лично для меня, как для программиста, самый интуитивный ответ — это Unit-тесты. Однако опрометчиво накидываться на сочинение Unit-тестов может не только оказаться бесполезым занятием, но даже нанести вред в будущей разработке проекта.
Поэтому в этой статье я хочу предложить вам альтернативу и расскажу о том, почему лучше всего в самую первую очередь писать самые сложные тесты (системные), а затем уже — все остальные.
Если вы тестируете API, то должны знать про два основных формата передачи данных:
XML — используется в SOAP (всегда) и REST-запросах (реже);
JSON — используется в REST-запросах.
Сегодня я расскажу вам про XML. В списке доп литературы будет ссылка на книгу по XML, у меня нет цели ее дублировать, но я расскажу про этот формат тем, кто XML еще в глаза не видел. А дальше уже гуглим сами ))
XML, в переводе с англ eXtensible Markup Language — расширяемый язык разметки. Используется для хранения и передачи данных. Так что увидеть его можно не только в API, но и в коде.
Этот формат рекомендован Консорциумом Всемирной паутины (W3C), поэтому он часто используется для передачи данных по API. В SOAP API это вообще единственно возможный формат входных и выходных данных!
Автор: Тоби Стид (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 непонятно, что у нас пришло, массив или объект. Чтобы понять это, выводим ответ на консоль и проверяем там. Подробнее см в видео:
