Як підготуватися до написання тестових кейсів [Поради щодо продуктивності]
Як підготуватися до написання тестових кейсів та покращити свою продуктивність:
Коли тестер вирішує писати високоякісні тестові кейси і хоче покращити свою ефективність та продуктивність написання тестових кейсів, є декілька ключових моментів, які допомагають тестерам досягти цих цілей.
По-перше, їм потрібно професійно та психологічно підготуватися до деяких ключових моментів, необхідних кожному успішному тестувальнику програмного забезпечення в ІТ-галузі. Це буде трактуватися як “ Вхідні дані ”Для тестера перед тим, як почати писати тестові кейси.
Далі вони повинні зрозуміти показники якості, залучені до проекту, який використовується як інструмент для оцінки ефективності тестувальника на різних фазах життєвого циклу тестування. Це буде трактуватися як “ Виходи ”Для тестера після завершення написання тестового кейсу .
Нарешті, тестувальник повинен знати, як повідомляється про помилку, ескалація питань та як підготовка звітів про тестування відповідає стандартній процедурі та може бути зрозумілою для зацікавлених сторін проекту.
Що ви дізнаєтесь:
· Підготовка до написання тестових кейсів
· Показники якості
· Повідомлення про помилки
· Звіти про випробування
· Висновок
· Рекомендована література
Підготовка до написання тестових кейсів
1) Написання тестових кейсів - це мистецтво, і це не просто робота чи завдання. Шматок або сегмент програмного забезпечення може бути розроблений і розроблений, але до тих пір, поки він не буде повністю протестований для всіх сценаріїв з ефективним тестовим підходом, він буде марним і не матиме права на випуск і використання будь-ким. Тому, розгляньте себе як важливу особу в проекті, а свою тестову діяльність - як важливе завдання в проекті.
2) пристрасть з позитивним ставленням , що є гранично особистим які повинні мати тестери якості протягом життєвого циклу проекту. Пристрасть мотивує можливості командоутворення, а ставлення приносить велику продуктивність у написанні якісних тестових кейсів. Означає, тестова діяльність - це поєднання професійних та особистих якостей для спільної мети досягнення великих результатів як кінцевого результату в проекті.
3) Позитивні і негативні тести є частиною написання тестових кейсів, але тестери повинні мати напівпозитив мислення, щоб розбити тестоване додаток через пошук помилок . Це не негативне мислення, а уникнення ситуації виявлення помилки кимось після випуску або уникнення ситуації, коли система буде зламана деякими користувачами системи.
4) Ефективність тестера слід оцінювати не на основі кількості помилок, виявлених у тестовій системі, а на основі можливостей написання успішних тестових випадків, результатом яких є виявлення дефектів. Отже, тестові кейси повинні бути написані таким чином, щоб охоплення та простежуваність має бути максимальним на основі системних меж та обсягу.
5) Докладно зрозумійте домен програми .Наприклад, тестування веб-сайту простіше, ніж тестування фінансового програмного забезпечення, розробленого для фондової біржі, яке одночасно використовується тисячами людей. Проста функціональність веб-сайту може бути зрозумілою будь-якому тестувальнику, тоді як фінансові умови та функціональні можливості не можуть бути зрозумілими всім тестувальникам до тих пір, поки вони не матимуть відповідного рівня освіти або підготовки або досвід домену .
Отже, коли тестувальник призначається за новим проектом, він / вона повинен зробити самооцінку, чи мають вони право та можуть виконувати свою роботу відповідно до очікувань чи ні. Якщо функціональні вимоги важко зрозуміти, їх слід донести до команди проекту заздалегідь, щоб уникнути помилок у майбутньому щодо ефективності та продуктивності тестувальника. Цим керуватиме керівник проекту або керівник тестування у відповідних планах та навчанні.
6) Вимоги до проекту та типи випробувань, які потрібно виконати, різняться залежно від проекту. Тестер повинен бути підготовлений для проведення будь-якого виду тестування. Не обмежуйте свої можливості до ваших навичок та спеціальностей. Будьте готові взяти на себе відповідальність та виклики для написання та виконання тестових кейсів для будь-якого типу тестування.
Багато тестувальників намагаються пристосувати себе або спроектувати себе як лише тестери, що працюють вручну або для автоматизації. Коли приходять на тестування продуктивності, тестування на навантаження або стрес-тестування, дуже мало тестерів беруть на себе роль і готуються до навчання або збору необхідних знань. Тому, швидко вчитися і будьте готові брати на себе відповідальність і рости у своїй кар’єрі.
7) Визначте типи тестування і навички, необхідні для тестування AUT. Наприклад, деякі проекти вимагають лише тестування чорної скриньки, а деякі - навичок тестування білої скриньки. Знання “ сценарії 'Або досвід у' SQL ”Або робота з“ розмітити мову ”, Як-от HTML / XML тощо, або навіть системні знання про те, як встановити / усунути неполадки при встановленні програмного забезпечення тощо, - це деякі конкретні вимоги до проекту, які ви повинні вивчити самостійно або пройти навчання для того самого.
8) Переконайтеся, що тестові кейси охоплюють Типи тестування продуктивності, тестування безпеки та регресії. Наприклад, щоб увійти до програми за допомогою екрана входу нижче:
Тестування продуктивності може знадобитися, щоб перевірити, чи є програма стабільною, коли одночасно до системи входять 1000 користувачів, і тестові випадки повинні бути написані для охоплення цього сценарію.
Тестування безпеки може знадобитися, щоб перевірити, чи дозволяє програма лише тим користувачам, які мають належні права та дозволи, бути уповноваженими на використання системи, а тестові випадки слід писати для охоплення цих сценаріїв.
Можливо, знадобиться регресійне тестування, щоб перевірити, чи правильно працюють основні функціональні можливості та критичні функції у кожному випуску.
9) Огляд тестового випадку : Однією з найважливіших та найневигідніших фаз будь-якої розробки програмного забезпечення та життєвого циклу тестування є ' ОГЛЯД '. Коли план проекту включає достатньо часу для розподілу процес перегляду на кожному етапі розробки проекту, найбільш якісні результати та результати ми можемо очікувати однакові.
Наприклад, перед тим, як починати писати тестові кейси, тестувальники повинні перевірити, чи переглядається документ «специфікація вимог» і чи враховуються та оновлюються всі документи в документі. Якщо організація дотримується належного та зрілого процесу, усі шаблони документів повинні містити інформацію про цю зміну на першій сторінці самого документа.
Документи тестування слід переглядати принаймні 3 рази через:
i) Самоогляд ii) Експертна перевірка iii) Перевірка іншими на предмет повноти, охоплення тестуванням, відстежуваності та тестування тестового випадку чи ні.
10) Нарешті, зрозуміти, як оцінювати і спланувати завдання тестування . Плануйте працювати лише за запланованим розрахунковим часом протягом доби. Цього можна досягти, якщо вчасно розпочати і виконати завдання та залишити день, склавши плани на наступний день.
Уникайте затримуватися пізно ввечері та проводити вихідні в офісі. У наш час доступні ефективні підходи до управління проектами, і проекти виконуються в гнучкому середовищі. Якщо проектні групи не досягнуть етапів, це буде трактуватися як неефективне управління проектами, а не як неефективність проектних команд.
Примітка : Майте на увазі, навіть для автоматизоване тестування , тестові кейси повинні бути чітко написані та переглянуті принаймні один раз, повністю охоплюючи функціональний потік тестованої програми. Будь-який інструмент автоматизації тестування може успішно реєструвати та виконувати тестові кейси лише тоді, коли ручні тестові кейси чітко визначені та написані.
Показники якості
Це важлива діяльність на етапах тестування програмного забезпечення. Команда тестування повинна бути повністю обізнаною з різними показниками тестування, які використовуються для досягнення мети проекту. Ефективність тестувальника оцінюється не лише на етапі виконання тесту, а на основі всіх показників тесту, зібраних в результаті аналізу вимог, написання тестових випадків, виконання, звітності про дефекти та, нарешті, фази звітності про тестування.
Нижче наведено кілька важливих показників тесту слідують більшість організацій для підвищення продуктивності тестувальників та ефективності фаз тестування.
Також дивінші корисні показники тесту, що використовуються на етапах тестування:
=> Важливі показники та вимірювання тестування програмного забезпечення та Відстеження помилок проекту в реальному часі, тестові показники та процес виходу з тесту.
1) Середня ефективність тестування
Помилки за людино-місяці випробувань.
Обчислюється як середнє (загальна кількість помилок під час тестування в людських місяцях).
Розраховується після кожного внутрішнього випуску, а також після завершення тесту.
Межа прийому: повинна бути менше 50
2) Середня щільність дефектів споживача
Помилки, про які повідомляє клієнт після доставки, проти загальних зусиль на тестування за людино-місяці.
Обчислюється як Середнє (загальна кількість помилок після доставки / випробування в людських місяцях).
Розраховується після зовнішнього випуску та завершення проекту.
Межа прийому: повинна бути менше 1
3) Функціональні невдалі тести
Кількість невдалих функціональних тестів / Загальна кількість виконаних функціональних тестів.
Розраховується щомісяця або раз на два тижні.
4) Помилки з рівнем важкості 1
Загальна кількість помилок, виявлених за рівнем серйозності 1 (блокатор).
Неможливо продовжити тестування програмного забезпечення через проблеми з блокуванням.
Розраховується щотижня.
5) Помилки з рівнем серйозності 2
Загальна кількість помилок, виявлених за рівнем серйозності 2 (основні помилки).
Тестування не можна продовжувати для функції через основні помилки, але можна продовжити з іншими частинами системи.
Розраховується щотижня.
6) Помилки з рівнем важкості 3
Загальна кількість помилок, виявлених за рівнем серйозності 3 (незначні помилки).
Тестування можна продовжувати, оскільки виявлена помилка незначна і не зупиняє тестування.
Розраховується щотижня.
7) Помилки з рівнем серйозності 4
Загальна кількість помилок, виявлених за ступенем тяжкості 4 (косметичні проблеми).
Тестування можна завершити без будь-яких проблем, оскільки виявлені помилки пов’язані з косметикою та мають бути виправлені для наступного випуску.
Розраховується щотижня.
Повідомлення про помилки
Механізм повідомлення про помилки слід контролювати за допомогою визрілого тестового процесу, щоб підтримувати якість програми. Повинен бути належний процес ескалації, щоб уповноважені особи знали статус, серйозність та пріоритет помилки. Існує доступно багато безкоштовних та комерційних інструментів звітності про помилки як Bugzilla, Mantis тощо, які є дуже ефективними в механізмі відстеження проблем і можуть бути легко інтегровані з будь-яким інструментом управління тестами, що використовується в проекті.
У кожному проекті тестування необхідно щодня дотримуватися стандартних процедур для онлайн-механізму звітування про стан. Кожна помилка / проблема, що реєструється та повідомляється в цих системах відстеження помилок, повинна негайно надсилати електронний лист відповідним органам влади, який допоможе їм спланувати та вжити відповідних дій.
Щоб детально вивчити процес повідомлення про помилкипрочитайте наступні статті:
=> Як написати хороший звіт про помилку? Поради та підказки => Зразок звіту про помилку => Чому звітування про помилки - це мистецтво, якому повинен навчитися кожен тестувальник? => Життєвий цикл помилок => Приклади звітів про помилки веб-програм та програм для продуктів
Last updated