Здавалка
Главная | Обратная связь

Взаимодействие тестировщиков и клиентов



Все знают, что…

• Разработка ПО существует благодаря наличию клиентов

А между прочим, еще…

• Качество продукта определяется удовлетворённостью клиентов

• Клиент вовлечён в процесс разработки так же как и другие участники

• Качественное тестирование возможно только зная каким образом клиенты будут использовать продукт

 


8. Различия в понятиях "тестирование", "контроль качества", "обеспечение качества".

 

Тестирование – исследование продукта и предоставление информации (дефекты, отчеты, метрики)

Контроль качества (QC, Quality Control) – Тестирование + принятие решения о выпуске продукта.

Обеспечение качества (QA, Quality Assurance) – процессный менеджмент, определяющий пути повышения качества продукта (не только в области тестирования).

 

9. Стоимость исправления дефекта на разных стадиях разработки ПО. Оценка распределения трудоемкости по стадиям.

 

Чем на более поздней стадии обнаружится ошибка, тем больше будет стоимость её исправления. Миссия тестирования – снизить стоимость разработки путем раннего обнаружения дефектов.

Широко известна оценка распределения трудоемкости между фазами создания программного продукта: 40%-20%-40% (разработка спецификаций и требований, кодирование, тестирование)

 

10. Позитивные, негативные, исследовательские тесты.

 


11. Функциональное и виды нефункционального тестирования.

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

 

 
 

 


12. Модульное, интеграционное и системное тестирование.

Модульное тестирование (юнит-тестирование) — тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

Интеграционное тестирование— тестируются интерфейсы между компонентами, подсистемами или системами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

Системное тестирование— тестируется интегрированная система на её соответствие требованиям.

 


13. Альфа- и бета-тестирование.

 

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

Бета-тестирование– использование почти готовой версии продукта группой сторонних пользователей с целью выявления максимального числа «нетипичных» дефектов для их исправления перед выходом продукта в релиз.

Бета-тестирования может использоваться как часть стратегии продвижения продукта на рынок:

• Бесплатная раздача бета-версий привлекает вниманием многих пользователей к окончательной, платной, версии.

• Сбор отзывов о продукте от широкого круга пользователей.

 

14. Регрессионное и приемочное тестирование.

 

Регрессионное тестирование (regression testing, от лат. Regressio – движение назад) – собирательное название методов тестирования, направленных на обнаружение дефектов в уже протестированных частях продукта, которые не должны изменяться.

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

Плохой дизайн и архитектура ПО – благодатная почва регрессионных дефектов.

“Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50%) влечет появление новой”.

Приемочное тестирование (acceptance testing) – выполняется на основании набора типичных сценариев использования ПО, разработанных на основе требований к данному ПО. Выполняется с целью демонстрации заказчику возможностей готового продукта. Заказчик принимает решение о принятии или отправлении на доработку продукта.

 

15. Smoke- и AdHoc-тестирование.

 

Smoke-тестирование – выполнение минимального набора тестов на явные ошибки.

Выполняется:

• Самим программистом после модификации кода. Если тест не пройдет, нет смысла отдавать продукт в глубокое тестирование

• В условиях критического недостатка времени на регрессионное тестирование при внесении небольших изменений

 







©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.