Меню

Дослідницьке тестування проти сценарію: Хто перемагає?

exploratory testing vs scripted testing

Спробуйте Наш Інструмент Для Усунення Проблем

Реальні переваги дослідницьких випробувань:

Традиційно тестування програмного забезпечення було дуже жорсткою діяльністю, але в останні роки відбувся зсув від тестування на основі сценаріїв. Пошукові випробування , який є більш керованим контекстом, вийшов на перший план. Це тому, що це дає тестувальникам більше свободи використовувати свої вміння та знання, а також робить їх відповідальними за оптимізацію вартості власної роботи.

Дослідницьке тестування проти сценарію

Не всі продаються на вартість дослідницьких випробувань. Помітна відсутність офіційності та наголос на особистій відповідальності може спричинити дзвінок тривожних дзвонів. Але це занепокоєння значною мірою базується на неправильному тлумаченні дослідницьких випробувань. Справа не в тому, щоб викидати правила з вікна та тестувати навмання, це насправді дуже структуровано та систематично. І це також дуже ефективно.

Скептики хочуть конкретних доказів того, що це робить більше, ніж покращує моральний стан тестувальника. Ось чому ми вирішили провести дослідження, яке б порівняло дослідницьке тестування на основі контексту безпосередньо з підходом тестування на основі сценарію. Результати були дуже цікавими, як ви збираєтесь це дізнатись.

Що ви дізнаєтесь:

Запитання та відповіді на інтерв’ю j2ee для старших розробників

Групи на основі контексту (дослідницьке тестування) проти сценарій

Дві команди, два підходи:

Ми почали з того, що розділили тестувальників на дві команди по три. Тестери в кожній команді мали однакові порівнянні знання в галузі застосування. Ті самі визначення для тяжкість дефекту (мажор, мінор) були встановлені для обох команд. Обидві команди отримували однакову збірку додатків. Одна команда («за сценарієм») застосовуватиме традиційний підхід до тестування на основі сценарію, а інша команда («дослідницька») застосовуватиме підхід до тестування на основі контексту. Діяльність тестування буде розділена на два етапи по три дні кожен.

Команда за сценаріями визначив п’ять бізнес-процесів для тестування та сформував 15 тестових кейсів. Тестові випадки були обмеженими, тому тестувальники не мали жодної свободи досліджувати за межами сценарію.

Пошукова група створив два візуальні карти розуму , одна, яка визначила охоплення випробувань та статути випробувань, а інша - компоненти / модулі продукту. В результаті цього процесу було створено 24 тестові статути. Визначені статути мали високий рівень і дозволяли інтерпретувати контекст, розширюючи обсяг тестової сесії для тестувальників.

Фаза 1:

Команді за сценарієм вдалося виконати 6 тестових справ за відведені три дні. У той час вони повідомили про 6 основних дефектів.

Дослідницькій групі вдалося пройти 13 тестових сесій, що тривали від 30 хвилин до 180 хвилин кожна. Вони повідомили про 10 основних дефектів та 5 незначних дефектів.

сценарій проти дослідницького тестування 1

Цікаво, що дослідницька група повідомила про всі дефекти, про які повідомила сценаристська команда.

Фаза 2:

Сценарій команді вдалося виконати 9 тестових кейсів цього разу. Вони повідомили 10 основних дефектів і 8 незначних дефектів .

Дослідницька група пройшла 18 сеансів. Вони повідомили 14 основних дефектів і 5 незначних дефектів.

сценарій проти дослідницького тестування 2

На фазі 2 команда сценарію повідомила про 2 основні та 1 незначний дефект, які дослідницька група не знайшла, але дослідницька група повідомила про 3 основні та 1 незначний дефект, про які сценарийна команда не повідомила.

Це не враховує відносної складності робочих процесів, які, можливо, були обрані тестерами в рамках цих сесій та тестових випадків, але ми все одно можемо зробити кілька цікавих висновків.

Що це означає?

Здається, дослідницький підхід та породжена ним відповідальність та гнучкість призводять до більш ефективної форми тестування. Можливо, ви зможете охопити більше грунту, розробляючи та адаптуючи свої тестові статути в міру проходження тестових сесій, виходячи з того, що має сенс у контексті. Цій свободі не вистачає тестування на основі сценарію, і це може запобігти виявленню дефектів.

інструменти для постійного розгортання в devops

Жорстке дотримання сценаріїв створює зношені шляхи, і лише шляхом відхилення від цих шляхів ми виявимо всі дефекти. Як кілька разів згадували лідери думок в рамках спільноти випробувачів, “Якщо ви уявляєте товар як поле наземних мін, і кожна міна є дефектом, то цілком очевидно, що повторювати один і той самий шлях знову і знову - не спосіб їх знайти усі '.

Зрештою, жоден з підходів не був ідеальним, оскільки кожна команда повідомляла про дефекти, які інша команда не виявила, навіть якщо дослідницька група в цілому повідомила про більше.

Реально це може означати, що правильний підхід, що стосується максимально наближення до «мінімальних» дефектів, буде сумішшю двох. Але, є багато переваг з контекстний підхід які говорять на його користь. Це вимагає менше часу на підготовку, менше документації, ідентифікує проблеми раніше та вимагає від тестувальників використання аналітичних навичок та дедуктивних міркувань. Вони отримують більш глибоке та глибоке розуміння продукту і дійсно виступають захисниками кінцевого споживача.

Висновок

Кінцевий результат демонструє, що пошукові випробування призводять до повідомлення про більшу кількість дефектів перед запуском, що призводить до кращої доставки продукції командою, і, зрештою, більш задоволені / виконані тестери які є бажаними результатами, як би ви на це не дивились.

Про автора

Муш Хонда - директор з контролю якості в Технологія KMS , постачальник ІТ-послуг протягом життєвого циклу розробки програмного забезпечення з офісами в Атланті, штат Джорджія, та Хошиміні, В’єтнам. Раніше він був випробувачем в Ernst & Young, Nexidia, Colibrium Partners і Connection. Послуги KMS включають управління додатками, тестування, підтримку, професійні послуги та збільшення персоналу.

Ви згодні? Не соромтеся розміщувати свої коментарі, запитання нижче.

НАЗАД Підручник | НАСТУПНИЙ підручник No4: Дослідницьке тестування за допомогою HP Sprinter

Рекомендована література

^