Хто повинен написати план тесту?

Я перебуваю у власній команді з розвитку моєї компанії, і ми розробляємо веб-сайти нашої компанії відповідно до вимог маркетингової команди. Перш ніж випустити сайт для проходження тестування, ми попросили надати їм план тестування, який вони повинні виконувати.

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

1. Натисніть на кнопку A .
2. Ключ в XYZ в кнопку поля форми і натисніть кнопку B .
3. Ви повинні побачити поведінку C .

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

Ми рухаємось до використання Agile підходу для управління нашими проектами, і це також вимагається в кінці кожної ітерації.

Окрім тестування підрозділів та інтеграції, хто повинен створити план тестування кінцевого користувача? Це повинні бути квестори чи розробники?

Заздалегідь дякую.

З повагою
CK

План тесту НЕ слід писати розробниками. Частина того, що потрібно зробити тестовим планом, - це перевірити, чи правильно інтерпретував розробник вимогу. Розробник не може ефективно написати план тестування для коду, який він збирається написати. Плани тестування повинні писати люди, які збираються робити QA, або бізнес-аналітики. Якщо розробники повинні писати плани, ніколи не привласнюйте когось написати план для тієї частини програми, яку він збирається написати.

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

Команда з контролю якості повинна написати та виконати план тестування.

В ідеалі план тесту повинен бути написаний паралельно з функціональною специфікацією - дивно, як думка про те, як перевірити функціональність, концентрує розум і покращує технічні характеристики.

Відповідь Scrum: Якщо ви хочете визначити "Визначення закінченого", ви помітите, що тестовий план швидко стає одним із пунктів. Як ще можна описати історію, яку потрібно зробити, якщо вона не була перевірена.

Хто несе відповідальність за створення плану тесту? Команда

Хто така команда? Будь-яка особа, яка зобов'язана реалізувати продукт, повинна бути членом Команди.

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

Я вважаю, що плани функціональних тестів повинні бути написані функціональними / бізнес-аналітиками. Вони пишуть функціональний аналіз (навіть якщо ви працюєте спритно, я припускаю, що у вас є аналіз), і тому вони повинні бути записати, які шляхи в додатку слід дотримуватися для тестових цілей.

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

Ось ідея, яка може зробити щасливі обидві групи та добре поєднуватись із рухом у напрямку Agile:

Автоматизуйте ваші користувальницькі чеки прийому та екранізуйте їх.

http://pragprog.com/magazines/2009-12/automating-screencasts

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

Він також забезпечує спосіб власне виконання вимог - чи натрапили ви на виконавчі технічні характеристики Гойко Аджича? Погляньте тут: http://gojko.net/2010/08/04/lets-change-the-tune/ Якщо ви думаєте про це як про спосіб перевести вимоги у виконувану форму, щоб демонструвати своїм клієнтам. , то це раптом здається набагато менш безглуздим.

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

1) Ось наша нова реєстраційна форма - дивіться цю скріншот, щоб побачити, як вона працює!

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

Тобто ви представляєте приємний показ екрана, а потім просите зворотного зв'язку, обрамляючи його, не надто конкретно, змушуйте їх думати про потенційні проблеми, а не просто підтверджувати. Отримати їх мислення , замість того , щоб просто натиснувши наосліп через план тестування. Ви в основному пишете статут дослідницького тесту для них. (Якщо ви подивитеся на квадрати тестування Agile , це були б тести в Квадранті 3).

Візьміть для прикладу ремонт будинку. Чи приймете ви контрольний список, складений вашим підрядником з проханням перевірити, що він зробив для вас? Або ви придумаєте свій власний контрольний список і перевірте, чи підрядник зробив те, що Ви вказали?

Відповідь ясна: запитувач повинен перевірити, чи те, що він / вона вимагав, робиться відповідно до специфікацій. Він / вона має вийти зі своїм власним контрольним списком і протестувати додаток. проти цього списку.

Однак розробник повинен мати власний контрольний список і забезпечити правильне внутрішнє тестування та видалення помилок перед обробкою програми. більше для UAT. В ідеалі розробник повинен автоматизувати більшість цих тестів у вигляді тестових сценаріїв. Пам'ятаєте TDD? В ідеалі тестові сценарії (у цьому випадку одиничні тестові випадки) повинні бути написані для тестування компонентів програм. Потім слід написати тестовий набір для об'єднання цих тестових випадків для проведення інтегрованих та регресійних тестів.

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