DOU voice chat «Тест-дизайн. Усе, що ви хотіли знати» (подія в архіві)

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

Як писати тестову документацію, визначати тест-кейси і що станеться, якщо забити — про це і поговоримо.

📅 26 липня о 19:00 у телеграм-каналі dou_qa поговоримо про тест-дизайн, проєктування тестів та тест-кейси.

Спікери:

🔴 Трансляція: Telegram

Охочі зможуть поставити питання під час стріму, або ж — залишити питання в коментарях. Найцікавіші — озвучимо.

P. S. Усі наші войсчати абсолютно безкоштовні, та закликаємо задонатити на бандеромобілі для Перемоги. Там ще і призи можна виграти :)

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Добрий день. В пілотному випуску подкасту DOU про QA, один з ведучих назвав тести «сміттям». Тобто іх потрібно «швидко створити, швидко змінити і швидко видалити» за його словами. Все інше не відіграє важливої ролі і виходить що тести вони одноразові. Це і є суть Agile методології, швидкість та гнучкість.

У мене питання, як зрозуміти ДЕ той БАЛАНС між написанням тестів і самим процесом тестування? Скільки часу можемо потратити на документацію, а скільки на самі тести? Це співвідношення 50/50 чи 10/90, де 10% це документація і 90% це сам процес тестування відповідно?

Підписатись на коментарі