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

Привет! Меня зовут Дарина Майорова, я работаю в тестировании в Яндексе, и хочу рассказать, как в Яндекс Афише я за полгода вырастила команду саппорта тестирования.

Весной 2021 года у нас была проблема: в Афише было две команды разработки (Афиша и виджет продажи билетов), и был недобор тестировщиков . Мы столкнулись с большой нагрузкой, отсутствием времени на ведение документации, и тестирование выступало в роли “бутылочного горлышка” в командах. А в случае ухода хотя бы одного тестировщика в отпуск (или увольнения) — мы рисковали получить еще больший завал.

Какие решения можно было тут придумать? Желательно — дающие быстрый результат (найм и онбординг нового сотрудника — это не быстро).

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

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

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

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

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

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

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

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

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

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

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

Большое количество модулей Maven замедляет сборку проекта и время прогона тестов. Для того, чтобы сохранить многомодульную структуру проекта и быстро прогонять тесты, мы в Wrike написали новый инструмент — Maven Modules Merger, который сократил время некоторых сборок с 50 до 12 минут. В статье подробно расскажу о том, с какими проблемами нам помог справиться Maven Modules Merger и поделюсь подробностями его создания.

«В IT голодным не останешься» - поговорка новых реалий, которая давно себя оправдала. И ни для кого не секрет, что даже базовое образование в сфере цифровых технологий позволяет в дальнейшем работать сразу в нескольких направлениях. Поэтому, если вы ищите дополнительный заработок, то вас может заинтересовать такое неординарное явление в цифровом мире, как багхантинг – настоящая охота за «сокровищами».

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

А до офлайна остались считанные дни (21 июня в Санкт-Петербурге), и сейчас ещё не поздно решиться в нём поучаствовать.

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

Анализ тестов — это выкидывание лишнего из вашего чек-листа. Работа из серии «сесть и подумать»:

• какие проверки можно объединить?

• какие и вовсе выкинуть?

Было бы здорово дать некий алгоритм, который поможет всегда и везде, но нет, увы. Универсальная фраза здесь только «сесть и ПОДУМАТЬ». А самое главное: «вместе с водой не выплеснуть ребенка». Убирайте тесты аккуратно, особенно в первые годы работы. Возможно, выкинутое было отнюдь не лишним...

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

В этой статье я решил сделать краткий обзор функциональности Visualize, Mock Servers и Flow.

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

В этой статье мы рассмотрим NBomber как легкую для освоения альтернативу JMeter, а также постараемся ответить на вопрос "Почему я должен проводить нагрузочное тестирование именно с NBomber ?".

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

Андрей Лушников выступил у нас на Heisenbug с докладом о Playwright ещё в 2020-м. Но похоже, что с тех пор тема доклада стала только актуальнее: 34 000 звёзд проекта на GitHub ясно показывают, что он пришёл к популярности. А Андрей по-прежнему остаётся одним из главных контрибьюторов Playwright. Поэтому мы решили сделать для Хабра текстовую версию его доклада.

Конечно, за два года проект успел уйти вперёд (обзавёлся своим тестраннером и локаторами), но база осталась прежней, так что информация по-прежнему может быть полезной. Если вы ощущаете, что и вам пора приобщиться к этому инструменту — вот материал от того, кто точно глубоко разбирается в теме.

Видео и расшифровка — под катом. Далее повествование будет вестись от лица спикера.

Как тестировать React-компоненты? Какую библиотеку использовать? Как тестировать компоненты, которые берут данные из Redux, а не из пропсов? Как тестировать компоненты, в которых используется роутинг с помощью React-router-dom? Что делать, если в компоненте есть асинхронный код?

...Мои вопросы, когда на работе впервые попросили покрыть тестами компонент. Я, разумеется, стал гуглить тестирование React-компонентов в связке с Redux и React-router-dom, и понял, что в сети есть много ответов на вопрос, зачем нужно тестирование, но мало кто объясняет, как написать тесты. А если и объясняет, то в  общих чертах на абстрактных примерах. Мне не хватало статьи, вооружившись которой, начинающий разработчик мог бы выполнить тест на реальном продукте. Поэтому я решил написать ее сам.

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

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

Примечание редакции: тема важная, поэтому в качестве иллюстраций для большей читаемости мы добавили любимые мемы про QA.

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

Собрали 5 советов, которые помогут тестировщику найти взаимопонимание с разработчиками.

Привет. Меня зовут Маша, я — тестировщик в команде мобильной платформы. Когда-то для нас была актуальна проблема взаимодействия QA и Support. Сложностей было предостаточно, как и неприятных последствий. Но со временем мы успешно разобрались во всем. Хочу поделиться нашим опытом и рассказать, какие изменения сработали во благо.

25 лет назад Якоб Нильсен описал 10 основных принципов проектирования взаимодействия. Эти принципы были разработаны на основе многолетнего опыта в области юзабилити-инженерии и стали правилами для взаимодействия человека и компьютера.

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

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

Именно поэтому сложно жить без инструмента, который бы помогал нам в автоматическом режиме следить за качеством кода. Также мы хотели, чтобы наши продукты соответствовали определённым правилам и стилю кодирования. Речь про автоматические метрики, которые можно было бы посчитать (например, сложность кода) и сделать его логику простой для понимания, без излишеств. Это не значит, что мы захотели отказаться от написания сложного кода, просто если существует возможность написать простой и сложный код для одной функциональности, лучше выбрать первое, глядишь и дебажить придется меньше. Так в нашей жизни появился SonarQube.