Меню

Як підготуватися до написання тестових кейсів (Поради щодо продуктивності)

how prepare yourself

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

Як підготуватися до написання тестових кейсів та покращити свою продуктивність:

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

По-перше, їм потрібно професійно та психологічно підготуватися до деяких ключових моментів, необхідних кожному успішному тестувальнику програмного забезпечення в ІТ-галузі. Це буде трактуватися як “ Вхідні дані ”Для тестера перед тим, як почати писати тестові кейси.

написання тестового кейсу

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

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

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

DVD для копіювання та запису програмного забезпечення безкоштовно

Підготовка до написання тестових кейсів

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

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

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

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

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

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

6) Вимоги до проекту та типи випробувань, які потрібно виконати, різняться залежно від проекту. Тестер повинен бути підготовлений для проведення будь-якого виду тестування. Не обмежуйте свої можливості до ваших навичок та спеціальностей. Будьте готові взяти на себе відповідальність та виклики для написання та виконання тестових кейсів для будь-якого типу тестування.

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

7) Визначте типи тестування і навички, необхідні для тестування AUT. Наприклад, деякі проекти вимагають лише тестування чорної скриньки, а деякі - навичок тестування білої скриньки. Знання “ сценарії 'Або досвід у' SQL ”Або робота з“ розмітити мову ”, Як-от HTML / XML тощо, або навіть системні знання про те, як встановити / усунути неполадки при встановленні програмного забезпечення тощо, - це деякі конкретні вимоги до проекту, які ви повинні вивчити самостійно або пройти навчання для того самого.

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

Ефективність тестового кейсу 2

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

9) Огляд тестового випадку : Однією з найважливіших та найневигідніших фаз будь-якої розробки програмного забезпечення та життєвого циклу тестування є ' ОГЛЯД '. Коли план проекту включає достатньо часу для розподілу процес перегляду на кожному етапі розробки проекту, найбільш якісні результати та результати ми можемо очікувати однакові.

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

Документи тестування слід переглядати принаймні 3 рази через:

i) Самоогляд
ii) Експертна перевірка
iii) Перевірка іншими на предмет повноти, охоплення тестуванням, відстежуваності та тестування тестового випадку чи ні.

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

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

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

Показники якості

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

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

Також дивінші корисні показники тесту, що використовуються на етапах тестування:

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

1) Середня ефективність тестування

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

2) Середня щільність дефектів споживача

  • Помилки, про які повідомляє клієнт після доставки, проти загальних зусиль на тестування за людино-місяці.
  • Обчислюється як Середнє (загальна кількість помилок після доставки / випробування в людських місяцях).
  • Розраховується після зовнішнього випуску та завершення проекту.
  • Межа прийому: повинна бути менше 1

3) Функціональні невдалі тести

  • Кількість невдалих функціональних тестів / Загальна кількість виконаних функціональних тестів.
  • Розраховується щомісяця або раз на два тижні.

4) Помилки з рівнем важкості 1

youtube у mp3 довше 30 хвилин
  • Загальна кількість помилок, виявлених за рівнем серйозності 1 (блокатор).
  • Неможливо продовжити тестування програмного забезпечення через проблеми з блокуванням.
  • Розраховується щотижня.

5) Помилки з рівнем серйозності 2

  • Загальна кількість помилок, виявлених за рівнем серйозності 2 (основні помилки).
  • Тестування не можна продовжувати для функції через основні помилки, але можна продовжити з іншими частинами системи.
  • Розраховується щотижня.

6) Помилки з рівнем важкості 3

  • Загальна кількість помилок, виявлених за рівнем серйозності 3 (незначні помилки).
  • Тестування можна продовжувати, оскільки виявлена ​​помилка незначна і не зупиняє тестування.
  • Розраховується щотижня.

7) Помилки з рівнем серйозності 4

  • Загальна кількість помилок, виявлених за ступенем тяжкості 4 (косметичні проблеми).
  • Тестування можна завершити без будь-яких проблем, оскільки виявлені помилки пов’язані з косметикою та мають бути виправлені для наступного випуску.
  • Розраховується щотижня.

Повідомлення про помилки

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

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

Щоб детально вивчити процес повідомлення про помилкипрочитайте наступні статті:

=> Як написати хороший звіт про помилку? Поради та підказки
=> Зразок звіту про помилку
=> Чому звітування про помилки - це мистецтво, якому повинен навчитися кожен тестувальник?
=> Життєвий цикл помилок
=> Приклади звітів про помилки веб-програм та програм для продуктів

Звіти про випробування

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

Нижче наведено один такий простий звіт про тестування:

Також прочитайте наступні корисні підручники дляефективна звітність про тести:

=> Посібник із написання ефективного звітного тесту
=> Як розумно повідомити про виконання тесту (Завантажити шаблон звіту про стан)

Запити sql практикують питання з відповідями

переможний

jaya1

Висновок

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

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

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

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

Рекомендована література = >> Найкращі онлайн-курси творчого письма

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

НАЗАД Підручник | НАСТУПНИЙ підручник

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

^