Меню

7-етапове практичне впровадження ручного тестування перед випуском виробництва

7 step practical implementation manual testing before production release

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

У попередньому дописі цієї серії, присвяченому ручному тестуванню, я намагався пролити якомога більше світла на основи ручного тестування.

Якщо ви пропустили це, Ви можете прочитати його тут .

Сподіваюся, це вдало наблизило вас до відповідей, які ви шукали.

У такому випадку, чи не хотіли б Ви дізнатись більше про практичне впровадження ручного тестування, як ознайомитись із ним і як насправді розпочати в ньому кар’єру?

Ця стаття розкриє всі ці аспекти.

Впровадження ручного тестування

Давайте розпочнемо.

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

Цикл ручного тестування

Зрозуміти Цикл ручного тестування або Життєвий цикл тестування програмного забезпечення (STLC), перш за все, нам потрібно зрозуміти життєвий цикл розробки програмного забезпечення (SDLC), про що, я впевнений, ви вже розумієтесь.

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

Як і більшість Світ йде рухливим в ці дні я буду тримати свої речі спрощеними навколо Agile.

7 практичних етапів ручного тестування перед випуском виробництва

Тут я йду.

Пам'ятайте, я говорю як про SDLC, так і про STLC.

# 1) Збір вимог

Вимоги Фаза збору

Бізнес-аналітик (особа / команда, відповідальна за збір вимог) документує вимоги. Вони документують вимоги, це головне, ви можете зосередитись лише на цьому. Те, де це задокументовано, має менше значення.

Люди використовують що завгодно, щоб документувати їх, що підходить їм, але не обмежуючись традиційними платформами, такими як MS word doc, сучасними платформами, такими як Jira / Rally та новими інструментами, такими як Trello.

# 2) Обговорення / обмін вимогами

Етап обговорення вимог

Потім бізнес-аналітик повинен поділитися задокументованими вимогами з командою розробників, командою тестування та командою UX (за потреби). Зазвичай це відбувається на офіційній зустрічі, де SPOC (єдиний пункт контактів або ціла команда, залежно від цього) з усіх трьох функцій відповідають і розуміють всю вимогу.

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

Подальше читання=> Як переглянути документ ЄСВ

Після того, як відповіді на всі запитання та необхідні зміни в вимозі зроблені, цей етап можна розглядати як Готово .

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

Наприклад, документація викликається або розбивається як SRS (специфікація системних вимог), документ документа, епічна версія, історія користувача, точка історії (можливо, найменша одиниця вимоги) і т. д. У подібних рядках ця зустріч, на якій спільно використовуються вимоги, називається як Вимога Обговорення на засіданні, догляді, зборі дірок та ін., Сподіваюся, ви зрозуміли мою думку?

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

Опублікуйте цю зустріч двома кроками, які запускаються одночасно, не в певному порядку, див. Наступні два кроки.

# 3) Проектування

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

Цей етап може включати, але не обмежуючись наступними завданнями:

  • Вирішення підходу до розвитку
  • Підготовка проектного документа
  • Створення блок-схем
  • Оцінка зусиль
  • Визначення впливу цієї нової вимоги на будь-яку існуючу функціональність
  • Потрібно виправити наявні дані тощо.

Команда UX також може залучитись до цієї фази, коли відбувається зміна інтерфейсу користувача або розробляється новий екран. Команда UX допомагає команді розробників та команді тестувальників з використанням прототипу інтерфейсу для функціональності / функції в обговоренні. Це може бути документ Photoshop, просте зображення, презентація PowerPoint або щось інше, що змусить команду розробників зрозуміти, як слід розробляти екрани.

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

# 4) Сценарій тесту / проектування кейсів

Тестовий сценарій Фаза проектування

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

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

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

Тестові кейси, написані в ідеалі, переглядаються керівником тесту або колегою з багатьох сторін, таких як:

  • Покриття вимог
  • Граматика правопису
  • Стандарти написання тестових кейсів (не що інше, як шаблон, якого дотримується команда / компанія)
  • Зворотна сумісність
  • Сумісність з платформою
  • Тестові посилання на дані
  • Види цільового тестування тощо.

Подальше читання=> Написання тестових кейсів із документа SRS

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

Коли я сказав «коли закінчення написання тестового випадку», я мав на увазі одного разу «всі тестові кейси написані на основі повного знання даної вимоги та можливих сценаріїв тестів, розкритих до цього конкретного часу». Практично неможливо забезпечити 100% охоплення тестових випадків на першому шляху.

Будуть дефекти, які ви знайдете в випадкових (але передбачуваних) діях, у суто випадкових діях (тестування мавп) та в деяких рідкісних сценаріях. Є ймовірності, що ви пропустите деякі з них. І в якийсь час ти можеш пропустити навіть дуже базові, зрештою, ти людина. Але тут, принаймні, хороший огляд тестового кейсу та структурований спосіб написання тестових кейсів можуть вас врятувати.

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

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

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

У будь-якому випадку, це взагалі окрема тема для обговорення. Поділитися інформацією 'підходить для всіх' щодо цього важко, але дозвольте мені спробувати.

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

Подальше читання=> Як написати документ плану тестування

Інформація, яку на цьому етапі слід абсолютно заморозити:

  • Сфера тестування: Вимоги, зворотна сумісність, платформи, пристрої тощо.
  • Людина / Команда, яка збирається тестувати
  • Оцінка тестового зусилля
  • Обмеження: Будь-які припущення або обмеження, прийняті заздалегідь.
  • Люди додатково документують критерії вступу, критерії виходу, ризик тощо, про що, я думаю, насправді не потрібно окремо згадувати, оскільки це має бути швидше нормальне розуміння.
    • Критерії вступу (Коли починати тестування): мало хто починає, коли для тестування доступна перевіряемая частина функціональних можливостей. Мало хто чекає на тестування всієї функціональності. Як тільки базовий потік виявиться робочим, починається тестування.
    • Критерії виходу (Коли зупинятись): Коли блокувальника немає, критичні та основні (піддані удару) дефекти при відкритому етапі тестування можуть бути зупинені. Або посередині, коли надто багато дефектів, з якими стикаються тестування, можуть бути зупинені відповідними зацікавленими сторонами.
    • Ризик : Бізнес-ризик або функціональний ризик, якщо тестування не відбувається відповідно до задокументованого плану.

# 5) Фаза розвитку

Етап розробки програмного забезпечення

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

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

# 6) Етап тестування

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

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

який пристрій виконує трансляцію мережевих адрес (nat)?

Дозвольте детальніше вивчити цей етап і поговорити про важливі завдання:

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

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

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

Прочитайте докладні кроки=> Етап виконання тесту

# 7) Огляд бізнес-аналітика (BA)

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

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

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

# 8) Відвантаження / Випуск

Випуск позначено як 'Готовий до відвантаження' після успішного огляду бізнес-аналітиком.

Рекомендуємо прочитати=> Тестовий процес випуску

Види ручного (читайте людського) тестування

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

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

Далі він ділиться на декілька типів залежно від обсягу та порядку денного тестування. Типи, перелічені в наступному абзаці.

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

Нижче наведено перелік деяких популярних та важливих типів тестування, які можна віднести до категорії тестування на людині:

  • Ручне функціональне тестування : Тестування функціональності програми на відповідність даній вимозі з використанням людських зусиль та розуму. Далі ділиться на чимало типів залежно від обсягу та порядку денного тестування, таких як тестування системи, модульне тестування, тестування диму, перевірка розумності, інтеграційне тестування, регресійне тестування, тестування інтерфейсу користувача тощо.
  • Тестування продуктивності : Це потрапляє в категорію Нефункціональне тестування, чи не так? Але знову ж таки людина реалізує його, хоча виконання виконується або людиною, або інструментом. Тестувальник повинен принаймні провести це тестування з точки зору часу відгуку (щоб перевірити, чи це прийнятно), якщо він не повинен використовувати будь-який інструмент для тестування навантаження та все.
  • Браузер / Тестування сумісності платформи: Випробовуваний додаток повинен виглядати і працювати належним чином (очевидно, що може бути незначна різниця в залежності від механізму браузера) у браузерах та платформах (або на пристроях, якщо це мобільний додаток).
  • Тестування юзабіліті : Дозвольте насамперед погодитися з тим, що це сама по собі величезна тема, яка, як правило, належить спеціалістам з тестування юзабіліті. Я все ще вважаю, що як тестувальник ми повинні принаймні повідомляти або виділяти, якщо ми знаходимо щось менш придатне для використання, або ми повинні поділяти нашу думку.
  • Тестування безпеки : Знову ж таки дуже величезний тип тестування і, звичайно, вимагає великих практичних знань. Тестер повинен спробувати вивчити та виконати щонайменше базові тести, такі як фальсифікація URL-адрес, сценарії між сайтами, введення SQL, викрадення сеансу тощо, залежно від наявних знань та, де це можливо.
  • Тестування багатоквартирного житла: Якщо ваша програма багатокористувацька, тобто один екземпляр, що містить дані кількох клієнтів, це тестування є обов’язковим. Незалежно від прямого згадування у вимогах, це слід робити. Дані одного клієнта, що передаються іншому, є свого роду злочином для розробки та тестування.

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

Це все для цієї частини. Дякую за читання. Діліться своїми думками / відгуками в коментарях.

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

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

^