Меню

Чим відрізняється планування тестів для проектів, що проводяться вручну та автоматизації?

how does test planning differ

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

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

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

=> Клацніть тут, щоб отримати повну серію підручників з плану тестування

Планування тестів

Хороший комікс Ділберта про планування:

планування проекту

Перш ніж ми підемо далі, я хочу встановити, про що ця стаття НЕ буде.

# 1) Це не поглиблене обговорення систем автоматизації. Різні проекти використовують різні рамки залежно від природи їх AUT, архітектури, складності, досвіду команди тощо.

Інформацію про основи можна знайти за посиланнями нижче:

Структури автоматизації тестів, частина 1 і частина 2 .

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

# 3) Це також не спеціально інструменти. Кожна діяльність у SDLC вимагає часу, зусиль, інфраструктури - іншими словами - ГРОШІ.

Для проекту ручного тестування витратними факторами є:

  • Люди
  • Інструменти - Тестування / Управління дефектами
  • Інфраструктура - довкілля
  • Час
  • Навчання

Для проекту автоматизації, крім вищезазначених статей, йому потрібні витрати на:

  • Засоби автоматизації
  • Надбудова для інтеграції інструменту управління тестами
  • Надбудова для підтримки AUT (наприклад, SAP, Oracle тощо)
  • Структура створена
  • Навчання спеціального інструменту

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

Ні.

Є одне і єдине питання, яке визначає успіх - “Чи можете ви отримати кращу рентабельність інвестицій (рентабельність інвестицій) порівняно з ручним маршрутом”? - Якщо не відразу, то врешті-решт.

Якщо відповідь на це запитання - 'НІ', ви неправильно запланували проект автоматизації.

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

план випробувань автоматизації

Розділи плану тестування автоматизації

Розділ №1:Сфера дії

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

Розділ №2: Тестова стратегія

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

Розділ №3:Ресурси / Ролі та обов'язки

  • Першим кроком у цьому напрямку є розуміння можливостей команди та передбачення випереджаючого масштабу автоматизації, що входить у картину. Це допоможе вибрати команду, яка відповідає потребам автоматизації та тестування вручну. Крім того, підбирайте людей, які мають правильне ставлення - ті, хто не вважає, що тестування вручну нижче їх статусу.
  • Виберіть команду, яка добре знає AUT, управління тестами, управління дефектами та інші заходи SDLC
  • Розділ №1: Сфера застосування

Розділ №4:Інструменти

Виберіть інструменти автоматизації на основі таких правил:

  • Чи має компанія вже ліцензії на певний інструмент, спробуйте і подивіться, чи можете ви ним користуватися
  • Шукайте інструменти з відкритим кодом (але надійні)
  • Члени команди вже знають інструмент чи нам потрібно залучити когось нового? Або навчити існуючі?

Розділ No5: Розклади

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

Розділ №6:Навколишнє середовище

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

Розділ №7:Результати

  • Ваші тестові сценарії - це ваші результати. Однак не всі володіють знаннями в галузі автоматизації / мови програмування. Отож, плануйте створити документ “Інструкції”, який допоможе поточним користувачам та майбутнім членам команди зрозуміти цей сценарій, навіть коли вас немає поруч.
  • Включіть коментарі у свій сценарій.

Розділ №8: Ризики

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

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

Тому, якщо ви пропонуєте автоматизувати систему, виберіть ту, яка є

  • Стабільне і не надто велике обслуговування
  • Має можливості для величезних номерів для регресії
  • Не має надто багато ручного втручання або не залежить від інтуїції людини

Розділ №9:Дані тесту

  • Враховуйте аспекти безпеки даних
  • Не кодуйте будь-які тестові дані у сценарії. Це просто призводить до занадто великого обслуговування сценарію та може спричинити помилки під час модифікації.
  • Будьте дуже конкретні. Для кроку тесту вручну - «введіть ім’я», ви можете сказати, введіть будь-яке ім’я з 5 символів. Під час тестування тестер може набрати “Swati” або “Seela” або що-небудь інше. Але щодо інструменту він не може робити таких припущень. Тому вкажіть точні значення.

Розділ №10:Звіти / Результати

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

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

як представити графік в Java - -

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

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

Цей допис написаний членом колективу авторів STH Свати Сіелою.

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

=> Завітайте сюди, щоб отримати повну серію навчальних програм з плану випробувань

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

^