Життєвий цикл дефектів - Як ви вже можете знати, виконання тесту - це фаза, коли тестер насправді виконує тестові сценарії. Процес виконання тестових сценаріїв відрізняється від компанії до компанії і може бути різним у різних проектах в межах однієї компанії.
Зараз уже кілька днів доступні інструменти для виконання тестових інструментів, такі як Центр якості, візуальна студія Microsoft тощо. Фактичний процес виконання кожного кроку для порівняння фактичного та очікуваного результату залишається однаковим для функціонального тестера незалежно від використовуваних інструментів.
- Що робити, якщо фактична поведінка не дорівнює очікуваній поведінці?
Коли тестер виявить, що фактичний результат тестування не дорівнює очікуваному результату, реєструється дефект.
- Як записати дефект?
Зараз існує багато інструментів, доступних за добу, деякі інструменти реєстрації дефектів - ClearQuest від IBM, Центр якості HP, інструменти з відкритим кодом, такі як життєвий цикл дефектів у JIRA тощо.
Є деякі обов'язкові поля, які є загальними для різних інструментів реєстрації дефектів, ці поля -
- Опис життєвого циклу дефекту
- Життєвий цикл дефектів Підсумок
- Дефект, зареєстрований користувачем
- Дефект призначений
- Дефект серйозності
- Пріоритет дефекту
- Додаткові знімки
- Номер випуску / ім'я
Життєвий цикл дефектів
Життєвий цикл Defect починається з реєстрації нового дефекту. Щоразу, коли дефект реєструється, він переходить у стан «Новий».
Тестер - новий дефект
Кому призначити новий дефект?
Тестер може призначити дефект розробнику або потенційному клієнту. Це рішення про призначення дефектів варіюється від проекту до проекту. На деяких робочих місцях відбувається процес життєвого циклу дефектів, щоб призначити його безпосередньо відповідному розробнику, а в деяких місцях дефект спочатку присвоюється відвіднику розробки, а відвідник dev в свою чергу призначає його розробнику.
Призначення дефектів (нове) - розробник дефектного життєвого циклу
Призначення дефекту (нове) - розробник Dev Leadà
Аналіз дефектів
Розробник проаналізує дефект, щоб перевірити, чи він відтворюється. Тут найважливіший внесок тестера - включити всі необхідні деталі в дефект. Підсумок дефектів, детальний опис дефекту - це поля, які допомагають зацікавленим сторонам зрозуміти дефект за один раз. Підсумок дефектів завжди повинен мати лише інформацію про дефект високого рівня. При цьому вона повинна мати достатню інформацію для опису огляду дефекту в одному рядку.
Опис дефекту - це місце, де тестер повинен містити всю необхідну інформацію, як оточення, сценарій, використовувані дані тестування, очікуваний результат, фактичний результат, посилання на файли / дані та посилання на знімок.
Ось короткий огляд різних елементів детального опису дефекту -
Середовище
Тестова середовище, де був виявлений дефект. Часто проекти мають кілька тестових середовищ, де тестова група проводить тестування. Наприклад - AT (середовище тестування для складання), PT (середовище тестування продукту), UAT (середовище тестування прийняття користувачем) тощо. Мета різних середовищ полягає в тому, щоб вона забезпечила гнучкість у команді розробки та тестування, щоб код розгорнувся в будь-якому доступному середовищі, щоб вчасно почати тестування.
Бувають випадки, коли Тест продукту (також його називають тестом системи) та тестування UAT перекривається, отже, наявність декількох середовищ є обов'язковим для продовження тестування паралельно.
Бувають випадки, коли команді розробників потрібне додаткове середовище для налагодження проблем, про які повідомляє тестувальна група. Також команда розробників має спеціальне середовище для завдання блочного тестування.
Отже, з кількома середовищами, у дефекті потрібно згадати конкретне середовище, де було виявлено проблему.
Сценарій
Сценарій - це набір кроків, які виконує тестер, що призвело до дефекту. Тут очікується, що тестер згадає всі кроки, які може виконати розробник для відтворення дефекту. Часто бувають випадки, коли тестер повідомляє про дефект, але розробник не в змозі повторити те саме, і, отже, дефект буде відхилено. Це може статися через неправильні кроки / відсутні кроки, зазначені в описі. Чіткі кроки допомагають усім зрозуміти дефект та повторити його, не маючи залежності звертатися до тестера, щоб отримати вхідні дані. Добре задокументований сценарій має легкий для читання, легкий для розуміння та чіткі кроки, які слід дотримуватися, щоб повторити дефект.
Дані тесту
Тестувальник повинен згадувати дані, які використовувались під час тестування, що призвело до проблеми. Ця інформація дає можливість розробникові використовувати подібні дані для відтворення дефекту та пошуку першопричини для того ж.
Існують деякі сценарії, в яких тестер виявляє дефект, використовуючи певні дані, але та сама проблема не піддається повторенню, використовуючи дані подібного типу. Це може статися через пошкодження даних, тому введення даних дає можливість з'ясувати першопричину дефекту. Розробник може не переходити до рівня коду, якщо трапляється пошкодження даних. Цей вид дефекту може бути перетворений в дефект даних.
Очікуваний та фактичний результат
Це важливе поле детального опису, де тестер доводить, що помилка справді є дефектом. Чітке згадування очікуваного результату дає зрозуміти, що кожен власник акцій повинен вважати помилку дефектом. Уявіть, що дефект записується з усіма деталями, але він не визначає очікуваний результат сценарію!
Зазвичай тестер вводить лише очікуваний результат, може бути в рядку або дві, проте дуже важливо згадати джерело очікуваного результату. Джерело тут посилання на документ, де згадується очікуваний результат. Це може бути документ про вимогу або посилання на дошку розкадрування.
Посилання на файли / дані
Іноді дефект передбачає генерацію файлу або введення у вигляді файлу. У подібних сценаріях тестер повинен надавати інформацію про файл, який використовувався, і це спричинило проблему в застосуванні. Ці файли можна приєднати за допомогою інструменту управління дефектами або надати посилання на них. Ці довідкові місця повинні бути доступними всіма зацікавленими сторонами.
Посилання на знімок
Знімки відіграють дуже важливу роль, коли ви хочете показати їм точне повідомлення про помилку розриву сторінки, яке відображається на екрані або коли ви хочете показати деталі навігації по екрану. Знімок дає швидке уявлення про виниклий дефект, екран, на якому виявлений дефект, дані, що використовуються на екрані тощо. Кожен інструмент управління дефектами має можливість додавати знімки. Іноді тестер може також додавати таблиці Excel або текстові документи Excel.
Це різні компоненти реєстрації дефектів та найкращі практики для кожного з них. Повертаючись до життєвого циклу дефектів, як тільки дефект буде призначений розробнику, він / вона аналізуватиме його, використовуючи дані, надані в пункті дефекту. Якщо відповідно до аналізу, записана проблема справді є дефектом, розробник буде "відкрити" дефект для роботи над його виправленням.
Рекомендовані курси
- Веб-сервіси в навчальному пакеті Java
- Тренінг з розробки ігор в C ++
- Повне навчання з етичного злому
- Вегас Про 13 навчальних курсів
Нове - Відкрите
Дефект у відкритому статусі показує, що він знаходиться у розробці та розробники працюють над його виправленням. Якщо аналіз виявить, що зареєстрована проблема не є дефектом, це може статися, коли є розбіжність у розумінні очікуваної поведінки системи. Якщо аналіз говорить про те, що дефект недійсний, розробник відкине дефект. Термінологія "Відхилено" або "Повернення до тестування".
Нове - повернення до тестування.
Як слід перевірити тестер, якщо дефект справді був недійсним дефектом?
Це сценарій, коли точний документ з вимогами допомагає всім в команді дійти висновку, якщо дефект, зареєстрований як недійсний, чи дійсний. Посилання на документи з вимогами допомагає як тестерові, так і розробнику дійти одного і того ж висновку, і це дійсно полегшує процес обговорення.
Існують сценарії, коли правильність оформлення та вимоги документів піддаються сумніву при посиланні цих документів під час обговорень дефектів; у такі періоди повернення до Business Analyst вважається найкращим варіантом для уточнення запитів.
Як найкраща практика, вимоги та проектні документи завжди повинні бути актуальними для того, щоб посилатися на них без будь-яких двозначностей.
У статусі «Відкрито» команда розробників працює над виправленням дефекту, як тільки дефект буде виправлений, стан змінюється на «Готовий до розгортання».
Відкрито - готово до розгортання
Розгортання - це процес, коли зміни завантажуються на сервер, щоб команда тестування могла працювати над фіксованою версією коду. Зазвичай для кожного проекту є окрема група розгортання для цього завдання.
Тож на високому рівні команда програмного забезпечення в основному складається з цих 3 груп -
- Розвиток
- Дефект життєвого циклу при тестуванні
- Розгортання (або іноді його називають командою Build)
Після того, як збірка буде розгорнута і дефект знову буде доступний для повторного тестування, вона призначається відповідному тестеру для завдання повторного тестування.
Дефект призначений для тестування.
Провідний тест - індивідуальний тестер.
Призначений дефект - індивідуальний тестер.
На деяких робочих місцях дефект спочатку присвоюється випробувальному свинцю, і він, в свою чергу, призначає його індивідуальному тестувальнику, проте в деяких місцях дефект безпосередньо призначається тестувальнику, який би його перевіряв, або тому, хто виявив дефект.
Статус тут змінюється від Ready to Deployment - Ready SIT Testing.
Тепер дефект знаходиться в тарілці тестера. Команда тестування перевірить дефект, і є дві можливості: або виправлення запрацювало б правильно, або те ж саме виникне знову. Залежно від результату дефект може перейти до наступних статусів -
Готове тестування SIT - закрите
Готове тестування SIT - повторно відкрити
В обох вищезазначених сценаріях тестувальник повинен додати коментарі проведених тестувань. Це включає згадування перевірених сценаріїв та використаних даних. Якщо дефект буде знову відкрито, тестер повинен надати точні кроки, які виконуються, що знову призвело до помилки.
Стан повторного відкриття такий же, як і статус «Новий» дефект.
Після того, як дефект буде знову відкрито, він повториться за тим самим циклом.
Виклики життєвого циклу дефектів
- Вирішення ступеня важкості дефекту - це одна із поширених тем обговорення (часто бореться) серед розробників тестерів в / с.
- Дефект не відтворюється в системі розробника.
- Дефект, піднятий за сценарієм, який не зазначений у вимогах та проектних документах.
- Дефект знайдений, але такого ж неможливо підняти, оскільки виникнення сценарію щодо виробничого середовища неможливо.
Як тестер повинен долати вищезазначені проблеми?
- Тяжкість прямо пропорційна впливу, який дефект наносить застосуванню, якщо тестер не може продовжувати роботу через дефект, він, безумовно, відзначається з найбільшою суворістю.
- Якщо існує рішення для продовження тестування, його слід позначити як середню ступінь тяжкості. Крім того, враховуючи вплив подальших випробувань життєвого циклу дефектів, серйозність також може бути вирішена, враховуючи ситуацію, коли весь модуль виходить з ладу, в цьому випадку, навіть незважаючи на тестування іншого модуля, але суворість для поточного модуля висока тому дефект слід позначати з найвищою вираженістю.
- Якщо дефект не відтворюється в системі розробника, є ймовірність, що середовище розробки та тестування не синхронізується. Дефект, який можна відтворити на тестувальній системі, завжди вважається дійсним дефектом.
- Бувають ситуації, коли дефект реєструється з урахуванням загального сценарію бізнесу, але прямий сценарій не зазначений у вимогах чи проектному документі. Завжди вважається найкращою практикою враховувати фактичні бізнес-сценарії, а не просто виконувати кроки тестування. Спілкування з бізнес-аналітиками та іншими зацікавленими сторонами в продуктах відіграє важливу роль для фіксації таких дефектів.
- Існують сценарії, коли тестер виявляє розрив у бізнес-логіці на етапі тестування. Знаходження таких прогалин знову вважається великим плюсом для тестера. Прогалини в дизайні зазвичай усуваються за допомогою удосконалень.
- Покращення - Якщо поведінку потрібно змінити під час фази тестування життєвого циклу програмного забезпечення, створюється удосконалення, яке може бути прийняте у поточному чи наступному випуску, враховуючи терміни та пропускну здатність команд розробки та тестування.
- Є деякі сценарії, які тестер може перевірити під час спеціальних тестів, які насправді можуть бути недійсними сценаріями, враховуючи можливість їх появи у виробництві.
Хто найкращий друг тестера?
Куди повинен відправитись тестер у разі неоднозначності? Відповідь залежить від типу запиту, якщо запит стосується вимог, доцільно спочатку обговорити в колективі, щоб виправити розуміння системи, можна шляхом консультацій зі старшими членами. Наступною точкою контакту повинні бути бізнес-аналітики.
Якщо запит стосується процесу тестування, бажано звернутися до тестового ведучого чи керівника тесту.
Якщо запит стосується розуміння технічних характеристик програми, член команди розробників може стати потрібною людиною, до якої можна звернутися.
Оскільки тестування - це процес, який вимагає загального розуміння системи, комунікація допомагає тестувачу отримати швидку відповідь на запити, це просто залежить від того, щоб задати правильні запитання правильним особам. Ухилення від задавання питань у потрібний час може призвести до дефекту просочення виробничого середовища.
Наскільки важлива роль тестера в корпоративі сьогодні?
Є проекти, де група тестування однаково важлива, як і група розробників, і в деяких сценаріях більша залежність від групи тестування, ніж від команди розробника. Пізніший сценарій зустрічається рідко, але він існує на деяких робочих місцях. Це траплялося з часом і може бути протягом певного періоду часу, коли команда розробників не має великого досвіду порівняно з командою тестування. Є люди, які розуміють загальний потік та функціональність краще, ніж більшість інших членів команди. Така людина може бути частиною команди тестування / розробки. Це один із факторів, який визначає залежність від команди / окремої людини для конкретного проекту.
Який кар’єрний шлях для тестера?
Особі може знадобитися певний час, щоб зрозуміти загальний процес тестування, домен та інші завдання, над якими він / вона, як очікується, буде працювати в повсякденному житті. Виходячи з цього розуміння, доцільно прийняти рішення для вивчення подальших областей, якими може займатися тестер. У процесі завжди є можливості для автоматизації різних потоків. Створення невеликих утиліт також може допомогти команді у великій мірі. Якщо тестер добре програмує, це вважається великим плюсом. Це відкриває можливості для автоматизації ролей. Тестування працездатності також є одним із напрямків кар'єри тестерів. Бізнес-аналітик - ще один варіант. Хороші знання домену та хороші комунікативні навички - це необхідний набір навичок, щоб бути бізнес-аналітиками. Тестування відкриває багато можливостей для тестувальників для роботи в різних областях, інструментах, процесах тощо. Це просто залежить від людини, щоб забрати і почати заглиблюватися всередину однієї з основних тестових областей. Існує багато сертифікатів, характерних для різних інструментів, які спеціалізуються на одній із областей тестування. Сертифікація від стандартного постачальника є перевагою для покращення кар’єри, але сам сертифікат не може допомогти вам у довгостроковій перспективі, якщо не поєднується з правильним досвідом роботи.
Рекомендовані статті
Ось кілька статей, які допоможуть вам отримати більш детальну інформацію про тестування програмного забезпечення, тому просто перейдіть за посиланням.
- 6 найдивовижніших питань тестування програмного забезпечення для інтерв'ю
- Кар'єра в тестуванні програмного забезпечення
- Як покращити кар'єрний ріст роботи тестеру програмного забезпечення