💡Правильные ответы

1) При возникновении риска важно оценить, насколько серьезно он повлияет на пользователей, потребителей и др. лиц. Какие факторы НЕ могут влиять на это воздействие?
Ответ: все перечисленные факторы влияют.

❤️ Дополнение:
Определение уровня риска, как правило, включает в себя оценку каждого элемента риска, вероятность возникновения и влияние при наступлении. Вероятность возникновения - это вероятность того, что потенциальная проблема существует в тестируемой системе. Другими словами, вероятность — это оценка уровня технического риска. Факторы, влияющие на вероятность для рисков продукта и проекта, включают:
• сложность технологии и команд;
• личностные проблемы и проблемы подготовки среди бизнес-аналитиков, дизайнеров и
программистов;
• конфликт внутри команды;
• контрактные проблемы с поставщиками;
• географически распределенная команда;
• конфликт используемых и новых подходов;
инструменты и технологии;
• слабое управленческое или техническое руководство;
• время, ресурсы, бюджет и давление менеджмента;
• отсутствие мероприятий по обеспечению качества;
• высокие темпы изменений;
• высокий темп выявления ранних дефектов;
• проблемы взаимодействия и интеграции.

Воздействие при возникновении - серьезность эффектов для пользователей, потребителей или других заинтересованных лиц. Факторы, влияющие на воздействие рисков проекта и продукта, включают:
• частота использования затронутой функции;
• критичность функции для достижения бизнес-целей;
• ущерб репутации;
• потеря бизнеса;
• потенциальные финансовые, экологические и социальные потери или помехи;
• гражданские или уголовные правовые санкции;
• потеря лицензии;
• отсутствие разумных обходных путей;
• видимость отказа, приводящего к отрицательной рекламе;
• безопасность.
Уровень риска может быть оценен как количественно, так и качественно.

2) Выберите 5 основных метрик по ISTQB для контроля прогресса выполнения тестов:
Ответ: Риски продукта (качества), Дефекты, Тесты, Покрытие, Уверенность. А вот полнота тестовых данных по ISTQB уже относится к метрикам для мониторинга активностей по реализации тестов.

❤️ Дополнение:
Риски продукта, дефекты, тесты и покрытие могут быть зачастую измерены и отображены конкретными способами в течение проекта или активности. Если эти измерения связаны с определенными критериями выхода, указанными в плане тестирования, то они могут обеспечивать собой объективный стандарт для решения этого вопроса. Уверенность – это измеряемое путем опроса или использующее покрытие как дополнительную метрику; впрочем, в отчетах степень достоверности отражается субъективно.

3) Метрики для мониторинга активностей по реализации тестов могут включать: А) % конфигурации тестовой среды Б) % загруженных записей тестовых данных В) % автоматизированных кейсов Г) количество определенных тест условий
Ответ: А,Б,В - верно; Г-неверно

❤️ Дополнение:
Количество определенных тестовых условий относится к метрикам для мониторинга активностей анализа тестирования.
К ним также можно отнести количество дефектов, найденных при анализе тестов (например, при определении рисков
или других тестовых условий, использующих базис тестирования)

4) Как называется модель из 5 уровней, каждый из которых одновременно отражает степень зрелости команды и эволюционный путь к улучшению процесса тестирования?
Ответ: TMMi

❤️ Дополнение:
TMMi состоит из пяти уровней зрелости и призвана дополнить CMMI. Каждый из уровней зрелости содержит определенные области процесса, которые должны быть завершены на 85% путем достижения конкретных и общих целей, прежде чем организация может перейти к следующему уровню.

По ISTQB уровнями зрелости TMMi являются:

🔸Уровень 1: Начальный
Начальный уровень представляет собой состояние, в котором нет официально задокументированного или структурированного процесса тестирования. Тесты обычно разрабатываются в каждом отдельном случае после кодирования и тестирование рассматривается как отладка. Под целью тестирования понимают доказательство того, что программное обеспечение работает.

🔸Уровень 2: Управляемый

Второй уровень достигается, когда процесс тестирования отделен от отладки. Это может быть достигнуто путем установки политики и целей тестирования, вводя шаги, найденные вфундаментальном процессе тестирования (например, планирование тестирования), а также внедрение основных методов и техник тестирования.

🔸Уровень 3: Стандартизованный
Третий уровень достигается, когда процесс тестирования интегрируется в жизненный цикл разработки программного обеспечения, и задокументирован в формальных стандартах, процедурах и методах. Проводится рецензирование и выделен отдел тестирования, который контролируется и управляется.

🔸Уровень 4: Измеряемый
Четвертый уровень достигается, когда процесс тестирования эффективно измеряется и управляется на организационном уровне в интересах конкретных проектов.

🔸Уровень 5: Улучшаемый
Конечный уровень представляет собой состояние зрелости процесса тестирования, когда данные из процесса тестирования могут быть использованы для предотвращения дефектов и акцент делается на оптимизацию установленного процесса.

5) Вы, как руководитель, выбираете инструмент для тестирования в команде. И проводите анализ отношения затрат к прибыли перед его покупкой (возврат инвестиций (ROI)). Что нужно отнести к повторяющимся затратам?
Ответ: лицензия и стоимость поддержки (лайк, если увидел, что ответ продублирован 😉), расходы на обучение и наставничество, поддержание артефактов, созданных с помощью инструмента

❤️ Дополнение:
Нерегулярные затраты могут включать:
• описание требований к инструменту для удовлетворения целей и задач;
• оценка и выбор подходящего инструмента и его поставщика;
• покупка, адаптация или разработка инструмента;
• проведение вводного тренинга по инструменту;
• интеграция инструмента с другими инструментами;
• получение аппаратного и программного обеспечения, необходимого для работы
инструмента.

6) Что из перечисленного НЕ относится к большим группам активностей завершения тестирования?
Ответ: Анализ тестирования

7) Когда дефект обнаружен или наблюдается сбой, информация должна быть собрана и включена в отчет о дефекте. Эта информация должна удовлетворять трем целям
Ответ: управление отчетом на протяжении всего жизненного цикла дефекта, оценка состояния проекта, особенно с точки зрения качества продукции, а также оценка прогресса тестирования

❤️ Дополнение:
Различные стандарты и документы, такие как ISO 9126 [ISO9126] (был заменен на ISO 25000), IEEE
829 [IEEE829], IEEE 1044 [IEEE1044], и Ортогональная Классификация Дефектов, используются, чтобы помочь руководителю тестирования определить, какую информацию собрать для отчетности по дефектам.

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

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

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

Словарь тестировщика

#testing #QA #ISTQB #тестирование #тестировщик #it #айти

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

А для тех, кто не успел принять участие или не попал в текущую группу, объявляем новый набор!

✅ Дату старта напишу позже, а пока предварительно можете записаться через сайт https://tech.wildberries.ru/techschool/courses/manual-testing.

Напомню, что обучение бесплатное, вас будут сопровождать опытные менторы, лиды команд, а по завершении стажировки вы можете попасть в команду Wildberries 💜💜💜


#Testing #QA #Тестировние

Заметки тестировщика