State & Transition Diagram (сокращенно S&T) — схема состояний и переходов. Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.
Вот объект находился в состоянии А, потом произошло какое-то действие, и он попал в состояние В. Потом он попадет в состояние С и другие... Принцип не меняется, было одно состояние, стало другое.
Мы рисуем:
кружочки — состояния объекта;
стрелочки — то, благодаря чему из состояния А в состояние В. Это действие, но его может совершить не только пользователь, но и система сама. Например, задача запустилась автоматически в 10 часов вечера.
Такая схема позволяет нам сразу визуально оценить, какие переходы вообще возможны и что надо протестировать. Ведь нам надо протестировать и эту стрелку, и эту... Так что стрелочки — это наши готовые тест-кейсы!
Автор: Энди Найт (Andy Knight) Оригинал статьи Перевод: Ольга Алифанова
Недавно мне задали вот такой вопрос (я его перефразировал для ясности):
Хорошая ли практика – одновременно использовать несколько тест-фреймворков? К примеру, я работаю над Python-проектом. Я хочу применять BDD c behave для фича-тестирования, но pytest лучше подойдет для юнит-тестирования. Можно ли использовать и то, и другое? Если можно, как мне структурировать мой проект?
Краткий ответ: да, нужно использовать фреймворки, наилучшим образом подходящие под конкретные цели. Обычно применение нескольких фреймворков несложно настроить. Разберемся подробнее.
В автоматизации тестирования я уже более 11 лет. Скажу сразу, что являюсь поклонником старомодного тестирования на Java и очень настороженно отношусь к различным готовым фреймворкам. Если вы придерживаетесь такого же мнения или только задумываетесь об использовании Robot Framework, в этой статье я постараюсь рассказать вам о его ограничениях и, конечно же, опишу все его достоинства.
Я столкнулся с Robot Framework около года назад. Перед нами стояла задача силами двух инженеров автоматизировать довольно большой объем тестов в сжатые сроки, т.к. ручная регрессия перестала влезать в разумные рамки. Сам проект связан с пожарной безопасностью. Тестировать предстояло Web-часть в трех браузерах и Mobile-часть на множестве iOS и Android телефонов и планшетов. Помимо этого, в наличии были тесты, которые взаимодействовали и с Web, и с Mobile. Конечно, это не ракету построить, но и не совсем тривиально. Честно скажу, я сопротивлялся, мы долго думали и в итоге, по совокупности внутренних и внешних факторов, выбрали Robot Framework.
Майндмап, Майнд карта, интеллект-карта, ассоциативная карта, диаграмма связей и т.д. – устоявшегося русскоязычного термина пока нет. Как, зачем, когда и надо ли?
Материал готовила для начинающих, но возможно и более опытные найдут полезные моменты.
На Хабре уже не раз писали о том, что у Selenium Grid есть проблемы, которые не решить простым способом (например: раз, два, три). В этой статье мы поделимся нашим опытом и расскажем, как нам в Wrike удалось построить стабильную инфраструктуру для Selenium-тестов.
TLDR: Мы написали своё open source решение и полностью заменили им Selenium Grid.
Мы уже рассказывали о том, как масштабировали свою Selenium-ферму с помощью Google Cloud Engine и Kubernetes. От очередей на запуск тестов мы избавились, но из QA-департамента регулярно поступали жалобы на нестабильность тестовой инфраструктуры.
Автор: Ноэми Феррера (NoemiFerrera) Оригинал статьи Перевод: Ольга Алифанова
В своем докладе на Heisenbug я демонстрировала два примера автоматизации в виртуальной реальности - Unium и Poco (Airtest). Мои объяснения были довольно поверхностными, поэтому я решила расширить их в этой статье.
Всем хорошего дня, я backend-разработчик компании Uma.Tech. Сегодня я хочу рассказать, как однажды нашему отделу разработки поступила задача от отдела тестирования: локально развернуть сервис создания заглушек для http-запросов. Если интересно, как проходил поиск, сравнение разных opensource и не только инструментов, до чего мы в итоге докатились и причём тут попугай на картинке — прошу под кат.
Оговоримся сразу: мы не рекламируем ни один из приведенных ниже инструментов, а просто делимся своим опытом.
TLDR: Если нет желания читать много букв, в конце общая сводная таблица по всем инструментам.
Автор: Тоби Стид (Toby Steed) Оригинал статьи Перевод: Ольга Алифанова
В первой статье этого нового цикла мы научились добавлять Cypress в новый проект и настраивать его, и закончили созданием первого теста. Поздравляю, теперь вы находитесь в той точке, в которой нечестные люди пополняют свое резюме в разделе технических навыков. Однако нам еще многому надо научиться, и в этот раз мы улучшим наш тест, внедряя в Cypress Page Objects.
Cypress, как практически все тест-инструменты и фреймворки, поддерживает разные паттерны дизайна. В этой статье, расширяя предыдущую, мы будем использовать Page Objects. Надеюсь, это поможет вам разобраться с парой моментов. Во-первых, вы увидите, как похож код с Page Objects в Cypress на Selenium (помимо синтаксиса), а во-вторых, как здорово Cypress позволяет быстро писать чистый и читабельный код.
Любой компании необходим взгляд со стороны на состояние информационной безопасности сервисов и продуктов. Эту задачу можно решить разными способами, один из которых — участие в Bug Bounty программах.
Bug Bounty программа как свежая сила в деле багхантинга
Bug Bounty («вознаграждение за ошибку») — это программа, которая предусматривает денежное вознаграждение или другие бенефиты за нахождение багов, эксплойтов и уязвимостей в работе ПО. Программы Bug Bounty реализованы многими компаниями, в том числе Facebook, Google, Reddit, Apple, Microsoft и др.
В мире автоматизации новичку ориентироваться довольно сложно. Приходится узнавать множество понятий, разбираться в особенностях существующих инструментов. Например, вот: Selenium, Selenide, Selenoid, Selendriod — что это, чем отличается? Да и можно ли их сравнивать?
Написал статью, чтобы помочь в этом разобраться. Кому интересно, добро пожаловать под кат!
