​​Алоха! Сегодня продолжаем рубрику #вопросытестеру, где мы разбираем вопросы, которые задают тестировщикам при найме на работу

#вопросытестеру #собеседование

Теория тестирования
Часть 2:

📍Вопрос 1: Что такое Performance Testing?

✅Краткий ответ:

Тестирование производительности, или Performance Testing — это процесс проверки и оценки работы системы или приложения в условиях реальной нагрузки с целью определить их способность функционировать при заданных параметрах производительности.

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

В процессе тестирования производительности обычно проводятся следующие виды тестирования:
1. Нагрузочное тестирование: система проверяется работоспособностью и производительностью при заданной нагрузке, на которую она должна быть способна.
2. Стресс-тестирование: система проверяется на предельной нагрузке, превышающей ожидаемую реальную нагрузку, чтобы определить ее предельные возможности и стабильность.
3. Профилирование производительности: система анализируется с помощью инструментов профилирования для выявления проблем и оптимизации производительности кода и алгоритмов.
4. Тестирование пропускной способности: система проверяется на способность обрабатывать и передавать указанное количество данных или запросов в заданные сроки.
5. Тестирование стабильности: система проверяется на способность работать без ошибок и сбоев в течение продолжительного времени.

📎Материалы по теме:
- Нагрузочное тестирование vs Тестирование производительности
- Тестирование производительности (Performance testing): основные концепции

📍Вопрос 2: Что такое Regression и Confirmation тестирование, какая между ними разница?

✅ Краткий ответ:

Regression Testing (регрессионное тестирование)- это процесс повторного тестирования уже протестированных функций или компонентов системы после внесения изменений. Цель Regression Testing заключается в том, чтобы убедиться, что изменения не вызвали непредвиденных проблем или не повлияли на уже работающие функции или компоненты. Подход к Regression Testing заключается в создании и выполнении набора тестовых сценариев, которые покрывают ключевые функции и используются для проверки, что система по-прежнему работает должным образом после изменений.

Confirmation Testing (повторное тестирование), с другой стороны, является подтверждением того, что предыдущие проблемы были исправлены или недостатки были устранены после Regression Testing. Цель Confirmation Testing состоит в проверке, были ли обнаруженные ранее проблемы и дефекты действительно исправлены. В основе Confirmation Testing лежит набор тестовых случаев или сценариев, которые ранее привели к ошибкам или проблемам, и повторное выполнение этих сценариев для проверки, что исправления были успешными.

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

📎Материалы по теме:
- Повторное тестирование против регрессионного тестирования
- Разница между повторным тестированием и регрессионным тестированием

Источник: @qa_and_it

Лидерство в тестировании: моделирование и покрытие

Источник статьи | Testing QA

​​Алоха! Сегодня поговорим о двух непохожих понятиях в мире разработки программного обеспечения - Use Case и User Story. И я постараюсь кратко и понятно рассказать, что же это такое и в чем разница, и можно ли их вообще сравнивать.

#usecase #userstory | BA\SA

Начнем с такого понятия как "Use Case"🙋‍♂️ - эта штука похожа на историю, которая рассказывает разработчику о том, как система должна взаимодействовать с пользователем. Если говорить простыми словами, это такая маленькая пьеска, которую актеры (пользователи) выступают перед системой, дабы получить необходимые им результаты. Каждый Use Case описывает один конкретный сценарий, начиная от входа пользователя в систему и заканчивая тем, как пользователь получает свои результаты. Тут все очень структурировано и без лишней воды.

А теперь перейдем к "User Story"🙋‍♀️ - это просто история из жизни, но повествующая о желании пользователя и его потребностях.

Если говорить в примерах, то допустим, у нас есть пользователь по имени "Джимми - 💁‍♂️", который хочет купить в онлайн-магазине футболку.
Исходя из этого, User Story Джимми может выглядеть так:

"Как Джимми, я хочу купить оранжевую футболку размером М, чтобы выглядеть стильно и привлекать внимание девушек". Здесь мы описываем, что пользователь хочет сделать, почему ему это нужно и какой результат он ожидает.

p.s.Вместо скучных технических деталей, я использую простой язык, чтобы создать приятную историю!

Если говорить шаблонно, то User story будет содержать формулировку: "Как тип пользователя, я хочу действие, чтобы получить результат"

И, кстати, оба этих понятия очень полезны для команды разработчиков и бизнес-аналитиков. Use Case помогает визуализировать, как система работает от начала и до конца, что особенно пригодится, когда нужно разбить работу на части или протестировать систему в действии. А User Story делает счастливыми как разработчиков, так и бизнес-аналитиков, потому что они позволяют понять, что именно пользователи хотят и как это можно превратить в реальный продукт.

Основная разница между Use Case и User Story в том, что Use Case обеспечивает более детальное и структурированное описание, покрывая различные аспекты взаимодействия, тогда как User Story фокусируется на описании потребности пользователя и желаемых результатах

Истчоник: @ba_and_sa

Как написать идеальный автотест: 25 джедайских принципов

Источник статьи | Testing QA

Особенности разработки автотестов различными инструментами, а также статистика по использованию

Источник статьи | Testing QA

​​Путь становления. От стажёра до тестировщика

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

Перейти к статье | QApedia

JMeter как инструмент для автоматизации функционального тестирования


Перейти к статье | Testing QA

Тест: сумеете ли вы стать junior QA в большой компании

Источник статьи | Testing QA

​​API (Application Programming Interface) – это набор правил и протоколов, позволяющих различным программным системам взаимодействовать друг с другом. В современном мире разработки программного обеспечения API стал неотъемлемой частью системной архитектуры, позволяя разделить функциональность программ на логические блоки и предоставлять возможность использования этих блоков другими системами, как внутренними, так и внешними.

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

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

Важными аспектами при документировании API являются:

✍🏼1. Описание ресурсов и методов: Документация должна содержать описание всех доступных ресурсов и методов, которые поддерживает API. Каждый ресурс должен быть подробно описан, включая его структуру данных, список полей, доступные методы и возможные запросы/ответы.

📌2. Примеры использования: Хорошая документация должна содержать множество примеров использования API. Примеры помогут разработчикам быстрее разобраться в функциональности и особенностях API, а также позволят им быстрее начать пользоваться им.

🌐3. Схемы данных: Для каждого ресурса API должны быть предоставлены схемы данных, описывающие структуру объектов, передаваемых по API. Схемы данных могут использоваться в процессе валидации запросов и ответов, а также для генерации моделей данных в клиентском коде.

😨4. Ошибки и исключения: Документация должна содержать список возможных ошибок и исключений, которые могут возникнуть при работе с API. Каждая ошибка должна быть подробно описана, включая информацию о причинах ее возникновения и возможные способы ее решения.

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

⏱6. Частые обновления: Документация API должна быть актуальной и регулярно обновляться с выпуском новых функций и исправлениями. Это поможет снизить степень путаницы у разработчиков и повысит удовлетворенность пользователей API.

📑7. Интерактивная документация: Для удобства использования API стоит предусмотреть возможность создания интерактивной документации, где разработчики могут отправлять запросы и видеть результаты в реальном времени, а также иметь возможность пробовать различные последовательности запросов.

Правильное документирование API является важным шагом для обеспечения успешной интеграции и сотрудничества с другими системами. Четкая, полная и понятная документация может значительно упростить жизнь разработчикам и сэкономить время и усилия при работе с API.

Материалы по теме:
- Документирование API
- Что такое API документация и как ее правильно составить и использовать?
- How to Write Good API Documentation

«Кто не рискует, тот не поднимает прод в выходные»

@qa_and_it

Неизменная ценность ручных тестировщиков: важность и преимущества в эпоху автоматизации

Источник статьи | Testing QA

​​Обзор новой версии сертификации ISTQB Foundation Level 4.0 (2024) для Тестировщиков

Статья для тех, кто хочет узнать что нового в версии 4.0 но не хочет читать весь силлабус, ну или думает читать или нет:)

Перейти к статье | QApedia

Быть тупым тестировщиком

Источник статьи | Testing QA

Когда разраб принёс тестировщику новую фичу:

Postman: Основы тестирования API и первые шаги с инструментом

Источник статьи | Testing QA

Измерение покрытия python сервисов для end-to-end тестов

Источник статьи | Testing QA

Принципы по улучшению QA процессов в Agile команде

Источник статьи. | Testing QA

Когда метрики тестирования бесполезны

Источник статьи | Testing QA