Привет, Хабр! Я — Ольга Султанова, руководитель тестирования в Рунити. Сегодня я расскажу о QA-метриках, которые мы применяем в работе: как мы их внедряли, как собираем данные, как автоматизируем и анализируем. А также о том, какие у нас стоят пороговые значения и о том, какие действия мы предпринимаем, когда они нарушаются.
Привет, меня зовут Олег Уланов (aka brain). Я занимаюсь пентестами веб-приложений и активно участвую в багбаунти, зарабатывая на чужих ошибках. Свой путь в наступательной безопасности я начал совсем недавно, но, несмотря на это, меньше чем за год мне удалось ворваться в топ-10 исследователей на Standoff Bug Bounty (сейчас я на 5-м месте — можете проверить 😉).
В своем дебютном посте кратко расскажу об уязвимости с подделкой запросов на стороне сервера (SSRF) и ее видах, покажу, как обнаруживать этот баг и почему его стоит искать даже на статических сайтах, а заодно подсвечу особенности работы с Burp Suite, Collaborator Everywhere и Wappalyzer. Статья будет полезна для прокачки скилов и поможет легче и быстрее обнаруживать SSRF в сервисах, размещенных на площадках багбаунти.
Когда я только начинала работать тестировщиком, снифферы трафика казались мне чем-то далеким. В голове было что-то типа: "Ну, это для тестировщиков мобилок и для разработчиков. Мне оно не надо". Но потом я постепенно начала их использовать и поняла, что сниффер это маст хэв вещь в некоторых случаях!
В этой статье расскажу о нескольких кейсах, где снифферы трафика могут реально сохранить кучу времени и некоторое количество нервов. Let's go!
Всем привет, меня зовут Антон Огольцов, я отвечаю за процессы тестирования в компании Integro Technologies. Мы являемся системным интегратором, представляющим услуги по разработке, внедрению и поддержке IT-решений для авиакомпаний, аэропортов и наземных служб.
Сегодня предлагаю рассмотреть опыт использования инструмента TMS (Test Management System) – Test It. Мы проведем анализ функциональности, удобства использования и эффективности данного ПО. На Хабре много статей, описывающих использование Test IT для управления автоматизированным тестированием, наша цель – поделиться с читателями опытом использования TMS в части мануального тестирования.
Данную статью я разделил на две части. В первой мы сравним функциональность Test IT с ранее используемым Confluence и Jira для работы с тест-кейсами/тест-сьютами и фиксацией результатов тестирования. Во второй части рассмотрим использование общих шагов, пред- и постусловий секций и кейсов, а также ознакомимся с процессом создания тест-планов и ходом выполнения тестирования с последующим составлением отчета и аналитики по прохождению тест-планов.
Для автоматизации проведения тестов QA существует множество различных инструментов, они предлагают разный функционал и обладают различными возможностями.
Lettuce — это инструмент тестирования на Python, который предоставляет высокоуровневый API для написания тестов. Он предоставляет понятный и простой интерфейс API для тестирования с такими функциями, как автоматическое редактирование, шаблоны тестов и многое другое. Lettuce также построен на базе платформы Behavior Driven Development (BDD), которая помогает упростить разработку тестов, предоставляя клиентам общие утверждения BDD, такие как @given или @when.
Привет! Я Катя Глушанина, тестировщик в 2ГИС. В далёком 2019 год в нашей компании было не так много сотрудников, а тестировщиков в веб-отделе — ещё меньше. Мы все работали в офисе, много общались и решали вопросы на месте. Ламповость атмосферы была включена по умолчанию. Компания начала расти, и с этим пришли новые вызовы. Стало больше команд, тестировщиков, появились удалённые сотрудники.
Это привело к трём «побочным эффектам»:
Сложности коммуникации. У нас 11 часовых поясов, и это иногда тормозит доставку фич. Например, у меня возник вопрос, а тот, кто может с ним помочь ещё не начал работать или уже закончил.
Нет обмена знаний. В распределённых командах могут чаще придумываться велосипеды.
Чувство изоляции. Одному дома может быть грустно: даже мем не с кем обсудить.
И мы поняли, что нужно что-то менять.
Про тестирование PWA есть много разрозненных мнений, подходов и обособленных принципов, иногда противоречащих друг другу. Мы в Red Collar решили испытать на себе несколько вариаций подхода к тестированию таких приложений.
Привет!
Юнит-тесты позволяют предотвратить ошибки и значительно упростить процессы рефакторинга и поддержки кода. Их реализация существует во всех языках программирования и Rust - не исключение.
Юнит-тесты в Rust обычно располагаются в том же файле, что и тестируемый код, в специальном модуле с именем tests, аннотированном #[cfg(test)]. Внутри этого модуля размещаются функции тестирования, каждая из которых также аннотируется как #[test].
Проведение анализа дефектов, обнаруженных на продакшене, кажется сложной и трудоемкой задачей. Однако в команде Polymatica мы успешно интегрировали этот процесс в цикл тестирования, сделав его неотъемлемой частью обеспечения качества ПО. Локализация дефектов с прода имеет наивысший приоритет, и мы создали эффективный подход для их анализа и устранения. Данный процесс постоянный и непрерывный, что позволяет нам постоянно совершенствоваться.
Инструменты для тестирования методом «чёрного ящика» сосредоточены на анализе входных и выходных данных программного обеспечения, его поведения и функциональности с точки зрения конечного пользователя. Они используются для различных типов тестирования, включая функциональное, системное и приёмочное, не требуя доступа к исходному коду.
Преимущества этих инструментов заключаются в их способности обеспечить объективную оценку внешних функций программного обеспечения. Они помогают убедиться в том, что разрабатываемый софт соответствует требованиям пользователей и ведёт себя ожидаемым образом в реальных ситуациях. Эти инструменты особенно полезны для выявления несоответствий в функциональности и интерфейсе программы, что делает их идеальными для тестировщиков без глубоких технических знаний о внутреннем устройстве софта. Такой подход способствует ориентированности на пользователя. В этой статье представлен обзор 13 инструментов для тестирования методом чёрного ящика.
Чтобы быстро продвигаться в рабочих задачах, необходимо иметь уверенность в том, что можно вносить изменения. А уверенность в изменениях зависит от тестового покрытия.
С тех пор как мы это поняли, автоматические тесты стали просто необходимы. Это привело к массовому внедрению шаблонов для старта работы. Однако просто начать работу недостаточно.
Гексагональная архитектура стала популярным архитектурным паттерном, помогающим отделить бизнес-логику от инфраструктуры. Такое разделение позволяет откладывать принятие решений о технологиях или легко заменять их. Кроме того, это позволяет тестировать бизнес-логику в изоляции от внешних систем.
В этой статье мы рассмотрим, как реализовать гексагональную архитектуру в Spring Boot приложении. Мы разделим бизнес-логику и инфраструктуру на отдельные модули и посмотрим, как можно изолированно реализовать и протестировать эти модули.
Данная статья представляет собой практическое руководство и предполагает, что читатель имеет базовое представление о принципах, лежащих в основе гексагональной архитектуры.
В этой статье содержится список из 10 репозиториев на Github: дорожные карты для карьерного роста, подборки книг, списки курсов, инструменты для упрощения процесса тестирования и многое другое. Независимо от вашего опыта, эта подборка поможет быстро сориентироваться в мире тестирования и оставаться на переднем крае этой динамичной области.
Здравствуйте вам каждому. Мы — Дмитрий и Павел, специалисты по тестированию в ITFB Group. В нашей работе, как и у любого тестировщика, есть много рутинных, однотипных задач. Делать их не хочется, но без них нельзя. К счастью, нам теперь могут помогать генеративные нейросети.
Мы решили исследовать возможности ChatGPT в нашей работе: чем он может быть полезен при составлении документации, написании тестовых сценариев и генерации автотестов. Конечно, это пока что не идеальный инструмент, но мы на своём опыте убедились, что в чем-то он уже может быть полезен многим тестировщикам.
Приглашаем под кат почитать про наш опыт.
Сталкивались ли вы с проблемой возникновения багов из-за пересечения включенных фичей в приложении? Или, возможно, была необходимость одновременно проводить большое число A/B-экспериментов в одном компоненте?
Некоторое время назад команда Почты Mail.ru решала задачу управления сложным состоянием приложения с большим количеством фичей и источников данных с помощью конечных автоматов. Нужно было ускорить разработку и тестирование, поддерживая возможность проведения более чем 20 А/В-экспериментов. На тот момент, я работал там над проектами портальной навигации и главной страницы.
Меня зовут Денис Стасьев. В этой статье расскажу о том, как мы внедряли машину состояний в одном из компонентов главной страницы Mail.ru — блоке новостей, что получили на выходе и ещё подробнее о том, почему в итоге остановились на XState.
Обычно планирование проводится с целью согласовать подход, набор обязательств, зависимости, необходимые затраты и график выполнения проекта. План — это договоренность между заинтересованными сторонами, поставщиками и участниками проекта, которая определяет:
• Какие ресурсы требуются и когда.
• Когда и кто будет выполнять задачи.
• Навыки, необходимые для выполнения задач.
• Инструменты и технологии, необходимые для выполнения плана.
• Какие результаты должны получить и в какой срок.
• Стоимость ресурсов.
• Процесс продвижения проекта/процесса по этапам.
• Риски, угрожающие выполнению проекта.
Жизнеспособность плана зависит от того, знают ли все участники проекта, что они делают и как.
Calculator, которому для загрузки данных из базы данных требуется объект dao (Data Access Object), то объект dao — это «реальный объект». Чтобы протестировать класс Calculator, необходимо предоставить ему объект dao, имеющий корректное соединение с базой данных. Кроме того, нужно добавить в базу данные, необходимые для тестирования.