Знайомство з роботою тестеру програмного забезпечення
Що перше, що вам спадає на думку, коли ви думаєте про тестування програмного забезпечення? Робота, що не кодує? Або професія, яка дуже проста, оскільки дає вам можливість знаходити помилки в роботі інших (пошук помилок, коли в інших - це найпростіше завдання для всіх нас)? Або ви вважаєте це професією, яка займається перевіркою правильності продукту? Усі ці думки правильні і є щоденними заходами для роботи тестеру програмного забезпечення. Однак тестування програмного забезпечення не обмежується лише цією діяльністю.
Розуміння програми
Додаток може бути з будь-якого домену - охорони здоров’я, страхування, фінансів тощо. Вивчення домену додатків дуже важливо для будь-якої роботи з програмним забезпеченням, щоб відкрити двері для мислення з різних ракурсів та різних поглядів користувачів під час тестування програми. Розкриття та підтвердження очевидних і не настільки очевидних шляхів застосування завжди є основним очікуванням від цього. Поглиблене знання про програму допомагає ефективно перевірити продукт одночасно, тестер може стати перевагою проекту, де він / вона вважається одним із першоджерел знань щодо поведінки товару.
Хоча вивчення домену та функціональності є постійним процесом, для будь-якого іншого важливого фактора є знання про процес тестування.
Процес тестування
Процес тестування може відрізнятися від компанії до компанії або навіть від одного проекту до іншого. Сьогодні у нас існують різні моделі розробки програмного забезпечення, такі як V модель, модель прототипування або зовсім інша методологія, як Agile підхід до розробки програмного забезпечення. Зі зміною моделі розробки змінюється і підхід до тестування, якого слід дотримуватися. Робота у V-моделі матиме чітко визначені процеси, тоді як очікується, що ця робота в умовах гнучкої методології буде перевірена в умовах, що постійно змінюються.
Завдання ще не налагоджене: наявність прийнятних знань про домен та розуміння процесу тестування, наступне завдання, яке постає перед життям, - це вивчення різних інструментів.
Інструменти
Інструменти мають на увазі інструменти управління тестами, засоби дефектного ведення журналів, засоби управління базами даних тощо.
Завдяки різноманітним програмним забезпеченням для реєстрації дефектів, його якостям та інструментам, деяким відкритим кодом та деяким ліцензіям, завжди є перевагою мати знання про декілька інструментів. Це допомагає йому легко переходити проекти чи команди, дотримуючись різних інструментів. Завдяки адекватним знанням домену, процесів та інструментів, це більше сприяє роботі Тестеру програмного забезпечення, що робить його робочі дні складними та захоплюючими. Співпраця в командах є одним з важливих факторів успіху будь-якого проекту, а для ефективної співпраці спілкування відіграє дуже важливу роль.
Рекомендовані курси
- Повний J2EE комплексний курс
- Інтернет-навчання з програмування R
- Перейдіть на курс програмування
- Навчання онлайн-сертифікації в програмі Haskell
Зв'язок
Комунікація відіграє дуже важливу роль для її якості програмного забезпечення, оскільки з початкових етапів розробки програмного забезпечення члени групи тестування беруть участь (як найкраща практика) в обговоренні вимог, опитують бізнес-аналітиків у разі будь-яких запитів або прогалин у вимозі. Тестер, який має ефективні комунікативні навички, може ефективно повідомляти про ризики, може ефективно спілкуватися з командою розробників, а також ефективно передавати результати тестів та звіти про тестування.
Планування робіт із тестування програмного забезпечення
Як випливає з назви, планування тесту - це етап, коли здійснюється підготовка до тестування. Підготовка до тестера передбачає різні види діяльності, які проводить, щоб ефективно застосувати програму. Це допоможе перевірити програму та ефективно розкрити дефекти програми. Для того, щоб почати планування, тест проходить через вимоги, щоб зрозуміти очікування.
1. Вимоги
Вимоги можуть бути задані команді тестування у вигляді каркасів, дощок для розкадрувань, аркушів Excel. Мета всіх цих документів - це ефективно та легко зрозуміти вимоги клієнта. Документ Wireframe - це не що інше, як документ, який може бути у формі презентації PowerPoint, яка зображує вимоги клієнта. На цих же лініях, на раскадровках зазвичай зображено необхідний вигляд / дизайн екранів. На сьогоднішній день на ринку доступні різні інструменти, які можна використовувати для підготовки необхідних документів. Створення необхідних документів є основною відповідальністю бізнес-аналітика. Очікується, що дегустація досконало зрозуміє вимоги. Для того, щоб тести та розробники зрозуміли вимоги правильно, бізнес-аналітики тримають форум відкритим для всіх, щоб підняти та отримати відповіді на запити щодо будь-якої з вимог. Платформа для обговорення та передачі відкритих питань та запитів варіюється від проекту до проекту. Це може бути ланцюжок електронних листів, конференц-дзвінок або навіть сховище спільного диска, що підтримується для відстеження всіх відкритих питань та їх відповідей, передбачених бізнес-аналітиком.
Чітка комунікація та запис спілкування відіграють дуже важливу роль для підтвердження. Невелике припущення щодо вимоги іноді може призвести до значного дефекту товару. На кожному етапі рекомендується тестувати якість тестування програмного забезпечення, щоб підтримувати чистоту зв'язку. Тестер програмного забезпечення Робоча комунікація може бути з бізнес-аналітиками або навіть у команді. Чітка комунікація допомагає уникнути припущень під час планування та виконання. У той же час рекомендується мати запис зв'язку (бажано спілкування електронною поштою). Наявність письмового повідомлення щодо запитів у відповідності до вимог допомагає на пізніх етапах виконання тесту, коли функціональність, можливо, не була б розроблена, як це підтверджено в записаному повідомленні.
2. Сценарій
Після того, як вимоги будуть зрозумілі, тестер починає документувати сценарії в документі тестового сценарію. Сценарій, як випливає з назви, - це функціональний потік, який користувач дотримується для виконання завдання.
Приклади сценаріїв -
- Користувач повинен мати можливість успішно увійти.
- Користувач повинен мати можливість бронювати квитки в системі.
- Користувач повинен мати можливість скасувати квитки в системі.
- Користувач повинен мати можливість перегляду / оновлення деталей профілю.
Це логічні завдання, які користувач виконує в системі. Ці логічні завдання при згрупуванні разом допомагають помітити всі можливі сценарії, які користувач повинен виконати. Ці сценарії зазвичай задокументовані на аркушах Excel або іноді використовуються деякі інструменти. Дослідження процвітає, щоб витягнути всі подібні сценарії з вимогливих документів. Документ, що містить такі сценарії, називається Документ тестового сценарію (або десь як Документ сценарію високого рівня). Цей документ служить вхідним документом для складання тестових справ.
3. Справа
Цей випадок є більш детальною версією робочого сценарію Software Tester, де сценарій розбивається на більш детальні кроки, які користувач насправді виконує під час використання програми. Простий приклад на основі вищезазначених сценаріїв:
Сценарій - Користувач повинен мати можливість успішно увійти.
Випробування:
- Переконайтеся, що користувач може ввести правильне ім’я користувача.
- Переконайтеся, що користувач може ввести пароль.
- Перевіривши, натиснувши кнопку Вхід після введення правильного імені користувача та пароля, користувач може успішно увійти.
Такий перелік цих випадків може включати перевірку перевірки на кожне поле, перевірку негативних сценаріїв тощо.
Нижче наведено кілька додаткових прикладів цих випадків -
- Перевірте, що ім'я користувача, коли воно не введено, система видає відповідну помилку.
- Перевірте, що пароль, коли він не введений, система видає відповідну помилку.
- Перевірте, що ім’я користувача та пароль, коли вони не введені, система видає відповідну помилку.
- Переконайтесь, що вводячи неправильний пароль, система видає відповідне повідомлення про помилку.
- Перевірте, що при введенні неправильного імені користувача система видає відповідне повідомлення про помилку.
4. Матриця відстеження вимог (RTM)
Матриця відстеження вимог, як випливає з назви, допомагає довести перевірку та включення охоплення вимог, передбачених Бізнес, у документи тестування, такі як сценарії та тестові випадки.
Як найкраща практика, це окремий документ, що показує відображення номера вимоги до сценарію / випадків, що містять цю вимогу.
Цей документ не може використовуватися у всіх видах проектів, але при його використанні він допомагає сильно простежити відображення сценаріїв високого рівня до вимог. Він вказує на охоплення і може бути використаний для перевірки наявності хоча б одного цього випадку проти кожної вимоги. Створення та підтримка RTM документа вважається найкращою практикою, однак не всі види проектів (як Agile) використовують програмне забезпечення для підтвердження робочого документа. Коли вимоги змінюються дуже часто, підтримка цього документа може бути почута. Щоб уникнути подібних накладних витрат і в той же час створити спосіб відстеження вимог, деякі проекти включають частину відстеження в робочий випадок Software Tester або в сам його сценарій.
Важливим аспектом є створення способу простеження сценаріїв / випадків до вимог і навпаки. Добре задокументовані вимоги полегшують завдання Prover створювати та підтримувати ці документи. Неоднозначні вимоги, постійно змінюються вимоги роблять життя більш складним і може призвести до наявності суперечливих документів, що призводять до пропуску певної валідації, а отже, і до дефекту кінцевого продукту.
Поки подорож для тестера планував і готувався до тестування. Оскільки підготовка до війни є частиною війниJ, те саме стосується і тут. Чим більш лаконічно створені ці документи, тим легше перевіряючим перевірити функціональність та виявити майже всі дефекти. Наступний етап подорожі тестера - Виконання.
Виконання тестеру програмного забезпечення працює
Це фаза, коли всі вищезазначені документи вводяться в експлуатацію. Вимоги були використані для створення Сценарію, для його створення використовувались Сценарій. цей Документ справ - це самодостатній документ тут для початку перевірки програми. Prover запускає перевірку програми, виконуючи кроки з цього документа справи. Кілька цих випадків можуть бути використані для перевірки одного сценарію, або навіть один тестовий випадок може відповідати одному тестовому сценарію. Все залежить від складності сценаріїв, а іноді і від стандарту, який слід застосовувати в тестовій групі. Отже, один тестовий документ може містити 20-50 тестових випадків, або він може мати 100-120 тестових випадків. Ці цифри призначені лише для пояснення, вони можуть дещо відрізнятися від проекту до проекту. Результатом цієї фази є тестові дефекти. Кількість дійсних дефектів, виявлених на цій фазі, дає гарне уявлення про стабільність застосування, якість тестування, якість складання та багато таких факторів, які безпосередньо впливають на виріб. Ця фаза є найважливішою фазою, оскільки тестер процвітає, щоб охопити всі тестові випадки (перевіряючи майже всі необхідні шляхи користувача) і в той же час підняти якомога більше дійсних дефектів. Усі підготовчі, комунікативні навички, запити, просині, щоб бізнес надходив на цій фазі тестування.
Дефекти програмного тестера працює
Під час виконання цього випадку будь-яка поведінка, яка не дорівнює очікуваному результату, піднімається як Дефект. Кожен тестовий випадок містить опис, очікуваний результат та стовпець для фактичного результату. Хоча в цьому документі на робочий документ із тестування програмного забезпечення є опис та очікувані результати та порожній стовпець для фактичних результатів. Під час виконання тестових випадків тестер повинен заповнити стовпець фактичного результату. У той же час, якщо фактичне значення не дорівнює очікуваному результату, дефект реєструється. Реєстрація дефекту просто не означає інформування розробника про проблему. Це знову формальний процес, який зазвичай виконується за допомогою інструменту. В даний час на ринку є різні інструменти, деякі з відкритим кодом, а деякі з ліцензованими. Будь-який інструмент реєстрації дефектів має такі поля -
- Назва проекту / випуску
- Підсумок дефектів
- Детальний опис дефекту
- Дефект серйозності
- Пріоритет дефекту
- Фаза виявлена дефектом
- Присвоєно
- Вкладення
Як ми бачимо, мета всіх цих полів полягає в тому, щоб знайти формальну детальну інформацію про проблему. Це допомагає розробникам відтворити дефект у своєму оточенні та виправити його. Нижче наведено короткий опис усіх цих полів -
- Назва проекту / випуску - назва випуску, де виявлено дефект, зазвичай проект має декілька випусків, і той самий проект може мати декілька підпроектів. Це поле допомагає підняти проблему для конкретного випуску.
- Підсумок дефекту - короткий опис знайденого дефекту в одній лайнері.
- Детальний опис дефекту - Це детальний опис дефекту, він повинен містити деталі, такі як середовище, де виявлений дефект, та використовувані дані тесту, фактичні результати, очікувані результати та будь-яку додаткову інформацію, яка додає більш цінну інформацію для зацікавлених сторін, щоб зрозуміти дефект.
- Важкість дефекту - це означає, наскільки важкий дефект. Зазвичай він має значення, схожі на критичні, високі, середні, низькі або числові значення, такі як 4, 3, 2, 1.
- Пріоритет дефекту - означає, наскільки терміново потрібно виправити дефект.
- Фаза виявлена дефектом - Оскільки існує багато фаз, коли дефект можна ввійти, фаза тестування блоку, SIT (тестування системної інтеграції), UAT (тестування прийняття користувача) або навіть фаза виробництва.
- Призначено - Ім'я розробника або ведучий розробника.
- Додатки - це дало можливість тестеру прикріпити знімок екрана, на якому виникла проблема.
Виконання тесту та ведення дефектів - це фаза, з якою може зіткнутися тестер. Деякі з них ефективно спілкуються з розробниками. Чи можемо ми стверджувати, що реєстрація дефекту зі всією необхідною інформацією недостатня для розробників, щоб зрозуміти дефект?
Це є, а в деяких випадках вимагає додаткового пояснення / обговорення з розробниками. Бувають випадки, коли тестер стикається з несподіваною поведінкою, в якій він / вона може бути не впевнений, чи є дефектом. З цими обставинами, як правило, стикаються нові люди в команді, які мають обмежені знання в галузі або мають неоднозначність щодо вимог. Ну, тут не слід звинувачувати тестера, якщо існують жорсткі терміни і постійно змінюються вимоги, і в більшості випадків доводиться дізнатися про домен, фактично плануючи та виконуючи тестові справи. Як ми бачимо, шлях тестера не такий простий, як сприймається. Це вимагає постійно ставлення до навчання, хороших навичок спілкування, хороших навичок співпраці та прагнення налаштувати себе в умовах, коли є зміни в областях, інструментах, процесах, що використовуються. Поки ми говорили про подорож ручних тестерів, загальний процес стосується і тестерів автоматизації. Автоматизація, з іншого боку, мають суттєві зміни в процесі, оскільки обсяг тестування та планування, виконання значно відрізняється.
Враховуючи подорож дослідника, як обговорювалося вище, чи можна все-таки сказати, що робота з якостями тестеру програмного забезпечення простіша, ніж у розробника?
Можна сказати, що більш ніж порівняння ролей розробника тестера v / s, корисніше буде обговорити, як співпраця двох може призвести до головного успіху продукту в цілому. Ми іноді забуваємо, що завдання тестера - знаходити проблеми в додатку, а не вказувати на помилки розробників. Коли ми забуваємо саму ідею своєї роботи, це іноді призводить до зайвої дискусії. Однак було помічено, що є однаково хороші групи тестування, розробки, де всі розуміють, що кінцева мета - зробити так, щоб заявка працювала, як очікувалося. Будемо сподіватися, що кожен буде дивитися на позитивну сторону тестування як на роль, яка допомагає в очищенні продукту, а не як на ту, яка просто виявляє помилки!
Рекомендовані статті
Це було керівництвом для розкриття та підтвердження очевидних і не настільки очевидних шляхів застосування - це завжди головне очікування роботи тестеру програмного забезпечення. Це наступне зовнішнє посилання, пов'язане з роботою тестеру програмного забезпечення.
- Життєвий цикл дефектів при тестуванні програмного забезпечення
- 6 найдивовижніших питань тестування програмного забезпечення для інтерв'ю
- Кар'єра в тестуванні програмного забезпечення