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

Всем привет! Я Дмитрий Лунин, работаю аналитиком в команде ценообразования Авито. Наш юнит отвечает за все платные услуги площадки. Наша основная задача — сделать цены на них оптимальными. 

Мы не только пытаемся максимизировать выручку Авито, но и думаем про счастье пользователей. Если установить слишком большие цены, то пользователи возмутятся и начнут уходить с площадки, а если сделать цены слишком маленькими, то мы недополучим часть оптимальной выручки. Низкие цены также увеличивают количество «спамовых» объявлений, которые портят поисковую выдачу пользователям. Поэтому нам очень важно уметь принимать математически обоснованные решения — любая наша ошибка напрямую отразится на выручке и имидже компании. 

Одним из инструментов для решения наших задач является A/B-тестирование.

Программисты пишут код (удивил, да?) Если это пет-проект, то вы вольны делать со своим кодом все, что хотите. Но когда над одним проектом работает несколько человек или даже целая команда, рано или поздно встаёт вопрос о необходимости код-ревью. Кому отдать на ревью? Как ускорить этот процесс? Как равномерно распределять реквесты по ревьюерам? Вопросов много, а ответы не так очевидны. В этой статье расскажу, с какой проблемой мы столкнулись в команде автотестирования в Wrike, как у нас устроен процесс ревью и зачем нам понадобился самописный сервис.

(Эта статья первоначально появилась на TechBeacon.com)

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

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

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

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

Поймите две основные концепции

Создавая стек автоматизации, не забывайте, что вы занимаетесь программированием; вы создаете программное обеспечение и должны относиться к этой задаче как к разработке программного обеспечения. Это означает — вы должны следовать практике разработки и поставки программного обеспечения, соответствующей тому, что вы разрабатываете.

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

Возможно, вы уже встречали термин «human factors design» в прошлом. Но что это такое?

Kafka — это популярный способ потоковой загрузки данных в ClickHouse. ClickHouse имеет встроенный коннектор для этой цели — движок Kafka. Наши друзья из Cloudfare первоначально создали этот движок для ClickHouse. С тех пор движок Kafka был значительно переработан и теперь поддерживается разработчиками Altinity. Однако не всегда очевидно, как использовать его наиболее эффективным образом. Мы попытались восполнить этот пробел, проведя вебинар по Kafka, который прошел успешно. В этой статье мы собрали типичные вопросы, которые мы получаем по поводу использования движка Kafka. Надеемся, что наши рекомендации помогут избежать распространенных проблем.

Меня зовут Андрей Непряхин, я руковожу отделом QA в компании AGIMA и расскажу, как мы подошли к процессу тестирования, чтобы сделать его более прозрачным, отлаженным и менее дорогостоящим. Но главная цель — повысить качество продукта. Это влияет на несколько очевидных метрик: лояльность наших клиентов, которые используют сайт, сервис или мобильное приложение, и выстраивание теплых и долгих отношений с нашим заказчиком, если мы говорим о разработке на аутсорсе.

Слой API любого приложения - один из важнейших программных компонентов системы. Это канал, который соединяет клиента с сервером (или один микросервис с другим), управляет бизнес-процессами и представляет сервисы, которые  приносят пользу пользователям. 

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

Становится понятно, что важность тестирования API очевидна. Некоторые методологии и ресурсы помогают нам узнать КАК тестировать API - вы можете использовать ручное тестирование, автоматическое тестирование, тестовые среды, инструменты, библиотеки и фреймворки. Однако, независимо от того, чем вы будете пользоваться - Postman, supertest, pytest, JMeter, mocha, Jasmine, RestAssured или любыми другими инструментами - прежде чем открывать любой инструмент тестирования, вам необходимо определить, что тестировать...

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

Давайте порассуждаем, почему так происходит, и как найти выход из этой ситуации.

Привет! Меня зовут Ольга Ермолаева. Я работаю в тестировании с 2008 года. Сейчас руковожу департаментом качества в компании «Инттерра» и помогаю студентам на курсе для тестировщиков в Яндекс.Практикуме в качестве наставника.

Все, кто работает в IT-сфере, когда-то задавались вопросом, как найти первую работу. Ведь все работодатели требуют опыт, но никто не говорит, где его взять.

Начинающие программисты пишут свои pet-проекты, выкладывают на Github и добавляют ссылку в портфолио. Дизайнеры могут показать свою страницу на Behance или Dribble. Но что делать начинающим тестировщикам?

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

В статье я поделюсь с вами одним из вариантов решения этой проблемы.

Как-то очень давно наш отдел автоматизации внутренних процессов посетил админ (ops) с идеей помочь нашим тестировщикам. Основная идея был упростить деплой т.к. было очень неудобно писать ручные curl запросы к gitlab'у с кучей меняющихся параметров. Так заставили нас наша команда решила помочь дружественному отделу и сделать их работу более приятной.

В статье я постараюсь поделиться тем, как мы разрабатывали GUI для curl'a, а сделали очень крутой сервис автоматизации. А также с какими проблемами столкнулись и как их решили (или нет).

Привет всем. Меня зовут Таня. Я автоматизирую тесты на Go уже около года, до этого занималась 4 года автоматизацией на Java.

В этой статье расскажу:

- Как писала интеграционные тесты на Go + Allure

- С какими проблемами столкнулась

- С какими библиотеками и инструментами работаю

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

Всем привет. Я qa automation engineer уже 14 лет и 9 из них мне так или иначе приходилось работать с автоматизацией веб-приложении (и не только). Я писала свои автотесты на C#, Java, и Js. Сейчас я хотела бы поделиться опытом, как я выбираю фреймворк для тестирования веб приложения. Думаю кому-то мой текст может быть полезен. 

Первое, с чего следует начинать создания своего фреймворка, - это с выбора движка взаимодействия с браузером. Именно движок в дальнейшем станет краеугольным камнем ваших тестов. Именно выбор движка является фундаментом дома, который вы строите (и потом этот фундамент никак не переделать сторонними библиотеками).

Этот, казалось бы, глупый вопрос задают с завидной регулярностью. Казалось бы уже давно все должно быть понятно, но нет.

Disclaimer: данная статья написана с учетом опыта разработки в определенной (хоть и самой массовой) сфере ПО, а именно e-commerce. В других сферах правила игры могут разительно отличаться.

Я работал в тестировании 3 года, в автоматизации 7 лет, и в разработке - все оставшееся время, и вскоре я буду выступать на Национальной Конференции по Тестированию в Великобритании с ответом на этот вопрос. Но конференция еще не скоро, а многим, видно, интересно узнать ответ уже сейчас.

Эта статья является переводом статьи из блога Uber. Обычно мы в Qameta Software не занимаемся переводами, но мимо этой статьи пройти не смогли. Хороший и исчерпывающий материал о том, что такое flaky-тесты, какие они бывают и как с ними справляться (с некоторыми проявлениями). Часть материала, посвященную переезду Uber с микросервисов на монорепо я опустил, оставив только то, что напрямую связано с отработкой flaky-тестов.

Юнит-тесты лежат в основе любой Continuous Integration (CI) системы. Они позволяют обеспечить контроль над качеством кода при высоких темпах разработки, предупреждая инженеров о багах в новом коде и регрессии в кодовой базе. Кроме того, они снижают стоимость разработки за счет обнаружения ошибок на ранних этапах. Именно поэтому построение стабильной и работающей тестовой инфраструктуры является одним из базовых требований для любой крупной разработки.

К сожалению, flaky-тесты осложняют жизнь тем, кто это требование пытается выполнить. Давайте считать, что мы будем принимать тест как flaky если на любых двух воспроизведениях он возвращает разные результаты: прошел или упал, — без изменения кода. Такие тесты чаще всего возникают в результате одной из двух причин: недетерминированность на уровне кода (порядок исполнения тредов и другие сложности с многопоточностью) или неоднородностью окружений, в которых выполняется тестирование (на одной машине все работает хорошо, а на CI-сервере тесты падают).

Давайте рассмотрим простой пример, на котором будет понятно, откуда у проблемы ноги растут:

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

Чтобы выявить технические ошибки, необходимо провести комплексный технический SEO-аудит сайта. Одним из основных помощников в этой сложной и трудозатратной задаче для нас выступает десктопная программа Screaming Frog.