Всі відомі типи тестування (100+ штук)

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Буду рада бачити вас на україномовному Ютюбі, де я викладаю багато теорії та практики з тестування ПЗ безкоштовно. Стаття написана на основі відео «Всі типи тестування» :)

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

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

Усі типи тестування, де не вказано, хто їх проводить, проводяться командою тестування.

  1. Functional — тип тестування, який базується на специфікаціях та вимогах до програми, що тестується.

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

  3. API testing. API (інтерфейс прикладного програмування) — це набір процедур, протоколів і інструментів взаємодії для створення програмних додатків. Цей інтерфейс визначає, як одна програма повинна взаємодіяти з іншою, дозволяє їм спілкуватися. А тестування цих функцій називається тестуванням API. Воно визначає, чи розроблені API відповідають очікуванням щодо функціональності, надійності, продуктивності та безпеки програми. Ця техніка тестування подібна до юніт тестування тим, що націлена на рівень коду. Тестування API відрізняється від юніт тестування тим, що зазвичай це завдання тестувальника, а не розробника.

  4. Compliance — тип тестування, який перевіряє, чи розроблено систему відповідно до стандартів, процедур і настанов. Зазвичай це виконується сторонніми компаніями, які пропонують сертифікацію «Certified OGC Compliant».

  5. Conformance — процес перевірки того, що реалізація відповідає специфікації, на якій вона заснована.

  6. (Changes related) Sanity — техніка тестування, яка визначає, чи нова версія програмного забезпечення працює достатньо добре, щоб прийняти її для серйозного тестування. За ISTQB, Sanity = Smoke testing.

  7. Confirmation testing — див. Re-testing

  8. Re-testing — тип тестування, в якому інженер перевіряє виправлення дефекту, запускаючи тест, що виявив дефект.

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

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

  11. Backward compatibility — метод тестування, який перевіряє поведінку розробленого програмного забезпечення зі старими версіями тестового середовища. Виконується командою тестування.

  12. Age — тип тестування, який оцінює здатність системи працювати в майбутньому. Процес оцінювання проводиться командами тестування.

  13. Сomparison testing — техніка тестування, яка порівнює сильні та слабкі сторони продукту з попередніми версіями чи іншими подібними продуктами. Може виконуватися тестувальником, розробниками, менеджерами або product owner’ами.

  14. Qualification — тестування на відповідність специфікаціям попереднього релізу, зазвичай проводиться розробником для клієнта, щоб продемонструвати, що програмне забезпечення відповідає визначеним вимогам.

  15. Non-functional — техніка тестування, яка зосереджена на перевірці програмного додатку на його нефункціональні вимоги.

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

  17. User Interface — тип тестування, який виконується для перевірки user-friendliness програми.

  18. GUI software — процес тестування продукту, який використовує графічний інтерфейс користувача, щоб переконатися, що він відповідає специфікаціям та вимогам.

  19. Load — техніка тестування, яка навантажує систему чи пристрій та вимірює їх реакцію. Зазвичай його проводять performance інженери.

  20. Performance — тестування, яке проводиться для оцінки відповідності системи або компонента визначеним вимогам до продуктивності. Зазвичай його проводить performance інженер. Також відоме як категорія, що об’єднує всі типи навантаження.

  21. Stress — техніка тестування, яка оцінює систему або компонент на рівні або поза межами встановлених вимог. Зазвичай його проводить performance інженер.

  22. Ramp — тип тестування, що полягає в постійному підвищенні вхідного сигналу, доки система не вийде з ладу. Його може проводити команда тестування або performance інженер.

  23. Stability — техніка тестування, яка намагається визначити, чи відбудеться збій програми, та перевіряє стабільність ПЗ. Зазвичай його проводить performance інженер.

  24. Benchmark — техніка тестування, яка використовує набори програм і даних, призначених для оцінки продуктивності апаратного та програмного забезпечення комп’ютера в певній конфігурації.

  25. Scalability — частина нефункціональних тестів, яка перевіряє програмне забезпечення для вимірювання його здатності до масштабування — будь то підтримуване навантаження користувача, кількість транзакцій, обсяг даних тощо. Його проводить performance інженер.

  26. Volume — тестування, яке підтверджує, що будь-які значення, які можуть стати великими з часом (наприклад, накопичені підрахунки, логи та файли даних), можуть бути прийняті програмою та не призведуть до припинення роботи програми чи погіршення її роботи будь-яким чином. Зазвичай його проводить performance інженер.

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

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

  29. Globalization — метод тестування, який перевіряє належну функціональність продукту з будь-якими налаштуваннями культури/мови з використанням усіх можливих міжнародних вхідних даних.

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

  31. Configuration — техніка тестування, яка визначає мінімальну та оптимальну конфігурацію апаратного та програмного забезпечення, а також вплив додавання або модифікації ресурсів, таких як пам’ять, диски та ЦП. Зазвичай це виконують performance інженери. Configuration testing — за ISTQB див. portability testing.

  32. Compatibility — техніка тестування, яка перевіряє, наскільки добре працює програмне забезпечення в певному апаратному/програмному забезпеченні/операційній системі/мережевому середовищі. Комп’ютерні системи, які не пов’язані одна з одною, вважаються сумісними, якщо вони можуть працювати в одному середовищі (наприклад, на одному апаратному забезпеченні), не впливаючи на поведінку одна одної. Сумісність слід перевіряти, коли нове або оновлене програмне забезпечення буде розгорнуто в середовищах, які вже містять встановлені програми.

  33. Portability testing — процес тестування для визначення переносимості програмного продукту.

  34. Binary portability — техніка, яка перевіряє виконувану програму на переносимість між системними платформами та середовищами, як правило, на відповідність специфікації Application binary interface.

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

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

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

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

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

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

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

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

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

  44. (Test design techniques) Equivalence partitioning — техніка тестування програмного забезпечення, яка розділяє вхідні дані на еквівалентні групи тестових даних, які поводяться однаково.

  45. Boundary value — техніка тестування програмного забезпечення, у якій тести перевіряють дані на проміжках та границях.

  46. Exploratory — техніка чорного ящика, що виконується без планування та документації. Вимагає більше скілів і досвіду, ніж Ad-hoc.

  47. Session based testing — тестування за допомогою сесій, використовується за допомогою тест чартерів з визначеним часом, є підходом дослідницького (Exploratory) тестування.

  48. Persona Based Testing — тестування на основі персон, визначає типажі юзерів та описує поведінку певних категорій користувачів системи.

  49. Error guessing — техніка тестування, в якій інженер намагається вгадати потенційні помилки, щоб знайти дефекти.

  50. Fuzz — техніка тестування програмного забезпечення, яка надає недійсні, неочікувані або випадкові дані на вході програми.

  51. Fault injection — елемент комплексної стратегії тестування, який дозволяє тестувальнику зосередитися на тому, як тестована програма здатна обробляти винятки. (див. Error handling)

  52. Penetration — метод тестування, який оцінює безпеку комп’ютерної системи або мережі шляхом імітації атаки зі зловмисного джерела. Зазвичай вони проводяться спеціалізованими компаніями з тестування на проникнення.

  53. Pairwise — комбінаторний метод тестування, який перевіряє всі можливі дискретні комбінації вхідних параметрів.

  54. All-pairs — див. Pairwise

  55. Pair testing — техніка розробки програмного забезпечення, за якої два члени команди працюють разом за однією клавіатурою, щоб перевірити програмне забезпечення. Один проводить тестування, а інший аналізує або переглядає результат. Це можна зробити між одним тестувальником і розробником або бізнес-аналітиком або між двома тестувальниками, коли обидва учасники по черзі керують клавіатурою.

  56. State & Transition Testing — тестування на основі станів та переходів, використовується у системах зі cкінченним числом станів, перевіряє всі можливі дії у різних станах системи та дозволяє проаналізувати, які переходи можна здійснювати між різними станами системи.

  57. Parallel — тип тестування програмного забезпечення, у якому кілька версій або підкомпонентів програми тестуються з однаковими вхідними даними на різних системах одночасно, щоб скоротити час виконання тесту. Мета паралельного тестування полягає в тому, щоб з’ясувати, чи поводяться застаріла версія та нова версія однаково чи по-різному, і переконатися, чи нова версія ефективніша чи ні.

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

  59. Path — типове тестування білого ящика, яке має на меті задовольнити критерії покриття для кожного логічного шляху через програму. Зазвичай виконує команда розробників.

  60. Basis Path — метод тестування білої скриньки, у якому тестові випадки визначаються на основі потоків або логічних шляхів, які можна пройти через програму. Метою тестування базового шляху є визначення кількості незалежних шляхів, тому необхідну кількість тестових випадків можна визначити явно, щоб максимізувати покриття тесту. У розробці програмного забезпечення тестування базового шляху передбачає виконання всіх можливих блоків у програмі та досягнення максимального покриття шляху з найменшою кількістю тестових випадків. Це гібридний метод тестування гілок і методів тестування шляху.

  61. Workflow — техніка end-to-end тестування за сценарієм, яка дублює певні робочі процеси, які, як очікується, використовуватиме кінцевий користувач.

  62. Statement Coverage — тестування білого ящика, яке задовольняє критерій, згідно з яким кожен оператор у програмі виконується принаймні один раз під час тестування програми. Зазвичай виконує команда розробників.

  63. Branch testing — техніка тестування, за якої всі гілки вихідного коду програми тестуються принаймні один раз. Тип тестування, у якому кожна умова/рішення виконується шляхом встановлення значення true/false. Зазвичай це робиться групами автоматизованого тестування або розробниками.

  64. Decision Coverage — див. Branch testing

  65. Condition coverage — тип тестування програмного забезпечення, у якому кожна умова виконується, коли вона істинна та хибна, кожним із способів принаймні один раз. Зазвичай його створюють команди автоматизованого тестування.

  66. Loop — техніка тестування білого ящика, яка використовує програмні цикли. Виконується командами розробників.

  67. Mutation — метод тестування, який передбачає зміну вихідного коду програм або байт-коду невеликими частинами, щоб перевірити частини коду, до яких рідко або ніколи не звертаються під час звичайного виконання тестів.

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

  69. (Approaches) Black box — метод тестування програмного забезпечення, який перевіряє функціональність програми без певних знань про код/внутрішню структуру програми. Тести базуються на вимогах і функціональності.

  70. Gray box — поєднання методологій тестування Black Box і White Box: тестування програмного забезпечення на відповідність його специфікаціям, але з використанням певних знань про його внутрішню роботу. Його можуть виконувати команди розробників або тестувальників.

  71. Glass box — див. White box

  72. White box — техніка тестування базується на знанні внутрішньої логіки коду програми та включає такі тести, як охоплення операторів коду, гілок, шляхів, умов. Його виконують розробники програмного забезпечення.

  73. Automated — техніка тестування, яка використовує інструменти автоматизованого тестування для контролю налаштування середовища, виконання тесту та звітування про результати. Він виконується комп’ютером і використовується всередині команди тестування.

  74. Manual scripted — метод тестування, за якого тестові випадки розробляються та переглядаються командою перед виконанням. Ручні сценарії тестування — це документи тестування, які використовуються тестувальниками для тестування сценаріїв, які мають бути виконані в рамках циклу тестування. Як правило, такі ручні сценарії тестів включають такі деталі: загальну інформацію про тест, опис кроку, дані кроку, очікуваний результат, фактичний результат, результат проходження/непроходження.

  75. Manual-support — техніка тестування, яка передбачає перевірку всіх функцій, які виконують люди під час підготовки даних і використання цих даних з автоматизованої системи.

  76. Negative — також відомий як «тест на невдачу» — метод тестування, в якому вводять завідома не правильні дані, щоб перевірити обробку помилок в програмі.

  77. Positive — метод тестування, в якому вводять валідні дані, щоб перевірити успішний сценарій.

  78. End-to-end — подібно до системного тестування включає в себе тестування повного програмного середовища в ситуації, яка імітує реальне використання.

  79. Static — форма тестування програмного забезпечення, де програмне забезпечення фактично не використовується, воно перевіряє головним чином правильність коду, алгоритму чи документа. Його використовує розробник, який написав код, або набирається група для перевірки технічної документації.

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

  81. Active — тип тестування, що полягає у введенні тестових даних і аналізі результатів виконання.

  82. Passive — техніка тестування полягає в моніторингу результатів працюючої системи без введення будь-яких спеціальних тестових даних.

  83. Code-driven — техніка тестування, яка використовує бібліотеки тестування (наприклад, xUnit), які дозволяють виконувати модульні тести, щоб визначити, чи різні розділи коду діють належним чином за різних обставин. Виконується командами розробників.

  84. Keyword-driven — також відома як table-driven або action-word тестування — це методологія для автоматизованого тестування, яка використовує ключові слова в якості команд системі. Може використовуватися групами мануального або автоматизованого тестування.

  85. Modularity-driven — техніка тестування, яка вимагає створення невеликих незалежних сценаріїв, які представляють модулі, розділи та функції програми, що тестується.

  86. Context driven — техніка Agile тестування, яка підтримує безперервну та творчу оцінку можливостей тестування в світлі виявленої потенційної інформації та цінності цієї інформації для організації в конкретний момент. Зазвичай виконується групами Agile тестування.

  87. Domain — техніка тестування білого ящика, яка містить перевірку того, що програма приймає лише дійсні вхідні дані. Зазвичай це роблять команди розробників програмного забезпечення та іноді команди тестування автоматизації.

  88. Model-based — проектування та виконання необхідних артефактів для виконання тестування на основі моделей.

  89. Comparison — тип тестування, під час якого сильні та слабкі сторони розробленого програмного забезпечення порівнюються з уже існуючими програмними продуктами на ринку.

  90. Concurrency — багатокористувацьке тестування, спрямоване на визначення ефектів доступу до того самого коду програми, модуля або записів бази даних. Зазвичай це роблять performance інженери.

  91. Error-Handling — тип тестування, який визначає здатність системи належним чином обробляти помилкові транзакції.

  92. (Levels) Unit — метод перевірки програмного забезпечення та валідації, за якого програміст перевіряє, чи окремі одиниці вихідного коду придатні для використання. Зазвичай його проводить команда розробників.

  93. Component — техніка тестування подібна до модульного тестування, але з вищим рівнем інтеграції — тестування виконується в контексті програми, а не просто безпосередньо тестує певний метод. Може виконуватись командами тестування або розробників.

  94. Integration — етап тестування, на якому окремі модулі програмного забезпечення об’єднуються та тестуються як група.

  95. System testing — процес тестування інтегрованої апаратної та програмної системи для перевірки того, що система відповідає заданим вимогам.

  96. Inter-Systems testing — техніка тестування, яка перевіряє, що взаємозв’язок між програмами працює правильно.

  97. System Integration — процес тестування, який перевіряє співіснування програмної системи з іншими.

  98. Top-down integration — техніка тестування, яка передбачає початок із верхньої частини системної ієрархії в інтерфейсі користувача та використання заглушок для тестування зверху вниз, доки не буде реалізовано всю систему.

  99. Bottom up — під час інтеграційного тестування знизу вгору спочатку розробляються модулі найнижчого рівня, а інші модулі, які йдуть до «основної» програми, інтегруються та тестуються один за одним.

  100. Big bang integration — техніка тестування, яка інтегрує окремі програмні модулі лише тоді, коли все готово.

  101. Hybrid integration — техніка тестування, яка поєднує методи інтеграції «Top-down» і «Bottom up».

  102. Thread — це техніка тестування програмного забезпечення, яка використовується для тестування додатків на основі клієнта-сервера. Тестування на основі потоків слід проводити на початкових етапах тестування інтеграції, щоб ключові функції можна було протестувати/перевірити для конкретного завдання/програми чи потоку.

  103. Acceptance — формальне тестування, яке проводиться, щоб визначити, чи відповідає система Acceptance Criteria, і щоб клієнт міг визначити, приймати чи ні систему. Зазвичай виконується замовником.

  104. Operational — техніка тестування, яка проводиться для оцінки системи або компонента в її робочому середовищі.

  105. Alpha — тип тестування програмного продукту або системи, що проводиться на сайті розробника. Зазвичай виконується командою розробки (і розробниками, і тестувальниками).

  106. Beta — остаточне тестування перед випуском програми для комерційних цілей. Зазвичай це роблять кінцеві користувачі або інші особи.

  107. Gamma — тип тестування перед випуском продукту, спрямований на виправлення незначних дефектів, виявлених у бета-тестуванні. Як правило, виконується з максимальним залученням кінцевих користувачів або замовника.

  108. (Without category) Agile — практика тестування програмного забезпечення, яка відповідає принципам гнучкого маніфесту, наголошуючи на тестуванні з точки зору клієнтів, які використовуватимуть систему.

  109. Assertion — тип тестування, що полягає в перевірці, чи умови підтверджують вимоги до продукту.

  110. Accessibility — тип тестування, який визначає можливість використання продукту людьми з обмеженими можливостями (з браком слуху, зору, ментальними хворобами). Процес оцінювання проводиться особами з обмеженими можливостями. Accessibility не лише про інклюзивність чи фізичні особливості. А ще, як приклад: водій за кермом, або жінка, яка везе візок з дитиною.

  111. Ad-hoc — тестування проводиться без планування та документації — тестувальник намагається «зламати» систему, випадково пробуючи функціональність системи.

  112. Breadth — Набір тестів, який використовує всі функціональні можливості продукту, але не перевіряє детальні функції. Може використовуватись в різних контекстах (Integration, sanity, functional, system, automation, regression)

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

  114. Install/uninstall — робота, яка зосереджена на тому, що потрібно буде зробити клієнтам, щоб успішно встановити та налаштувати нове програмне забезпечення. Може включати повні або часткові процеси встановлення/видалення оновлень і зазвичай виконується інженером з тестування програмного забезпечення разом із менеджером конфігурації.

  115. A/B testing — підхід статистичного тестування, щоб визначити, яка з двох систем або компонентів працює краще.

  116. Risk-based testing — тестування на основі ризиків, допомагає пріоритезувати тести в системі та зробити розподіл функціональності на основі вірогідності виникнення різних помилок.

  117. Tours Based Testing — тестування на основі турів, використовує різні метафори та ситуативні сценарії, на які накладається робота системи.

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

  119. Extended test — тестування, спрямоване на дослідження всієї заявленої у вимогах функціональності — навіть тієї, яка низько проранжована за ступенем важливість.

Що ж,

якщо маєте типи, яких тут бракує — пишіть в коменти

якщо маєте, що виправити — пишіть в коменти

якщо хочете побути токсіками — не пишіть в коменти

якщо хочете підтримати україномовний контент — підпишіться сюди:)

Всім добра і перемоги,
Попелюха

👍ПодобаєтьсяСподобалось21
До обраногоВ обраному19
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А я побуду занудою на підтримку автора. мені якраз подобається класифікация ISTQB, бо вона є притомним стандартом. Ось просто цікаво — а звідки взялися тлумачення, що саніті — це не те саме, що смоук? Хто це сказав, є джерело?

Змішалось все: руки, ноги, коні.. 😅😅

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

Що мені сподобалось в матеріалі. Те, що зібрано все до купки в одному місці.

Що мені не сподобалось в матеріалі. Я не дуже зрозумів мети (ну може хіба те, що зібрано все в одному місці). І як це комусь має допомогти на практиці.

Ще маю відмітити таку річ. В цьому світі кожне слово, термін, визначення — має значення. Бо слова створюються не просто так.
Якщо ми говоримо про «всі типи» тестування, то техніки, методи, процеси перевірки, набори процедур, і тд — це не типи. Це буквально методи, техніки і тд)
Я би їх сюди не тулив. Або трохи погрався б з визначенням, якщо це стосується типів. Ну, або замінив назву статті, яка згадує лише типи.

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

З приводу UI тестування не погоджуюсь. Це буквально перевірка юзер інтерфейсу. Як що відображено, чи правильно розташовано, чи відповідає мокапам і тд.
Юзер-френдлінес стосується зручності використання. А це точно вже до типу Usability testing.

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

Що ще не згадано(або я пропустив).

Mobile testing
Interruption testing
Interoperability testing
Crossbrowser testing
Certification testing
Device resources testing

Все є на гуру99. Ну, або просто на схожих ресурсах.

Всі мої слова слід сприймати як рекомендації для покращення матеріалу, не більше.

Дякую за коменти, пане токсіку:)

Більшість інфи якраз таки взята з гуру99, або гікс фор гікс. Юай і тд теж. І як вказано вище, ця стаття це переклад статті Гамільтона з гуру 99 з мінорними правками)

дик може нарешті покращувати здобутки Гамільтона ;)

Було б великою честю для мене, але шота впадлу😅😅😅

Дякую, Попелюха :)

Підписатись на коментарі