Привет! Меня зовут Евгения Воропаева. Я занимаюсь тестированием в PIMS-команде СберМаркета, мы разрабатываем внутреннюю систему для отдела контента и производства. Проект существует уже 2,5 года и за это время PIMS рос и развивался, приходили и уходили люди, менялись подходы к работе, внедрялись новые практики. Методом проб и ошибок мы выстроили процессы в команде тестирования, которые считаем оптимальными. Хочу поделиться результатом, к которому мы пришли и надеюсь, наш опыт будет вам полезен.
В Dodo Engineering есть традиция: несколько раз в год айтишники ходят в пиццерии и начинают ломать им процессы тестируют, как продукт работает на местах. В этот раз мы, разработчики Небесного логиста, решили сломать их по-крупному и зарядили тест на три недели.
В этой статье поделимся опытом, как мы тестируем продукт в реальных условиях на реальных пользователях, как это помогает прорабатывать наши гипотезы. Расскажем о том, как наши ожидания сломались о реальность, о волне негатива, с которым мы столкнулись, и как превращали критиков в своих сторонников.
Несколько недель назад я решил написать о тестировании фиксов. Главной моей целью было определить, существует ли системный подход, которому можно было бы следовать в общих случаях. Анализируя это, я быстро понял решающую роль уверенности в проверке и одобрении любого тестируемого нами программного обеспечения.
Уверенность диктует, сколько тестов, по нашему мнению, нам нужно выполнить, прежде чем мы сможем подтвердить успешность тестирования. Уверенность в команде разработчиков напрямую влияет на то, сколько времени мы потратим на тестирование, чтобы почувствовать, что наш продукт готов к релизу. Эта уверенность основывается на нашем опыте общения с командой разработки и качества их кода в прошлом.
Высокая уверенность — выполняется только самое необходимое количество тестов, гарантирующих, что программное обеспечение может быть принято. (Примечание: это не относится к критически важным программным системам.)
Низкая уверенность — на основе предыдущего опыта тестировщики могут проводить дополнительные проверки, даже если нынешнее качество кода хорошее.
Я считаю, что уровень уверенности очень влияет на скорость, с которой программное обеспечение может быть разработано. Часто можно услышать, что «QA — это узкое место процесса разработки», но это потенциально связано с исторически низким качеством кода, заставляющим тестировщиков перетестировать, даже когда проверяется код хорошего качества. Чтобы проиллюстрировать этот момент, я привожу ниже подход, который я придумал для тестирования и проверки исправлений ошибок.
Если вы разработчик и когда-либо писали интеграционные тесты — скорее всего, вы использовали TestContainers. Появившись в 2015 году, эта библиотека изменила то, как мы производим автоматизацию тестирования, позволив разработчикам запускать интеграционные тесты с участием баз данных на локальных машинах, что существенно сократило сложность интеграционных тестов и время, необходимое для их запуска и прогона.
Testcontainers "по щелчку пальцев" запускают базы данных, но для того, чтобы тесты начали проходить, нужно кое-что ещё: начальные данные внутри базы. Их необходимо подготовить перед запуском тестов, а по мере того, как схема растёт и усложняется, делать это становится всё труднее.
Комбинируя Testcontainers с одной из доступных на сегодня библиотек для синтеза реляционных данных, мы теперь можем заполнять любую Testcontainers-базу данных сгенерированными данными, что позволяет быстро разрабатывать тесты для логики, предполагающие взаимодействие с базой данных, избегая при этом необходимости разрабатывать и поддерживать большие объемы кода.
При поиске решений для сборки больших проектов на Go с завидной регулярностью попадались отсылки на статьи про Bazel.
К сожалению, понимания того, как должна выглядеть разработка после миграции на Bazel они не давали. Попробуем разобраться...
Это первый пост из цикла, посвященного миграции с go build на Bazel.
К процессу миграции мы подошли на этапе, когда запуск тестов на CI занимал примерно от 15 минут до часа. При этом мы уже успели реализовать некоторое распараллеливание и кэширование результатов тестов. Без этого тесты на одной машине должны были бы идти примерно часов восемь.
После внедрения Bazel запуск тестов на CI в основном укладывается в интервал от 1,5 до 25 минут (50 перцентиль в районе 12 минут), что гораздо комфортнее исходной ситуации.
Оговоримся, что сравнение этих цифр «в лоб» несколько некорректно: с одной стороны, за время пути кодовая база стала еще больше, а с другой – поменялась топология CI. Но в целом представление о полученном эффекте они дают.
Далее опишем, за счет какого механизма достигнуто ускорение.
В моей предыдущей статье «Лидерство в тестировании: введение» мы исследовали концепцию тестирования с точки зрения его целей. Краткое резюме: независимо от того, о каком типе теста вы говорите, мой совет — всегда задавайте конкретную цель теста. Это верно, даже если кажется, что это общепринятый термин, такой как модульный тест или приемочное тестирование.
Здесь я объясню, как определить стратегию тестирования, которая заложит основу для надежного и гибкого процесса тестирования, подходящего для любой методологии разработки, используемой вашей командой. Я раскрою:
— Что такое стратегия тестирования?
— Структура стратегии тестирования
Какими навыками должен обладать успешный в своем деле
QA Engineer в 2023 году? Скорее всего, многие из вас в первую очередь подумают про навыки технического характера. Как будто только жесткие навыки (hard skills) являются гарантом стремительного профессионального и карьерного роста. Эта мысль верна, но подобная формула профессионального успеха выглядит неполной: в ней отсутствует упоминание о психологических и поведенческих навыках – гибких навыках, известных как soft skills.
Настоящая статья посвящена гибким навыкам (soft skills), без которых достичь профессионального успеха и становления попросту невозможно. Давайте обсудим наиболее важные навыки, которыми должен обладать каждый уважающий себя QA Enginner в 2023 году, и разберём для решения каких именно профессиональных задач они необходимы и почему.
Что же такое гибкие навыки (soft skills)? Во-первых, это качества, определяющие способность специалиста эффективно выстраивать рабочие процессы, решать возникающие на проекте проблемы, выходить из информационного кризиса и т.п.
Но, к сожалению, для большинства, особенно для тех, кому 30 и более лет, soft skills это лишь перечень прилагательных, указываемых в резюме в разделе «О себе» для галочки, в чём и заключается основная проблема: о них часто говорят, но не всегда уделяют достаточного внимания их развитию.
Рассмотрим подробно топ 10 самых важных гибких навыка, необходимых в профессии QA Engineer и IT отрасли в целом.
Привет, Хабр! Меня зовут Герман, я давно работаю в тестировании (ex Тинькофф, Островок, Яндекс).
Про тестировщика создаётся стереотип ворчуна, который постоянно всем не доволен и занимается только тем, что ищет изъяны в чужой работе.
Поделюсь своим опытом — как тестировщику критиковать и сохранить хорошие отношения с командой.
Твою критику не должны воспринимать в штыки. С командой тебе работать несколько лет, ходить с ними в барчик и ещё карьеру как-то строить.
Наверное каждый разработчик и QA-инженер, в рабочем процессе сталкивался с необходимостью подмены отправляемых/принимаемых данных. Когда эта задача касается данных, гуляющих между клиентом и сервером, особых проблем она не приносит. Запрос можно модифицировать и отправить ручками, к примеру через Postman, а для модификации ответа можно использовать инструменты вроде Burp Suite, Charles и т.д., но что делать если целевой запрос отправляется с сервера?
Рынок интернета вещей растет значительными темпами и разработка кода для микроконтроллеров важна для любых проектов, где подразумевается наличие какого‑либо вспомогательного оборудования или носимого устройства. Для разработки программного обеспечения под встраиваемые микроконтроллеры сейчас (кроме C/C++) можно использовать многие другие технологии (например, TinyGo, Dart/Flutter, Rust), так же как и Python в наборе библиотек MicroPython, который работает как со своей платой (pyboard), так и с другими микроконтроллерами (например платами на процессорах ESP8266 или STM32). В этой статье мы рассмотрим общие подходы к разработке и тестированию программного обеспечения для микроконтроллеров с использованием Python.
В марте исполнится два года с тех пор, как я, в то время ещё джун‑тестировщик без опыта, устроилась на работу в компанию «Синимекс». Сейчас моя должность — специалист по обеспечению качества. До перехода в IT я успела много лет проработать в журналистике и была, по мнению многих знакомых, тотальным гуманитарием. В этой статье я хочу поделиться своим опытом перехода — надеюсь, что моя история будет полезна тем, кто решил попробовать себя в IT и делает свои первые шаги на этом непростом и не всегда предсказуемом, но интересном пути.
К тому времени, как я решилась на поиски работы в сфере IT, за плечами у меня было десять лет работы в журналистике и гуманитарное образование. Приступать к освоению совершенно новой для меня области было непросто, но своё дело сделали пандемия коронавируса и профессиональное выгорание.
Думаю, мало чьей жизни не коснулись изменения 2020 года — периода, когда способы взаимодействия человека с другими людьми, условия и режим его работы, да и просто сама возможность выйти из дома стали сильно зависеть от эпидемиологической обстановки вокруг. В то время, когда из окон можно было следить за вереницами скорых, было сложно понять, что будет дальше и как приспособиться к новым условиям жизни. Очевидным было одно: настало время для изменений. И чем менее предсказуемым становится окружающий мир, тем больше гибкости от меня потребуется.
От журналистики, если честно, я и правда успела устать. И когда бывшая коллега, человек с разносторонним опытом работы в очень разных областях, предложила мне попробовать тестирование ПО («Ты ж редактор, они правят ошибки, и тестировщики тоже правят ошибки...»), решила — почему бы и нет?
Привет! Меня зовут Сергей, я в тестировании уже 11 лет и сейчас развиваю качество в компании QIWI. В этом посте я хочу рассказать вам, как сейчас выглядят наши продуктовые команды, куда подевалась роль тестировщика и поделиться некоторыми выводами.
Проблематика прошлого
Когда‑то у QIWI была довольно популярная структура. У нас были отделы разработки, аналитики, тестирования и прочее. Ребята из этих отделов объединялись в проектные команды и занимались проектом.
При этом одной из целей нашей компании — «Поставлять всё возрастающее количество качественных инкрементов, способствующих развитию приоритетных продуктов, не забывая при этом о людях в командах«.
И в рамках этой цели у нас в фокусе всегда было две вещи:
Всем привет, я пробовал в прошлом году сделать дайджест для qa инженеров, но в связи с событиями 24 февраля я не смог найти силы продолжить
В этом году я постараюсь делать дайджест на постоянной основе
Всем привет! Меня зовут Василий, я руковожу командой QA в Сравни. Сегодня хочу поделиться своим опытом найма и онбординга тестировщиков. По мере роста штата компании эти процессы видоизменялись, пандемия тоже внесла свои коррективы. Надеюсь, статья будет полезна всем, кто так или иначе участвует в найме сотрудников технических специальностей. Но обо всём по порядку.
Существуют признаки высококачественного программного обеспечения. Оно удобно в использовании, надежно и обеспечивает производительность. Любое программное обеспечение, которое изобилует ошибками, работает нестабильно или работает не так, как задумано, считается неудачным.
Это приведет к появлению недовольных клиентов и разочарованных сотрудников, а также заставит клиентов потерять доверие к продукту.
От RPA (Robotic process automation) до высокотехнологичной разработки программного обеспечения — ежедневно создается огромное количество приложений. От стартапов до крупных предприятий — компании всех типов и размеров занимаются разработкой программного обеспечения.
Если ваша фирма также занимается разработкой программного обеспечения или хочет его разработать в ближайшем будущем, как вы можете обеспечить его высокое качество?
В этом может помочь тестирование. Оно гарантирует, что программное обеспечение соответствует таким основным характеристикам, как удобство использования, надежность и производительность.
Тестирование на совместимость — одна из таких форм тестирования программного обеспечения.
За последние несколько лет разработчики ПО и мобильных приложений очень четко осознали важность тестирования. Его популярность непрерывно растет. Только в США этот рынок услуг должен вырасти на 55,76 миллиарда долларов в течение 2022-2026 годов.
В этом материале мы приведем основные тезисы из обзора рынка тестирования программного обеспечения в крупном российском бизнесе, который подготовлен редакцией портала TAdviser. Исследование подробно описывает подходы российских заказчиков к выбору технологий и инструментов тестирования, а также модели их использования, дает представление о трендах рынка и потребности его игроков в кадрах.
Это вторая часть статьи «Мессенджеры на работе — это не прокрастинация, или как мы сделали сервис для автотестирования». Как и обещали, в данной статье мы расскажем о том, как масштабировали наш сервис, как развивали функциональность автотестов и как в итоге вышли за рамки обычного репорт-бота.
Во многих компаниях использование брокеров сообщений является неотъемлемой частью процесса разработки высокопроизводительных систем. И одним из самых популярных на сегодняшний день является Kafka. Kafka — это не только брокер сообщений, но и разделитель журналов. Кроме того, с помощью Kafka мы можем моделировать различные сценарии тестирования. Но чтобы применить это на практике, нам нужен UI инструмент для работы с Kafka. Итак, в сегодняшней теме мы рассмотрим самые популярные UI инструменты и коснемся их функционала и возможностей для тестеров.
