Тестирование веб-сервисов *

«Интересно, а кто-нибудь заметил, что Safari Technology Preview как-то странно влияет на заголовок, баннер бета-версии и кнопки сайта?»

Есть у Postman несколько полезных функций, которые помогают нам экономить десятки, а в некоторых случаях и сотни человеко-часов в месяц. Тут нет каких-то больших секретов или магии, но рассказ про них может для кого-то послужить началом долгого и продуктивного использования.

В этом посте я пробегусь по пяти функциям и приемам для Postman, которые мы используем для тестирования систем, связанных с банковскими операциями в сегменте C2B – теми самыми, которые весь мир ежедневно проводит через всевозможные кассовые аппараты, банкоматы, терминалы и QR-коды.

Привет, хабр. Меня зовут Кияшева Екатерина и я руковожу тестированием. Сегодня хочу поделиться своим чит‑листом обо всем.

Чит‑лист — набор стандартных проверок для многократного использования в различных приложениях, одинаковых по какой‑либо характеристике.

Я использую чит‑лист с тремя целями: передаю его своим коллегам, чтобы маст-хэв тесты не были забыты, заглядываю в него перед проверкой тестового покрытия коллег на малознакомом проекте, проверяю себя в ходе вычитки техзадания и при тест‑дизайне.

Хочу, чтобы его было полезно и удобно использовать, поэтому буду рада предложениям и комментариям по его расширению и упрощению.

Хочу описать свои наработки и устоявшиеся подходы к тестированию PHP проектов. Последние годы я работаю с Symfony и здесь будет достаточно моментов специфичных для этого фреймворка. Так же в этой статье термин функциональные тесты (functional) является синонимом End-to-End тестов. Статья рассчитана на разработчиков уже знакомых с PHPUnit и Symfony, структурой composer файла. Врочем, здесь есть и общеизвестные моменты, чтобы облегчить понимание тем, кто только начинает писать тесты. Статья призвана упорядочить знания и показать какие-то удобные подходы. Формат статьи не позволяет раскрыть все нюансы. Тем не менее, я постараюсь озвучить все основные моменты, применяемые в работе и которые лично мне помогают на практике. 

Однажды инженер Василий проснулся и понял, что больше не может ждать эти бесконечные пайплайны.

Чтобы отделить ощущения от реальности, он начал собирать статистику — сколько ходят пайпланы, сколько выполняются сами тесты в сервисе фото, а сколько собираются образы. Всё обдумав, он осознал: нужно что-то делать непосредственно с самой сборкой — от пайплайна к пайплайну зависимости меняются редко, а пересобирается всё каждый раз, как в первый.

Картина была такая: от старта пайплайна до непосредственного запуска тестов в сервисе проходило в среднем 7,5 минут. Допустим, за рабочий день каждый член команды (разработчик/тестировщик) запускает 3 пайплайна, а людей в команде — 14. Тогда на сборку образа уходит 5 часов 15 минут. 

Василию не подходит.

До сих пор существует множество стереотипов о тестировщиках. В этом переводе статьи 2009 года собраны одни из самых узнаваемых типов тестировщиков, описывающие не только лишь негативные узнаваемые черты, но и позитивные стороны тестировщиков. Надеюсь для людей не знакомых с тестированием эта статья поможет увидеть насколько разные тестировщики бывают.

Данная статья может быть полезна тем, кто хочет немного повеселиться, т.к. некоторые типы тестировщиков действительно встречаются в жизни и можно вспомнить забавного коллегу, а также тем, кто хочет стать чуточку лучше, взглянув на себя со стороны и сделав определённые выводы, т.к. легко ассоциировать себя с описанными типами тестировщиков.

Всем привет! Меня зовут Кирилл, я старший разработчик в группе «Полигоны и ограничения доставки» в Ozon. Cегодня я расскажу про фаззинг, встроенный в Go: что это такое, зачем он нужен в разработке программного обеспечения и как с его помощью найти баг в дикой природе open-source-коде (рассмотрим на примере).

Привет, Хабр! Меня зовут Анна Дегтева, я — лингвист и антрополог. Почти 20 лет провела на кафедре математической лингвистики СПбГУ, из которых 15 преподавала. Начала заниматься разработкой голосовых интерфейсов, когда только прошёл релиз Siri, а компания i-Free взялась за разработку русскоязычных аналогов. В какой-то момент моих знаний о языке стало недостаточно. Я поняла, что речь нужно исследовать в комплекте с её носителями и поступила на факультет антропологии Европейского университета в Санкт-Петербурге. Там изучала, чем люди отличаются от роботов, как сделать так, чтобы нас было почти не отличить, и нужно ли это делать.

Сегодня расскажу, как правильно делать то, чему обычные люди обучаются к пяти годам — разговаривать. Это понимание поможет вам при проектировании диалоговых интерфейсов и UX-тестировании пользовательских устройств. Поговорим о разработке детского устройства, которое помогло мне получить опыт, пригодный для использования в любом диалоговом агенте.

Если вы приобретали новый автомобиль в последние несколько лет, то велика вероятность, что в нем есть хотя бы один встроенный модем, который нужен для разных полезных функций вроде удалённого прогрева автомобиля, самодиагностики, которая предупреждает о сбоях до того, как они произойдут, и всевозможных опций безопасности.

Автопроизводители активно используют электронику в своих новых моделях. Но, как показывает исследование охотника за ошибками и штатного инженера по безопасности Yuga Labs Сэма Карри, в электронных системах есть масса уязвимостей, которые позволяют отслеживать и даже контролировать некоторые автомобили, включая машины экстренных служб.

Многие IT-компании до сих пор придерживаются традиционного цикла разработки программного обеспечения. Организации склонны отдавать больший приоритет реализации, чем проектированию и редко уделяют должное внимание вопросам качества приложения. Но что такое качественное приложение? В чем разница между компаниями, ориентированными на качество, и компаниями, нацеленными на конечный продукт?

UPD: Добавили записи докладов и слайды

Всем привет!

Меня зовут Игорь, и я руковожу тестированием в Ozon Fintech. 

Внутри Ozon тестирование на Python популярно в командах логистики, склада, маркетплейса и всего финтеха. Почему мы используем этот язык?

Ответы на поверхности:

• Он прост в изучении и применении – это позволяет нам находить кандидатов, не знающих Python, и быстро погрузить их в язык.

• При этом это самый популярный язык автоматизирования тестирования, и, как следствие, много материалов по теме и кандидатов на рынке =)

• Batteries Included Philosophy.

Всё это позволяет нам быстро собирать компактные команды, которые успевают многое автоматизировать. В итоге удается обеспечить хороший уровень качества при многочисленных ежедневных релизах и быстро запускать новые продукты, чтобы радовать наших покупателей и продавцов.

Больше о нашем подходе к тестированию на Python мы расскажем на первом в этом году открытом Ozon Tech Community QA (Python) Meetup 18 января в 18:00 в Москве.

Что может быть более полезно для будущего, чем образование?

Что может быть более полезно для образования, чем интерактивный QA-учебник состоящий из 42 модулей, 42 онлайн-тестов, 500+ страниц от менторов с суммарным опытом 100+ лет?

Что может быть более полезно для кошелька QA-студента, чем когда это всё бесплатно?

Этот учебник появился не потому, что миру нужен был еще один учебник по тестированию. Хороших QA-учебников предостаточно. Он появился, когда стало ясно, что и обучающимся самостоятельно, и, как ни странно, QA-преподавателям нужен несколько другой подход к обучению тестированию. Так появилась трехуровневая модель обучения, результатом которой этот учебник и стал. 

Внедрение автоматизированных практик тестирования — очень полезная штука. Однако при подходе к этой задаче возникает масса вопросов. Какую платформу выбрать? Сложной ли будет миграция? Какие подводные камни ждут впереди? В своем посте я расскажу, как мы переносили практику тестирования и внедряли «тесты как код» на базе Allure TestOps.

Достаточно давно (по меркам ИТ-мира) я посмотрел доклад Артема Ерошенко с Heisenbug 2020 «Тест-кейсы как код». С переходом в Леруа Мерлен со старой TMS на Allure TestOps появилось желание полноценно попробовать данный подход у себя.

В статье расскажу о том, что из этого получилось.

В этой статье я расскажу вам о том, как ровно год назад я связал в цепочку несколько проблем безопасности для достижения Удаленного выполнения кода (RCE) на нескольких серверах компании VK. Я постарался описать свои шаги в подробностях, так как мне самому, как постоянному читателю отчетов по баг-баунти, всегда хочется понять, как исследователь мыслит во время обнаружения необычных уязвимостей. Надеюсь, для вас эта статья будет интересна.

Привет, Хабр! Меня зовут Мария Снопок, я отвечаю за автоматизацию тестирования на Python в X5 Tech. Я, конечно, не Остер, но могу дать с десяток вредных советов из области автоматизации. В частности, о том, как испортить жизнь себе и окружающим. 

В статье я собрала вредные советы по кодингу, коммуникациям, организации процессов, стандартам, визуализации и пр.: что нужно делать, чтобы тебя закидали помидорами. Смело наступаем на грабли – советы подкреплены реальными кейсами.

Меня зовут Виктор Мясников, я отвечаю за качество продукта в «Юле». Я закончил Бауманку и хотел строить ракеты, но с ними не вышло, поэтому теперь профессионально строю «велосипеды» для QA, а ещё люблю уничтожать рутину. Я расскажу, как мы проектировали BDD-фреймворк и зачем он вообще нам понадобился.

О чем эта статья и чем она полезна.

Всем привет! В этой статье пойдет речь о том, как написать простые UI-тесты на языке Java. Это будет интересно тем, кто давно хотел попробовать себя в автоматизации или добавить новенького в свой текущий проект.

В этой статье не будет большой остановки на теории, а также на том, как настроить рабочую среду. Эти темы я упомяну кратко и дам ссылки, которые помогут разобраться в них самостоятельно.

Основная часть статьи будет посвящена практическому разбору теста и нюансам их написания.

Собирайте с собой друзей, хорошее настроение и поехали!

Что такое UI-тесты? Плюсы и минусы.

UI-тестирование – это тестирование пользовательского интерфейса программы/сайта/приложения и др.

Звучит легко, а чем такие автотесты полезны?

1)    Такие тесты используются, чтобы автоматизировать рутинные задачи и однотипные действия, например, проверку товаров в каталогах.

2)    Чтобы ускорить или упростить проверку сложных пользовательских путей. Например, в кейсе, где есть очень много тестовых данных и переходов или для прохождения которого нужна сильная концентрация.

3)     Чтобы снять часть работы с сотрудников, если их мало на проекте, часть проверок можно перенести на автотесты.

Сразу скажу, что собственно до модерации я не добрался - запоролся на обучении, так что «личный опыт» - это очень громко сказано. Но уже обучения оказалось достаточно фееричным, чтобы у меня возникло острое желание о нём написать.

Некоторое время назад Озон громко заявил о создании платформы для удалённого заработка, под названием "Озон-Профит". Заявлялось, что данная платформа позволит, имея компьютер и доступ в интернет, зарабатывать до 20 тысяч в месяц, работая по четыре часа в день, не выходя из дома. Мой сын не так давно экспериментировал с "Яндекс-толокой", поэтому я примерно понимал, о каких масштабах "заработка" может реально идти речь. Тем не менее - у меня есть пожилые родственники, которым не хватает пенсии, и у которых много свободного времени, и я подумал, что им это будет интересно.

Первый звоночек прозвенел, когда первый же из тех, кому я предложил посмотреть «Озон.Профит», категорически отказался от этой затеи сразу после попытки пройти обучалку. Отказ сопровождался словами "что-то как-то совсем бредово, можно только в глубокий минус уйти". Если что - человек на тот момент на полном серьёзе рассматривал варианты фулл-тайм работы за 1 МРОТ. Дальше я решил почитать отзывы в интернете, и обнаружил, что реально народ там зарабатывает по пять тысяч рублей в месяц максимум, а самой распространённой суммой месячного заработка было "2-3 тысячи в месяц"... Мне стало прямо совсем интересно, поэтому было принято решение выделить пару-тройку вечеров на то, чтобы составить своё собственное мнение.

Технологии Agile, Scrum и CI/CD становятся общепринятой нормой, и нам уже кажется, что новые релизы всегда можно выпускать постоянно, практически непрерывно. Технически, сейчас действительно есть реальная возможность выкатывать обновления каждый день, а некоторые разработчики готовы релизиться каждый час — для web- и мобильных приложений это совершенно нормально. При такой частоте возникает вопрос: а нужно ли иметь хорошо отлаженную систему автоматизированного тестирования? Цена ошибки в таком релизном цикле не высока, а компания получает возможность переложить финальное тестирование на плечи своих клиентов. Если у кого-то что-то пошло не так, можно моментально выпустить исправление. Но возможен ли такой подход в разработке корпоративной BI-системы? Об этом и поговорим сегодня.

Привет, Хабр.  

Меня зовут Саша, я занимаюсь разработкой инструментов мониторинга тестирования, но по факту ещё и исполняю роль руководителя направления QA в домене Маркетплейса, ответственном за создание всех карточек товаров на Ozon.  

Если вкратце, наша задача заключается в сопровождении селлера от этапа загрузки файла Excel, в котором есть сто тысяч пар носков, до момента, когда все эти носки окажутся на витрине Ozon. Очевидно, что мы занимаемся не только парсингом экселек — у нас есть и highload-сервисы раздачи контента, несколько стейт-машин, системы с мастер-данными всего Озона, и немалый отдел ML, так что мы регулярно сталкиваемся со сложными и нестандартными задачами, подход к решению которых, впрочем, мы всё-таки пытаемся стандартизировать. 

За последние полтора года, как наше направление отделилось от основной разработки Маркетплейса, QA-отдел вырос в пять раз, с 5 до 25 QA-инженеров. О том, как мы решали вопросы масштабирования команды и плакали пытались справиться с legacy-наследием в доставшихся нам процессах, подробнее расскажу под катом.