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

Вступление

Привет, Хабр. Сегодня я расскажу вам про Record-and-Replay подход к тестированию т. к. я его понимаю. Оговорка про мое понимание не случайна. Про этот подход не так много общедоступных материалов, чтобы иметь некий common agreement относительно значения этого термина. Многое из того, что я опишу, является моими личными оригинальными находками, но, тем не менее, фраза record-and-replay, на мой взгляд, наилучшим образом описывает применяемые мной решения. Так что я буду использовать именно ее.

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

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

Ключевой постулат

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

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

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

ДИСКЛЕЙМЕР: На самом деле у каждого инструмента есть как минимум по несколько альтернатив, выбор из которых может привести к знатному холивару. Если у вас есть свои соображения на тему "автор дурак, надо было брать не Х, а Y", приходите в комментарии!

Каждый второй обыватель хочет зайти в “денежную” ИТ-отрасль через тестирование. И с развитием онлайн-образования появилось довольно много возможностей это сделать. Результат - QA, особенно уровня джуна, становится много. Как с ними конкурировать?

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

TL;DR

• У некоторых автопроизводителей есть сотни тысяч потенциальных комбинаций сборки отдельной модели автомобиля.
• Ford F-150, содержат 150 миллионов строк кода.
• В автомобилях Volvo 2020 года около 120 ЭБУ и 100 миллионов строк исходного кода. 10 миллионов условных операторов, 3 миллиона функций, которые вызываются в 30 миллионах мест в исходном коде.
• В 2017 году 40% стоимости нового автомобиля можно отнести на полупроводниковые электронные системы, что вдвое больше, чем в 2007 году. К 2030 году эта сумма приблизится к 50%.
• Сегодня в каждый новый автомобиль упакован полупроводниками на сумму около 600 долларов, состоящих почти из 3000 микросхем всех типов.
• Автомобильный сетевой жгут, к которому могут быть прикреплены тысячи компонентов, может содержать более 1500 проводов общей длиной 5000 метров и весом более 68 кг.
• 40% бюджета на производство автомобиля с момента его разработки до начала производства можно отнести на счет системной интеграции, тестирования, проверки и валидации.
• По оценкам VW, только 10% программного обеспечения в его автомобилях разрабатывается собственными силами. Остальные 90% вносят десятки поставщиков, а у некоторых OEM-производителей это число, как сообщается, достигает более 50.
• Почти 60% затрат на рабочую силу при ремонте столкновения с транспортным средством с расширенными функциями безопасности связано с электроникой транспортного средства.
• 2019 год стал рекордным: 15 миллионов автомобилей были отозваны из-за дефектов электронных компонентов. Половина отзывов связана с дефектами программного обеспечения.
• В GM 90 инженеров на постоянной основе работают над разработкой средств кибербезопасности.
• 25 гигабайт данных в час — трафик внутри автомобиля

Привет, Хабр! Меня зовут Максим Бутаков, я работаю руководителем отдела контроля качества и тестирования в компании «ВТБ Лизинг». Сегодня я хочу рассказать о создании этого направления: о том, как нам удалось менее чем за три года улучшить качество продукта и существенно уменьшить количество багов. Думаю, под катом найдётся чем вас удивить.

Всем привет! Данная ошибка является очень популярной при использовании Selenide автотестах в Java. На поиск решения у меня ушло довольно много времени, поэтому в этой статье я хочу подробно рассказать про эту ошибку и как с ней работать.

Привет, Хабр! На написание этого поста меня вдохновил другой пост TDD есть опиум для народа, где обсуждаются спорные моменты в подходе TDD и в принципе делается вывод о его несостоятельности (хотя и признается необходимость тестов в любом случае). С автором я был полностью согласен... раньше, пока не понимал действительную суть TDD. Поэтому, я счел своим долгом рассказать суть Test Driven Development от лица человека, который пробовал писать тесты до реализации, разочаровался из-за сложностей, и только через некоторое время, уловив основную мысль, увидевшего новые возможности в разработке через тестирование.

Замечание: я всего лишь junior, и опыта разработки у меня не так много. Но надеюсь, что мне удастся донести мысль до читателя, а ошибки помогут исправить в комментариях. Примеры будут на Kotlin, мне кажется, это не должно стать помехой, язык достаточно хорошо читаемый. Несмотря на довод о слишком упрощенных примерах (наподобие калькулятора) в оригинальной статье, здесь я также не иду в дебри реальных повседневных задач, ограничиваясь кустарным примером. Да простит меня читатель, я не хочу заставлять сильно вникать в код, хочу просто объяснить идею.

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

Внедрить СХД для видеонаблюдения довольно легко. 

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

Привет, я Роман, Senior Engineer отдела QA Auto в inDriver. Примерно год назад у нашей команды возникла идея разгрузить ручных тестировщиков и автоматизировать процесс коммуникации между ними, когда они хотят прогнать тесты. Результатом стало создание сервиса Porter по автоматизации очередей тестирования, о котором я расскажу в этой статье. 

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

Что, если бизнес компании заключается в приеме и обработке платежей во множестве стран в режиме 365/24/7? В этом случае одной из ключевых целей ее сотрудников является доступность сервисов 99,999%. А к CI/CD в таких условиях предъявляются особые требования.

Заместитель директора департамента эксплуатации и разработки сервисных систем ECOMMPAY IT Федор Васильев на конференции HighLoad++ Весна 2021 рассказал об эволюции подходов его компании к деплою нового кода. А мы сделали на основе его доклада полезную статью, которую вы найдете под катом. 

Disclaimer.

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

Если вы раньше не писали unit-тесты, но хотите начать, не уверены как тестировать вашу БД и нужно ли это, не знаете как использовать моки, и для чего они, то эта статья может стать началом вашего пути.

А ещё здесь есть драконы - и это нормально.

Привет, Хабр! Меня зовут Руслан, я — автотестировщик в QA-агентстве «Кавычки». Из этого можно понять, что мы в агентстве занимаемся только тестированием во всех его проявлениях, а меня зовут Руслан. Отлично, идем дальше. Когда какая-то проблема начинает сильно докучать, то даже тестировщики могут что-то создать (ну или сломать это к черту, чтобы не мешало). Это статья как раз про тот случай, когда наша проблема перешла совместимый с жизнью болевой порог, и нам пришлось решить ее с помощью собственной разработки.

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

Привет, Хабр! Меня зовут Владимир, я работаю программистом в компании Quadcode. Вот уже почти полтора десятилетия я при помощи доброго десятка языков программирования разрабатываю приложения - от простых, вроде маленького плагина для Emacs, до сложных распределенных систем. Последние 4 года своей жизни я посвятил компании Quadcode, где занимаюсь разработкой транспортной подсистемы. Лет пять назад я вплотную столкнулся с адептами TDD (test-driven development) и это произвело на меня настолько сильное впечатление и оставило так много эмоций, что я написал “для своих” критический разбор наиболее часто встречаемых мною тезисов об этой технике (я бы даже сказал - учении). До сих пор мое мнение о TDD не изменилось, так что хотел бы описать его под катом и предлагаю обсудить вместе спорные моменты в комментариях.

Опытный тестировщик, особенно если он со своим проектом знаком давно, накидывает список тест кейсов довольно ловко. Но если вы еще только формируете свой профессиональный стиль или пришли в новый продукт, или просто открыты обмену опытом то, вероятно, вы найдете что-то значимое для себя в статье ниже.

„Вы говорите, что выбирать надо из двух зол?! Тоже мне ассортимент!“
Веслав Брудзиньский

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

Дабы разобраться в теме сделаем тест-драйв провайдеров и проведем сравнение сопоставимых услуг. Столкнем лбами 13 компаний. Мы взяли представителей разных ниш, отличающихся, как широтой услуг, так и ценами, с тем, чтобы выборка была репрезентативной и показала срез рынка. Итак, разместим хостеров в алфавитном порядке:

Один тестировщик может протестировать что угодно, кроме самого себя. А два, как известно, могут протестировать вообще всё. В этой статье мы расскажем, как на самом деле обстоит процесс подбора тестировщиков в hh.ru.