QA
Трагедия карьерного роста состоит в том, что человек чаще всего демонстрирует лучшие рабочие качества не тогда, когда ему дают возможности, а тогда, когда его запихивают в ситуацию «спасай» или «выкручивайся как хочешь».
Прошлым летом у нас с женой возникло желание обзавестись своей дачей. Хотелось получить MVP загородной жизни, чтобы попробовать её на вкус, но не залезать в долги и не вкладывать в этот эксперимент огромные суммы. Брать участок с готовым домом — лотерея и у нас не было опыта, чтобы не купить кота в мешке. Строить дом с нуля — нереально дорого. Рассматривали много вариантов, в итоге купили пустой участок и поставили туда добротную утепленную бытовку.
И я, как техно-гик, конечно же, не смог устоять — начал делать из нее умный дом умную бытовку и оснащать всем необходимыми для комфортной жизни. Об этом опыте хочу рассказать в статье.
Итак, поехали!
Привет, Хабр! Принесли полезный контент для всех, кто пишет автотесты на Python. В подборке — видео докладов с последнего AQA-митапа: о плагинах Pytest, архитектуре автотестов для продукта на open source-движке, а также о критериях понятных тестов (и как их соблюдать на практике). Материалы будут полезны как начинающим, так и опытным AQA-инженерам. Под катом — все видео и ответ на вопрос, зачем это смотреть, от гостей митапа.
Привет, Хабр! На связи участница профессионального сообщества NTA Александра Грушина.
Поговорим о важности написания тестов к своему коду, о магии подхода test-driven development. Я расскажу о своём пути: от первого знакомства с концепцией TDD до умелого использования инструментов тестирования на Java (Junit 5 + Mockito).
Туториал по работе с логами в Kibana для начинающих специалистов по тестированию ПО.
У Kibana имеется свой язык запросов KQL (Kibana Query Language) - официальный источник. С помощью этого языка можно составлять запросы, которые помогают отфильтровывать и найти необходимую информацию.
Подключение к Kibana для просмотра логов.
Привет, хабр. Меня зовут Кияшева Екатерина и я руковожу тестированием. Сегодня хочу поделиться своим чит‑листом обо всем.
Чит‑лист — набор стандартных проверок для многократного использования в различных приложениях, одинаковых по какой‑либо характеристике.
Я использую чит‑лист с тремя целями: передаю его своим коллегам, чтобы маст-хэв тесты не были забыты, заглядываю в него перед проверкой тестового покрытия коллег на малознакомом проекте, проверяю себя в ходе вычитки техзадания и при тест‑дизайне.
Хочу, чтобы его было полезно и удобно использовать, поэтому буду рада предложениям и комментариям по его расширению и упрощению.
Как правильно писать UI авто тесты на python используя Playwright, Page Object, Page Component, Page Factory.
Как правильно писать API авто тесты на Python используя Pytest, Pydantic, Httpx, Allure.
Эта статья как продолжение статьи Как правильно писать UI авто тесты на Python. Если мы говорим про UI автотесты, то тут хотя бы есть паттерны Page Object, Pagefactory; для API автотестов таких паттернов нет. Да, существуют общие паттерны, по типу Decorator, SIngletone, Facade, Abstract Factory, но это не то, что поможет протестировать бизнес логику на уровне API тестируемой системы
От автора: в этой статье я поделюсь своим опытом тестирования микросервисов. В последние годы команды разработчиков программного обеспечения внедряют архитектуру микросервисов, чтобы иметь возможность разрабатывать, тестировать и деплоить сервисы независимо и быстро. Для эффективного тестирования таких систем необходимо хорошо знать их архитектуру.
Именно этой строкой начинается Agile манифест. И вроде бы это очевидно: сотрудники - главный ресурс любой компании. Однако на практике очень часто приоритеты сдвигаются в другую сторону и на первое место выходят: метрики, релизы, цели, задачи, события.
А как же люди? Ведь именно их отношение к работе, их мотивация и определяет итоговый результат.
Связь мотивации и эффективности очевидна: мотивированный сотрудник способен более длительное время удерживать фокус внимания на объекте своей деятельности. Он проявляет больше упорства в преодолении различных трудностей, более охотно принимает ответственность за результаты своей деятельности.
Поэтому один из пунктов Agile манифеста и гласить: над продуктом должна работать команда замотивированных профессионалов.
Окей, уровень профессиональных компетенций можно определить путем различных видов тестирования. И развивать их за счет внутреннего и внешнего обучения. А как быть с мотивацией? Много ли компаний оценивают на входе мотивационных профиль своих сотрудников?
Забегая немного вперед, сразу хочу сказать, что мотивация, по сравнению с другими различными профессиональными характеристиками, - структура весьма динамичная. И перемены ее уровня могут происходить скачкообразно как вверх, так и вниз. Как и изменение самой структуры мотивации.
Как правило, при устройстве на работу, мотивация сотрудника сильно детерминирована материальными факторами: уровнем зарплаты, социальным обеспечением, стабильностью, перспективами роста и т.д.
И тут вроде все понятно: есть ДМС, инструменты премирования по ключевым показателям эффективности, карьерный гайд, печеньки к кофе. Чего еще надо? Однако все это относится к инструментам мотивирования (стимулирования), а не к мотивации.
Год назад для собственных нужд я написал обертку Yandex SpeechKit на Python, она получилась настолько простая и универсальная, что грех не поделиться : )
Попробуем в несколько итераций написать API тесты на Python и рассмотрим типичные ошибки, с которыми можно столкнуться.
Здравствуйте, уважаемые читатели!
В прошлой статье я поделился историей переезда в Словению, с тех пор прошло не так много времени, но судя по количеству запросов в личку, эта тема актуальна для многих айтишников и не только. Поэтому решил рассказать про жизнь в этой маленькой европейской стране, которую часто путают со Словакией.
На днях будет ровно 2 года как я официально получил ВНЖ в Словении по бизнес программе и это был очень насыщенный период жизни и адаптации. Но обо всем по порядку.
«Вначале было слово и это слово было два байта»
Старая шутка программистов
В практике работы отдела тестирования редко, но всё же возникают разногласия между участниками проекта, не являющимися тестировщиками, в неверной трактовке терминов вплоть до не совсем полного понимания что же такое «тестирование». Почему то, что существует на проекте не относится не только к «обеспечению качества» но и даже к «контролю качества». Я постараюсь объяснить разницу между этими терминами на примере очень условного «проекта», который зарождается не в большой корпорации с несколькими участниками, а буквально «на коленках» энтузиаста-Разработчика.
Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.
Это та причина, по которой многие подрядчики стараются избегать таких требований, как огня, что перекладывает риски во времени на более поздние этапы и на заказчика.
Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.
Стандарты по программной и системной инженерии предлагают десятки видов атрибутов качества системы, а заказчики требуют, чтобы система была удобной, быстрой, надёжной и безопасной.
При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?
С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».
Пока что умение специалистов и команд выявлять и формулировать такие ограничения представляет собой скорее искусство, а не ремесло, и не инженерию.
Давайте попробуем сделать это хотя бы ремеслом.
В этой статье я не буду рассказывать про успешные внедрения, лучшие практики и общеполезные методики. Я вообще не буду давать какие-либо советы. Наоборот, попытаюсь на основании своего опыта рассказать, как бывает плохо, какие практики быстро становятся ужасными и чего нужно опасаться.
