Какого объема тестирования достаточно? Это классический, не имеющий ответа философский вопрос, который задают все тестировщики, потому что заинтересованные стороны задают его им самим.

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

Пирамида автоматизации тестирования Майка Кона помогла многим командам с начала 2000-х годов.С тех пор мы немного подкорректировали её, чтобы уточнить наши цели, добавили облако сверху, чтобы показать, что не все регрессионные тесты можно автоматизировать. Иногда нам нужны тесты, ориентированные на человека, которые включают в себя исследовательские тесты (ИТ - exploratory tests).

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

Terraform - это инструмент с открытым исходным кодом, реализующий концепцию "Инфраструктура как код" и разработанный компанией HashiCorp. 

В своем декларативном характере Terraform позволяет разработчикам использовать высокоуровневый язык конфигурации HCL (HashiCorp Configuration Language) для описания желаемого состояния облачной или локальной инфраструктуры, предназначенной для запуска приложений. Следующим шагом является формирование плана достижения данного состояния и выполнение этапа подготовки инфраструктуры.

Mountebank - это мощная платформа для тестирования API и mocking-a, предоставляющая пользователям функционал и инструменты для создания гибких, настраиваемых и надежных тестовых окружений. В этой статье автор рассмотрит настройку Mountebank на реальном примере.

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

Позвольте мне рассказать вам историю...

Я хотела бы поделиться с вами несколькими хорошими практиками, которым я научилась в процессе работы – но как бы мне хотелось их знать, когда я только начала свое путешествие в мир автоматизированного тестирования. Хотя то, что мы называем «лучшей практикой», не обязательно подойдет для конкретного проекта или специалиста. В статье вы найдете советы о том, как можно улучшить свой фреймворк автоматизации на Selenium C#.

Сегодня специалистам по тестированию и менеджменту необходимо достичь оптимального баланса между скоростью и качеством при поставке программного обеспечения для современного бизнеса. Если вы стремитесь пересмотреть процесс обеспечения качества с целью ускорения выпуска продукта и внедрить непрерывное тестирование (Continuous Testing), то эта статья для вас.

Поговорим о важности хорошей документации в разработке ПО с использованием "user stories" (US) и "acceptance criteria" (AC). Автор предостерегает от ситуаций, когда разработка не соответствует ожиданиям заказчика из-за недостаточной документации.

Основное внимание уделено AC, которые определяют условия, необходимые для принятия продукта пользователями. Текст разъясняет цели и структуру AC, подчеркивая их важность для уточнения требований, управления сценариями и обеспечения коммуникации между заказчиком и командой разработки.

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

В чем ценность QA-метрик? Есть ли смысл тратить усилия на измерение, анализ, проверку, а затем на принятие действий в соответствии с полученными результатами? Тип и необходимость QA-метрик изменились с популярностью и широким распространением методологии разработки программного обеспечения Agile.

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

Риски, если они материализуются, оказывают негативное влияние на наши проекты. Управление рисками — это осмысление существующих рисков и принятие мер по снижению их вероятности, устранению или уменьшению их влияния на цели наших стейкхолдеров.

С точки зрения тестирования и обеспечения качества, риск — это "тип неудачи, о котором следует беспокоиться”. Тестирование на основе рисков — это практика моделирования возможных режимов отказа системы как рисков продукта для определения объема тестирования, масштабирования и установления приоритетов.

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

Сегодня я хотел бы поговорить об одной распространенной ошибке в автоматизированном тестировании с использованием BDD, а именно – об использовании императивных описаний тестов вместо декларативных.

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

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

Тенденцией современности является изучение всё большего количества инструментов для автоматизации, но мышление QA важнее.

На одном из моих уроков я бросил вызов студентам: «Сделайте диаграмму тестирования». Одни начали рисовать сложные изображения, другие – простые. Одни буквальные, другие метафорические. Но многие испытывали трудности, пытаясь сосредоточиться на самом процессе тестирования. Если вы действительно хотите стать мастером в этой области, вам нужно научиться заглядывать в себя, вызывать образы и слова, а затем создавать практические и концептуальные артефакты из них. 

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

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

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

Современным специалистам по тестированию и управлению необходимо достичь оптимального баланса между скоростью и качеством при разработке программного обеспечения, которое способствует развитию современного бизнеса. Если вы хотите привести свой процесс обеспечения качества к ускоренной доставке и непрерывному тестированию (Continuous Testing), то эта статья для вас.

Независимо от того, какую платформу для автоматизации тестирования вы используете, Cypress, Playwright, Selenium or WebDriver.IO, важным фактором является время выполнения тестов. 

В рамках подхода ”Shift left“ тестированию отводится большая роль в получении более раннего фидбэка. Если более классический подход предусматривает достаточно длительные периоды тестирования, то при быстрых feedback loops для тестирования остается не так и много времени.

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

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

Google Chrome является одним из самых популярных браузеров для всех тестировщиков по всему миру. Он позволяет нам повысить производительность, не выходя из Интернета. У браузера есть множество возможностей, которые делают Google Chrome надежным, безопасным, умным и более продуктивным браузером. Как тестировщикам, нам нужно, чтобы наша работа выполнялась эффективно и более разумно.  

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

Давайте познакомимся с каждым расширением по порядку и внедрим их в нашу повседневную деятельность по тестированию. 

Добро пожаловать!

Ежедневной задачей инженера по контролю качества (QA Engineer) является создание тест-кейсов для проверки требований продукта. В этой статье я собрал для вас техники проектирования тестов, которые помогут оптимизировать ваш набор тестов.