У розробці програмного забезпечення, включаючи його тестування, беруть участь люди. Таким чином, людська психологія має важливий вплив на тестування програмного забезпечення.
Виявлення дефектів під час статичного тестування, наприклад перевірки вимог або сеансу вдосконалення історії користувача, або виявлення помилок під час виконання динамічного тестування може сприйматися як критика продукту та його автора. Елемент людської психології, який називається упередженням підтвердження, може ускладнити прийняття інформації, яка суперечить існуючим переконанням. Наприклад, оскільки розробники очікують, що їхній код буде правильним, у них є упередженість підтвердження, через яку важко прийняти те, що код є неправильним. Окрім упередженого підтвердження, інші когнітивні упередження можуть ускладнювати людям розуміння або прийняття інформації, отриманої під час тестування. Крім того, це звичайна людська риса звинувачувати носія поганих новин, а інформація, отримана в результаті тестування, часто містить погані новини.
Внаслідок цих психологічних факторів деякі люди можуть сприймати тестування як деструктивну діяльність, навіть якщо воно значно сприяє просуванню проєкту та якості продукції. Щоб спробувати зменшити це сприйняття, інформацію про дефекти та невдачі слід передавати конструктивно. Таким чином можна зменшити напругу між тестувальниками та аналітиками, власниками продуктів, дизайнерами та розробниками. Це стосується як статичного, так і динамічного тестування.
Тестувальники та керівники тестування повинні мати хороші навички міжособистісного спілкування, щоб мати можливість ефективно спілкуватися про дефекти, збої, результати тестування, прогрес тестування та ризики, а також будувати позитивні стосунки з колегами. Способи гарного спілкування включають такі приклади:
Почніть зі співпраці, а не з битв. Нагадайте всім про спільну мету покращення якості систем.
Підкресліть переваги тестування. Наприклад, авторам інформація про дефекти може допомогти покращити їхні робочі продукти та навички. Для організації дефекти, виявлені та виправлені під час тестування, заощадять час і гроші та зменшать загальний ризик для якості продукції.
Повідомляйте результати тестів та інші висновки нейтрально, зосереджуючись на фактах, не критикуючи людину, яка створила дефектний предмет. Напишіть об’єктивні та фактичні звіти про дефекти та перевірте висновки.
Спробуйте зрозуміти, що відчуває інша людина та чому вона може негативно відреагувати на інформацію.
Підтвердьте, що інша особа зрозуміла сказане, і навпаки.
Типові цілі тесту були розглянуті раніше. Чітке визначення правильного набору цілей тесту має важливі психологічні наслідки. Більшість людей схильні узгоджувати свої плани та поведінку з цілями, поставленими командою, керівництвом та іншими зацікавленими сторонами. Також важливо, щоб тестувальники дотримувалися цих цілей з мінімальною особистою упередженістю.
Світогляд тестувальника та розробника (версія 3.1)
Розробники та тестувальники часто думають по-різному. Основною метою розробки є проєктування та створення продукту. Як обговорювалося раніше, цілі тестування включають верифікацію та валідацію продукту, пошук дефектів до випуску тощо. Це різні набори цілей, які вимагають різного мислення. Поєднання цих уявлень допомагає досягти вищого рівня якості продукції.
Ментальні установки відображають припущення людини та її бажані методи прийняття рішень і вирішення проблем. Світогляд тестувальника має включати цікавість, професійний песимізм, критичний погляд, увагу до деталей і мотивацію до хорошого та позитивного спілкування та стосунків. Менталітет тестувальника має тенденцію зростати та дозрівати в міру того, як тестувальник набуває досвіду.
Менталітет розробника може включати деякі елементи мислення тестувальника, але успішні розробники часто більше зацікавлені в проєктуванні та створенні рішень, ніж у міркуванні про те, що з цими рішеннями може бути не так. Крім того, упередженість підтвердження ускладнює усвідомлення помилок, скоєних ними самими.
З правильним мисленням розробники можуть перевірити власний код. Різні моделі життєвого циклу розробки програмного забезпечення часто мають різні способи організації тестувальників і тестової діяльності. Виконання деяких тестів незалежними тестувальниками підвищує ефективність виявлення дефектів, що особливо важливо для великих, складних або важливих для безпеки систем. Незалежні тестувальники представляють перспективу, яка відрізняється від точки зору авторів робочого продукту (тобто бізнес-аналітиків, власників продуктів, дизайнерів і розробників), оскільки вони мають інші когнітивні упередження, ніж автори.
Загальні навички необхідні для тестування (версія 4.0)
Майстерність – це здатність робити щось добре, що випливає з власних знань, практики та здібностей. Хороші тестувальники повинні володіти деякими основними навичками, щоб добре виконувати свою роботу. Хороші тестувальники повинні бути ефективними гравцями в команді та повинні вміти виконувати тестування на різних рівнях незалежності тестування.
Хоча такі навички є загальними, вони особливо актуальні для тестувальників:
Тестові знання (для підвищення ефективності тестування, наприклад, за допомогою тестових методик)
Ретельність, уважність, допитливість, увага до деталей, методичність (виявляти недоліки, особливо ті, які важко знайти)
Хороші комунікативні навички, активне слухання, бути командним гравцем (ефективно взаємодіяти з усіма зацікавленими сторонами, передавати інформацію іншим, бути зрозумілим, повідомляти та обговорювати недоліки)
Аналітичне мислення, критичне мислення, креативність (для підвищення ефективності тестування)
Технічні знання (для підвищення ефективності тестування, наприклад, за допомогою відповідних інструментів тестування)
Знання домену (щоб розуміти кінцевих користувачів/представників бізнесу та спілкуватися з ними)
Тестувальники часто є носіями поганих новин. Це звичайна людська риса – звинувачувати того, хто приніс погані новини. Це робить комунікативні навички вирішальними для тестувальників. Повідомлення результатів тестування може бути сприйнято як критика продукту та його автора. Упередженість підтвердження може ускладнити прийняття інформації, яка суперечить поточним переконанням. Деякі люди можуть сприймати тестування як деструктивну діяльність, навіть якщо воно значною мірою сприяє успіху проєкту та якості продукції. Щоб спробувати покращити цю точку зору, інформацію про дефекти та невдачі слід передавати конструктивно.
Whole Team Approach (підхід цільної команди) (версія 4.0)
Однією з важливих навичок тестувальника є вміння ефективно працювати в команді та робити позитивний внесок у досягнення командних цілей. Підхід цільної команди – практика, отримана від екстремального програмування – будується на цій навичці.
У підході цільної команди будь-який член команди з необхідними знаннями та навичками може виконати будь-яке завдання, і кожен відповідає за якість. Члени команди спільно використовують той самий робочий простір (фізичний або віртуальний), оскільки спільне розміщення полегшує спілкування та взаємодію. Підхід цільної команди покращує динаміку команди, покращує комунікацію та співпрацю всередині команди та створює синергію, дозволяючи використати різні набори навичок у команді на благо проєкту.
Тестувальники тісно співпрацюють з іншими членами команди, щоб забезпечити досягнення бажаних рівнів якості. Це включає співпрацю з представниками бізнесу, щоб допомогти їм створити відповідні приймальні тести, а також роботу з розробниками для узгодження стратегії тестування та прийняття рішення щодо підходів до автоматизації тестування. Таким чином, тестувальники можуть передавати знання про тестування іншим членам команди та впливати на розробку продукту.
Залежно від контексту підхід усієї команди не завжди може бути доречним. Наприклад, у деяких ситуаціях, таких як критичні для безпеки, може знадобитися високий рівень незалежності тестування.
Independence of Testing (Незалежність тестування) (версія 4.0)
Певний ступінь незалежності робить тестувальника більш ефективним у пошуку дефектів через відмінності між когнітивними упередженнями автора та тестувальника. Проте незалежність не є заміною поінформованості, наприклад, розробники можуть ефективно знаходити багато дефектів у власному коді.
Робочі продукти можуть тестуватися їх автором (немає незалежності), колегами автора з тієї ж команди (певна незалежність), тестувальниками з-за меж команди автора, але всередині організації (висока незалежність), або тестувальниками з-поза організації (дуже висока незалежність). Для більшості проєктів зазвичай найкраще проводити тестування з кількома рівнями незалежності (наприклад, розробники виконують тестування компонентів та інтеграції компонентів, команда тестувальників виконує тестування системи та системної інтеграції, а представники бізнесу виконують приймальне тестування).
Основна перевага незалежності тестування полягає в тому, що незалежні тестувальники, ймовірно, визнають різні види невдач і дефектів порівняно з розробниками через їхню різну історію, технічні перспективи та упередження. Крім того, незалежний тестувальник може перевірити, оскаржити або спростувати припущення, зроблені зацікавленими сторонами під час специфікації та впровадження системи.
Однак є й деякі недоліки. Незалежні тестувальники можуть бути ізольовані від команди розробників, що може призвести до відсутності співпраці, проблем із спілкуванням або ворогуванню із командою розробників. Розробники можуть втратити почуття відповідальності за якість. Незалежних тестувальників можна вважати слабкою ланкою або звинуватити у затримках рілізу.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 1.5.
В цьому відео починаємо працювати з секцією 1.5. 00:00:50 Людська психологія і Тестування 00:10:09 Світогляди тестувальника і розробника 00:18:20 Базові навички необхідні для тестування 00:26:33 Підхід цілісної команди 00:34:00 Незалежність тестування
Немає єдиного універсального процесу тестування програмного забезпечення, але є загальні набори тестових дій, без яких тестування з меншою імовірністю досягне поставлених цілей. Ці набори тестових дій є тестовим процесом. Належний конкретний процес тестування програмного забезпечення в будь-якій ситуації залежить від багатьох факторів. Тестові дії, які задіяні в цьому тестовому процесі, як ці дії реалізуються та коли вони відбуваються, розглядають або документують в стратегії тестування організації.
Тестовий процес (версія 4.0)
Тестування залежить від контексту, але на високому рівні існують загальні набори тестових дій, без яких тестування не досягне своїх цілей. Ці набори тестових дій утворюють процес тестування. Процес тестування можна пристосувати до конкретної ситуації на основі різних факторів. Які заходи тестування включені в цей процес тестування, як вони реалізуються та коли вони відбуваються, зазвичай вирішується в рамках планування тестування для конкретної ситуації.
Контекст тестового процесу (версія 3.1)
Фактори контексту, які впливають на процес тестування для організації, включають, але не обмежуються:
Модель життєвого циклу розробки програмного забезпечення та методології проекту, що використовуються
Рівні та типи тестів, які розглядаються
Продуктові та проєктні ризики
Бізнес домен
Операційні обмеження, включаючи, але не обмежуючись: бюджети та ресурси, часові рамки, складність
Договірні та нормативні вимоги
Організаційна політика та практика
Необхідні внутрішні та зовнішні стандарти
Дуже корисно, якщо тестова основа (для будь-якого рівня або типу тестування, що розглядається) має визначені вимірювані критерії покриття. Критерії покриття можуть ефективно діяти як ключові показники ефективності (KPI) для керування діяльністю, яка демонструє досягнення цілей тестування програмного забезпечення.
Наприклад, для мобільного додатку тестова основа може містити список вимог і список підтримуваних мобільних пристроїв. Кожна вимога є елементом тестової бази. Кожен підтримуваний пристрій також є елементом тестової бази. Критерії охоплення можуть вимагати принаймні одного тестового випадку для кожного елемента тестової основи. Після виконання результати цих тестів повідомляють зацікавленим сторонам, чи виконано визначені вимоги та чи спостерігалися збої на підтримуваних пристроях.
Контекст тестового процесу (версія 4.0)
Тестування не проводиться ізольовано. Тестування є невід’ємною частиною процесів розробки, що здійснюються в організації. Тестування також фінансується зацікавленими сторонами, і його кінцева мета – допомогти задовольнити бізнес-потреби зацікавлених сторін. Таким чином, спосіб проведення тестування залежатиме від ряду контекстуальних факторів, зокрема:
Зацікавлені сторони (потреби, очікування, вимоги, бажання співпрацювати тощо)
Члени команди (навички, знання, рівень досвіду, доступність, потреби в навчанні тощо)
Сфера діяльності (критичність об’єкта тестування, ідентифіковані ризики, потреби ринку, специфічні правові норми тощо)
Технічні фактори (тип програмного забезпечення, архітектура продукту, використовувана технологія тощо)
Обмеження проєкту (обсяг, час, бюджет, ресурси тощо)
Організаційні фактори (організаційна структура, існуюча політика, використовувана практика тощо)
Життєвий цикл розробки програмного забезпечення (технічна практика, методи розробки тощо)
Інструменти (доступність, зручність використання, відповідність тощо)
Ці фактори впливатимуть на багато питань, пов’язаних з тестуванням, зокрема: стратегію тестування, використовувані методи тестування, ступінь автоматизації тестування, необхідний рівень охоплення, рівень деталізації тестової документації, звітності тощо.
Тестові діяльності та завдання (версія 3.1)
Процес тестування складається з таких основних груп дій:
Планування тестування
Тестовий моніторинг і контроль
Тестовий аналіз
Тест дизайн
Реалізація тесту
Виконання тесту
Завершення тесту
Кожна основна група видів діяльності складається зі складових видів діяльності. Кожна складова діяльність складається з кількох окремих завдань, які відрізнятимуться від одного проєкту чи випуску до іншого.
Крім того, хоча багато з цих основних груп діяльності можуть здаватися логічно послідовними, вони часто реалізуються ітеративно. Наприклад, гнучка розробка передбачає невеликі ітерації проєктування, створення та тестування програмного забезпечення, які відбуваються на безперервній основі та підтримуються постійним плануванням. Таким чином, тестування також відбувається на ітераційній, постійній основі в рамках цього підходу до розробки програмного забезпечення. Навіть у послідовній розробці програмного забезпечення ступінчаста логічна послідовність основних груп дій включатиме накладання, поєднання, одночасність або пропуски, тому зазвичай потрібно адаптувати ці основні групи дій у контексті системи та проекту.
Планування тестування
Планування тестування включає дії, які визначають цілі тестування та підхід до досягнення цілей тестування в межах обмежень, накладених контекстом (наприклад, визначення відповідних методів тестування та завдань, а також формулювання розкладу тестування для дотримання кінцевого терміну). Плани тестування можуть бути переглянуті на основі зворотного зв’язку від моніторингу та контролю.
Тестовий моніторинг і контроль
Моніторинг тестування передбачає постійне порівняння фактичного прогресу із запланованим із використанням будь-яких показників моніторингу тестування, визначених у плані тестування. Контроль тестування передбачає виконання дій, необхідних для досягнення цілей плану тестування (який з часом може оновлюватися). Моніторинг і контроль тестування підтримуються оцінкою критеріїв виходу, які в деяких моделях життєвого циклу розробки програмного забезпечення називаються визначенням завершеності. Наприклад, оцінка критеріїв виходу для виконання тесту як частини даного рівня тесту може включати:
Перевірка результатів тестування та журналів відповідно до визначених критеріїв покриття
Оцінка рівня якості компонентів або системи на основі результатів тестування та журналів
Визначення необхідності додаткових тестів (наприклад, якщо тести, спочатку призначені для досягнення певного рівня охоплення ризику продукту, не змогли це зробити, вимагаючи написання та виконання додаткових тестів)
Перебіг тестування щодо плану повідомляється зацікавленим сторонам у звітах про хід тестування, включаючи відхилення від плану та інформацію для підтвердження будь-якого рішення припинити тестування.
Тестовий аналіз
Під час тестового аналізу аналізується тестова база, щоб визначити перевірені функції та визначити відповідні умови тестування. Іншими словами, тестовий аналіз визначає, «що тестувати» з точки зору вимірюваних критеріїв покриття.
Тестовий аналіз включає такі основні дії:
Аналіз тестової бази, що відповідає розглянутому рівню тесту, наприклад:
Специфікації вимог, як-от бізнес-вимоги, функціональні вимоги, системні вимоги, історії користувачів, епіки, випадки використання або подібні робочі продукти, які визначають бажаний функціональний і нефункціональний компонент або поведінку системи
Інформація про проєктування та впровадження, як-от діаграми або документи архітектури системи чи програмного забезпечення, специфікації дизайну, графіки потоку викликів, діаграми моделювання (наприклад, UML або діаграми зв’язків сутностей), специфікації інтерфейсу або подібні робочі продукти, які визначають компонент або структуру системи
Реалізація самого компонента або системи, включаючи код, метадані бази даних і запити, а також інтерфейси
Звіти про аналіз ризиків, які можуть розглядати функціональні, нефункціональні та структурні аспекти компонента або системи
Оцінка тестової бази та тестових елементів для виявлення дефектів різних типів, таких як:
Неоднозначність
Упущення
Невідповідність
Неточність
Протиріччя
Зайві твердження
Ідентифікація функцій і наборів функцій, які необхідно перевірити
Визначення та пріоритезація умов тестування для кожної функції на основі аналізу бази тестування та врахування функціональних, нефункціональних і структурних характеристик, інших бізнес- і технічних факторів і рівнів ризиків
Захоплення двонаправленої простежуваності між кожним елементом основи тестування та пов’язаними умовами тестування
Застосування методів тестування «чорного ящика», «білого ящика» та тестування на основі досвіду може бути корисним у процесі аналізу тестування, щоб зменшити ймовірність пропуску важливих умов тестування та визначити більш точні умови тестування.
У деяких випадках тестовий аналіз створює умови тестування, які слід використовувати як цілі тестування в тестових чартерах. Тестові чартери є типовими продуктами роботи в деяких типах тестування на основі досвіду. Коли ці цілі тестування можна простежити до бази тестування, покриття, досягнуте під час такого тестування на основі досвіду, можна виміряти.
Виявлення дефектів під час тестового аналізу є важливою потенційною перевагою, особливо якщо не використовується інший процес перегляду чи перевірки та/або процес тестування тісно пов’язаний із процесом перегляду чи перевірки. Подібні види діяльності тетстового аналізу не тільки перевіряють, чи вимоги є послідовними, правильно вираженими та повними, але й перевіряють, чи вимоги належним чином охоплюють потреби клієнтів, користувачів та інших зацікавлених сторін. Наприклад, такі методи, як розробка, керована поведінкою (BDD) і розробка, керована приймальними тестами (ATDD), які передбачають створення умов тестування та тестових випадків на основі історій користувачів і критеріїв прийнятності перед кодуванням. Ці методи також перевіряють, підтверджують і виявляють дефекти в історіях користувачів і критеріях прийняття.
Дизайн тесту або проєктування
Під час проєктування тесту умови тестування переробляються у високорівневі тестові випадки, набори високорівневих тестових випадків та інше тестове програмне забезпечення. Отже, аналіз тестів відповідає на питання «що тестувати?» тоді як дизайн тесту відповідає на питання «як тестувати?»
Дизайн тесту включає наступні основні дії:
Розробка та розстановка пріоритетів тестових випадків і наборів тестових випадків
Визначення необхідних тестових даних для підтримки тестових умов і тестових випадків
Розробка тестового середовища та визначення необхідної інфраструктури та інструментів
Документування чи фіксація двосторонньої відстежуваності між основою тестування, умовами тестування та тестовими випадками
Розробка тестових умов у тестові випадки та набори тестових випадків під час розробки тесту часто передбачає використання тестових методів.
Як і аналіз тесту, дизайн тесту також може призвести до виявлення подібних типів дефектів у тестовій основі. Крім того, як і з аналізом тестів, виявлення дефектів під час проектування тесту є важливою потенційною перевагою.
Реалізація тесту або впровадження
Під час впровадження тесту створюється та/або завершується тестове програмне забезпечення, необхідне для виконання тесту, включаючи послідовність тестових випадків у тестові процедури. Отже, дизайн тесту відповідає на питання «як тестувати?» в той час як реалізація тестів відповідає на запитання «чи є у нас усе готове для проведення тестів?»
Реалізація тесту включає такі основні дії:
Розробка та розстановка пріоритетів тестових процедур і, потенційно, створення автоматизованих тестових сценаріїв
Створення наборів тестів із процедур тестування та (за наявності) сценаріїв автоматизованого тестування
Розташування наборів тестів у розкладі виконання тесту таким чином, щоб забезпечити ефективне виконання тесту
Створення тестового середовища (включаючи, потенційно, тестові джгути, віртуалізацію сервісів, симулятори та інші елементи інфраструктури) і перевірку того, що все необхідне налаштовано правильно
Підготовка тестових даних і забезпечення їх належного завантаження в тестове середовище
Перевірка та оновлення двосторонньої відстежуваності між основою тестування, умовами тестування, тестовими випадками, процедурами тестування та наборами тестів
Завдання розробки тесту та виконання тесту часто поєднуються.
У дослідницькому тестуванні та інших типах тестування на основі досвіду розробка та реалізація тесту можуть відбуватися та можуть бути задокументовані як частина виконання тесту. Дослідницьке тестування може ґрунтуватися на тестових чартерах (розроблених як частина аналізу тестування), а дослідницькі тести виконуються негайно після їх розробки та реалізації.
Виконання тесту
Під час виконання тесту набори тестів запускаються відповідно до графіка виконання тесту. Виконання тесту включає наступні основні дії:
Запис ідентифікаторів і версій тестового(их) елемента(ів) або тестового об’єкта, тестового інструмента(ів) і тестового програмного забезпечення
Виконання тестів вручну або за допомогою інструментів виконання тестів
Порівняння фактичних результатів із очікуваними
Аналіз аномалій для встановлення їх ймовірних причин (наприклад, збої можуть виникати через дефекти коду, але також можуть виникати помилкові спрацьовування
Повідомлення про дефекти на основі помічених несправностей
Реєстрація результатів виконання тесту (наприклад, пройдено, не пройдено, заблоковано)
Повторення тестових дій у результаті дій, вжитих для виявлення аномалії, або в рамках запланованого тестування (наприклад, виконання виправленого тесту, тестування на підтвердження та/або регресійне тестування)
Перевірка та оновлення двонаправленої простежуваності між основою тестування, умовами тестування, тестовими випадками, процедурами тестування та результатами тестування.
Завершення тестування
Діяльності завершення тестування збирають дані про завершені дії тестування для консолідації досвіду, тестового програмного забезпечення та будь-якої іншої відповідної інформації. Діяльність із завершення тестування відбувається на етапах проєкту, наприклад, коли випускається програмна система, тестовий проєкт завершено (або скасовано), завершено ітерацію проекту Agile, завершено тестовий рівень або завершено технічне обслуговування.
Завершення тесту включає наступні основні дії:
Перевірка того, чи всі звіти про дефекти закриті, введення запитів на зміни або елементів невиконаних продуктів для будь-яких дефектів, які залишаються невирішеними наприкінці виконання тесту
Створення підсумкового звіту про тестування для інформування зацікавлених сторін
Доопрацювання та архівування тестового середовища, тестових даних, тестової інфраструктури та іншого тестового програмного забезпечення для подальшого повторного використання
Передача тестового програмного забезпечення групам технічного обслуговування, іншим командам проекту та/або іншим зацікавленим сторонам, які можуть отримати користь від його використання
Аналіз уроків, отриманих із завершених тестових дій, щоб визначити зміни, необхідні для майбутніх ітерацій, випусків і проектів
Використання зібраної інформації для вдосконалення процесу тестування
Тестові діяльності та завдання (версія 4.0)
Процес тестування зазвичай складається з основних груп дій, описаних нижче. Незважаючи на те, що багато з цих дій можуть здатися логічними, вони часто виконуються ітеративно або паралельно. Ці дії тестування зазвичай потрібно адаптувати до системи та проєкту:
Планування тестування складається з визначення цілей тестування, а потім вибору підходу, який найкращим чином досягає цілей у межах обмежень, накладених загальним контекстом.
Тестовий моніторинг і контроль. Моніторинг тестування передбачає постійну перевірку всіх тестових дій і порівняння фактичного прогресу з планом. Тестовий контроль передбачає виконання дій, необхідних для досягнення цілей тестування.
Аналіз тестування включає аналіз основи тестування для виявлення функцій, які можна перевірити, а також для визначення пріоритетів пов’язаних умов тестування разом із відповідними ризиками та рівнями ризику. Тест-основа та тест-об’єкти також оцінюються для виявлення дефектів, які вони можуть містити, і для оцінки їх тестування. Тестовий аналіз часто підтримується використанням тестових методик. Аналіз тестів відповідає на питання «що тестувати?» з точки зору вимірних критеріїв покриття.
Розробка тесту включає розробку умов тестування в тестових випадках та іншому тестовому програмному забезпеченні. Ця діяльність часто передбачає ідентифікацію елементів покриття, які служать керівництвом для визначення вхідних даних тестового випадку. Методи тестування можна використовувати для підтримки цієї діяльності. Проєкт тестування також включає визначення вимог до тестових даних, проєктування тестового середовища та визначення будь-якої іншої необхідної інфраструктури та інструментів. Дизайн тесту відповідає на питання «як тестувати?».
Реалізація тесту включає створення або отримання тестового програмного забезпечення, необхідного для виконання тесту (наприклад, тестових даних). Тестові випадки можуть бути організовані в тестові процедури та часто збираються в тестові набори. Створюються ручні та автоматизовані сценарії тестування. Процедури тестування впорядковані за пріоритетами та впорядковані в розкладі виконання тесту для ефективного виконання тесту. Тестове середовище створено та перевірено на правильність налаштування.
Виконання тесту включає виконання тестів відповідно до графіка виконання тесту (тестових прогонів). Виконання тесту може бути ручним або автоматизованим. Виконання тесту може приймати різні форми, включаючи безперервне тестування або сеанси парного тестування. Фактичні результати тесту порівнюються з очікуваними. Результати тестування реєструються. Аномалії аналізуються, щоб визначити їх ймовірні причини. Цей аналіз дозволяє нам повідомляти про аномалії на основі помічених збоїв.
Діяльність із завершення тестування зазвичай відбувається на етапах проєкту (наприклад, випуск, кінець ітерації, завершення рівня тестування) для будь-яких невирішених дефектів, запитів на зміни або створених елементів невиконаного продукту. Будь-яке тестове програмне забезпечення, яке може бути корисним у майбутньому, ідентифікується та архівується або передається відповідним командам. Тестове середовище вимкнено до узгодженого стану. Діяльність тестування аналізується, щоб визначити отримані уроки та вдосконалення для майбутніх ітерацій, випусків або проєктів. Створюється звіт про завершення тестування, який надається зацікавленим сторонам.
Тестові робочі продукти (версія 3.1)
Тестові робочі продукти створюються як частина процесу тестування. Так само, як існують значні відмінності в тому, як організації впроваджують процес тестування, також існують значні відмінності в типах робочих продуктів, створених під час цього процесу, у способах організації та керування цими робочими продуктами, а також у назвах, які використовуються для них продукти праці.
Багато продуктів тестування, описаних у цьому розділі, можна отримувати та керувати ними за допомогою інструментів керування тестами та інструментів керування дефектами.
Робочі продукти тестового планування
Робочі продукти планування тестування зазвичай включають один або кілька планів тестування. План тестування містить інформацію про тестову базу, з якою інші тестові робочі продукти будуть пов’язані через інформацію про відстеження, а також критерії виходу, які використовуватимуться під час моніторингу та контролю тестування.
Робочі продукти тестового моніторингу та контролю
Робочі продукти моніторингу та контролю тестування зазвичай включають різні типи звітів про тестування, включаючи звіти про хід тестування, які створюються на постійній та/або регулярній основі, і підсумкові звіти про тестування, створені на різних етапах завершення. Усі звіти про тестування мають надавати релевантні для аудиторії відомості про хід тестування станом на дату звіту, включаючи узагальнення результатів виконання тесту, щойно вони стануть доступними.
Робочі продукти моніторингу та контролю тестів також повинні вирішувати питання управління проєктом, такі як виконання завдань, розподіл і використання ресурсів, а також зусилля.
Робочі продукти тестового аналізу
Робочі продукти тестового аналізу включають визначені та пріоритезовані умови тестування, кожна з яких ідеально двонаправлено простежується до конкретного елемента (елементів) основи тестування. Для дослідницького тестування аналіз тестів може передбачати створення тестових чартерів. Аналіз тестів також може призвести до виявлення та звітування про дефекти в тестовій основі.
Робочі продукти тестового проєктування
Проєктування тестів відображується у тестових випадках і наборах тестових випадків для виконання умов тестування, визначених у тестовому аналізі. Часто є хорошою практикою розробляти тестові випадки високого рівня без конкретних значень вхідних даних і очікуваних результатів. Такі тестові випадки високого рівня можна повторно використовувати в кількох циклах тестування з різними конкретними даними, при цьому належним чином документуючи обсяг тестового випадку. В ідеалі кожен тестовий приклад можна двонаправлено простежити до тестових умов, які він охоплює.
Дизайн тесту також призводить до:
дизайн та/або ідентифікація необхідних тестових даних
дизайн тестового середовища
визначення інфраструктури та інструментів
Хоча ступінь документування цих результатів значно відрізняється.
Робочі продукти тестового впровадження
Робочі продукти тестового впровадження включають:
Процедури тестування та послідовність цих процедур тестування
Набори тестів
Графік виконання тесту
В ідеалі, після завершення впровадження тесту, досягнення критеріїв охоплення, встановлених у плані тестування, можна продемонструвати через двонаправлену відстежуваність між тестовими процедурами та конкретними елементами бази тестування через тестові випадки та умови тестування.
У деяких випадках реалізація тесту передбачає створення робочих продуктів за допомогою інструментів, таких як віртуалізація служб і сценарії автоматизованого тестування.
Реалізація тесту також може призвести до створення та перевірки тестових даних і тестового середовища. Повнота документації даних та/або результатів перевірки середовища може значно відрізнятися.
Тестові дані служать для призначення конкретних значень вхідним даних і очікуваним результатам тестових випадків. Такі конкретні значення разом із явними вказівками щодо використання конкретних значень перетворюють високорівневі тестові випадки на виконувані низькорівневі тестові випадки. Той самий тестовий приклад високого рівня може використовувати різні тестові дані під час виконання на різних випусках тестового об’єкта. Конкретні очікувані результати, пов’язані з конкретними даними тестування, визначаються за допомогою тестового оракула.
У дослідницькому тестуванні деякі робочі продукти тестування та впровадження можуть бути створені під час виконання тесту, хоча ступінь документування дослідницьких тестів (та їх простежуваність до конкретних елементів бази тестування) може значно відрізнятися.
Умови тестування, визначені в аналізі тесту, можуть бути додатково вдосконалені в реалізації тесту.
Робочі продукти виконання тестування
Продукти виконання тесту включають:
Документація статусу окремих тестових прикладів або тестових процедур (наприклад, готовий до виконання, успішний, невдалий, заблокований, навмисно пропущений тощо)
Звіти про дефекти
Документація про те, який тестовий елемент(и), тестовий(і) об’єкт(и), інструменти тестування та тестове програмне забезпечення були задіяні в тестуванні
В ідеалі, коли виконання тесту завершено, статус кожного елемента бази тестування можна визначити та повідомити через двонаправлену відстежуваність із пов’язаною процедурою(ами) тестування. Наприклад, ми можемо сказати, які вимоги пройшли всі заплановані тести, які вимоги не пройшли тести та/або мають пов’язані з ними дефекти, а які вимоги мають заплановані тести, які ще чекають на виконання. Це дає змогу перевірити відповідність критеріям покриття та звітувати про результати випробувань у термінах, зрозумілих зацікавленим сторонам.
Робочі продукти завершення тестування
Робочі продукти завершення тестування включають підсумкові звіти про тестування, елементи дій для вдосконалення наступних проєктів або ітерацій, запити на зміни або елементи невиконаних продуктів, а також завершене програмне забезпечення для тестування.
Тестові робочі продукти (версія 3.1)
Програмне забезпечення для тестування створюється як вихідний робочий продукт із тестових дій. Існують значні відмінності в тому, як різні організації виробляють, формують, називають, організовують і керують своїми робочими продуктами. Належне керування конфігурацією забезпечує послідовність і цілісність робочих продуктів. Наступний перелік робочих продуктів не є вичерпним:
Робочі продукти з планування тестування включають: план тестування, графік тестування, реєстр ризиків, а також критерії входу та виходу. Реєстр ризиків – це перелік ризиків разом із імовірністю ризику, впливом ризику та інформацією про керування ризикои. Графік випробувань, реєстр ризиків і критерії входу та виходу часто є частиною плану випробувань.
Продукти моніторингу та контролю випробувань включають: звіти про хід випробувань, документацію контрольних директив та інформацію про ризики.
Робочі продукти тестового аналізу включають: (пріоритетизовані) умови тестування (наприклад, критерії прийнятності) і звіти про дефекти щодо дефектів бази тестування (якщо не виправлено безпосередньо).
Продукти розробки тестів включають: (пріоритезовані) тестові випадки, тестові статути, елементи покриття, вимоги до тестових даних і вимоги до тестового середовища.
Робочі продукти впровадження тесту включають: процедури тестування, сценарії автоматизованого тестування, тестові набори, тестові дані, розклад виконання тесту та елементи тестового середовища. Приклади елементів тестового середовища включають: заглушки, драйвери, симулятори та віртуалізацію служб.
Продукти виконання тесту включають: журнали тестування та звіти про дефекти.
Робочі продукти із завершення тестування включають: звіт про завершення тестування, елементи дій для вдосконалення наступних проєктів або ітерацій, задокументовані отримані уроки та запити на зміни (наприклад, як елементи невиконаного продукту).
Відстежуваність (Тестова основа та Тестові робочі продукти) (версія 3.1)
Тестові робочі продукти та назви цих робочих продуктів значно відрізняються. Незалежно від цих варіацій, для впровадження ефективного моніторингу та контролю тестування важливо встановити та підтримувати відстежуваність протягом усього процесу тестування між кожним елементом бази тестування та різними продуктами тестування, пов’язаними з цим елементом, як описано вище. На додаток до оцінки охоплення тестуванням хороша відстежуваність підтримує:
Аналіз впливу змін
Зробити тестування можливим для перевірки
Відповідність критеріям управління ІТ
Покращення зрозумілості звітів про хід тестування та підсумкових звітів про тестування для включення статусу елементів основи тестування (наприклад, вимоги, які пройшли тестування, вимоги, які не пройшли тестування, і вимоги, які мають тести, що очікують на розгляд)
Розповідання технічних аспектів тестування зацікавленим сторонам у зрозумілих для них термінах
Надання інформації для оцінки якості продукту, можливостей процесу та прогресу проєкту щодо бізнес-цілей
Деякі інструменти керування тестами надають моделі тестових робочих продуктів, які відповідають частині або всім тестовим робочим продуктам, описаним у цьому розділі. Деякі організації створюють власні системи управління для організації робочих продуктів і забезпечення відстеження необхідної інформації.
Відстежуваність (Тестова основа та Тестові робочі продукти) (версія 4.0)
Для впровадження ефективного моніторингу та контролю за тестуванням важливо встановити та підтримувати відстежуваність протягом усього процесу тестування між елементами основи тестування, тестовим програмним забезпеченням, пов’язаним із цими елементами (наприклад, умови тестування, ризики, тестові випадки), результатами тестування та виявленими дефекти.
Точна відстежуваність підтримує оцінку охоплення, тому дуже корисно, якщо вимірювані критерії охоплення визначені в тестовій основі. Критерії охоплення можуть функціонувати як ключові показники ефективності для керування діяльністю, яка показує, наскільки досягнуто цілей тесту. Наприклад:
Відстеження тестових випадків до вимог може підтвердити, що вимоги охоплені тестовими випадками.
Простежуваність результатів тестування на ризики можна використовувати для оцінки рівня залишкового ризику в об’єкті тестування.
На додаток до оцінки охоплення хороша відстежуваність дає змогу визначити вплив змін, полегшує перевірку тестів і допомагає відповідати критеріям управління ІТ. Хороша відстежуваність також робить звіти про хід тестування та завершення більш зрозумілими завдяки включенню статусу елементів основи тестування. Це також може допомогти у зрозумілій формі донести технічні аспекти тестування до зацікавлених сторін. Простежуваність надає інформацію для оцінки якості продукції, можливостей процесу та прогресу проекту щодо бізнес-цілей.
Ролі тестування (версія 4.0)
У цьому навчальному плані розглядаються дві основні ролі в тестуванні: роль управління тестуванням і роль тестування. Діяльність і завдання, призначені цим двом ролям, залежать від таких факторів, як контекст проєкту та продукту, навички людей, які виконують ролі, і організація.
Керівник тестування бере на себе загальну відповідальність за процес тестування, команду тестування та керівництво тестовою діяльністю. Роль управління тестуванням головним чином зосереджена на діяльності з планування тестування, моніторингу та контролю тестування та завершення тестування. Спосіб виконання ролі керування тестуванням залежить від контексту. Наприклад, у розробці програмного забезпечення Agile деякі завдання з керування тестуванням можуть виконуватися командою Agile. Завдання, які охоплюють кілька команд або всю організацію, можуть виконувати менеджери тестування поза командою розробників.
Роль виконання тестування бере на себе загальну відповідальність за інженерний (технічний) аспект тестування. Роль виконання тестування в основному зосереджена на аналізі тестів, дизайні тестів, реалізації та виконанні тестів.
Різні люди можуть виконувати ці ролі в різний час. Наприклад, роль керування тестуванням може виконувати керівник групи, менеджер із тестування, менеджер із розробки тощо. Одна особа також може виконувати функції тестування та керування тестуванням одночасно.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 1.4.
В цьому відео починаємо працювати з секцією 1.4. 00:00:50 Процес тестування 00:18:03 Тестові види діяльності та завдання 01:25:29 Тестові робочі продукти 01:50:47 Відстежуваність 02:01:26 Ролі в тестуванні
Протягом останніх 50 років було запропоновано ряд принципів тестування, які пропонують загальні вказівки для всіх тестів.
Тестування показує наявність дефектів, а не їх відсутність (версія 3.1)
Тестування може показати, що дефекти присутні, але не може довести, що дефектів немає. Тестування зменшує ймовірність того, що в програмному забезпеченні залишаться невиявлені дефекти, але навіть якщо дефектів не виявлено, тестування не є доказом правильності.
Тестування показує наявність, а не відсутність дефектів. (версія 4.0)
Тестування може показати наявність дефектів в тестовому об’єкті, але не може довести, що дефектів немає (Buxton 1970). Тестування знижує ймовірність того, що дефекти залишаться невиявленими в об’єкті тестування, але навіть якщо дефектів не буде виявлено, тестування не може підтвердити правильність об’єкта тестування.
Вичерпне тестування неможливе (версія 3.1)
Перевірка всього (всіх комбінацій вхідних даних і попередніх умов) неможлива, за винятком тривіальних випадків. Замість того, щоб намагатися провести вичерпне тестування, слід використовувати аналіз ризиків, методи тестування та пріоритети, щоб зосередити зусилля на тестуванні.
Вичерпне тестування неможливо (версія 4.0)
Перевірити все неможливо, за винятком тривіальних випадків (Manna 1978). Замість того, щоб намагатися провести вичерпне тестування, слід використовувати методи тестування, визначення пріоритетів тестових випадків і тестування на основі ризику, щоб зосередити зусилля на тестуванні.
Раннє тестування економить час і гроші (версія 3.1)
Щоб виявити дефекти на ранній стадії, як статичне, так і динамічне тестування слід починати якомога раніше в життєвому циклі розробки програмного забезпечення. Раннє тестування іноді називають зрушенням вліво. Тестування на ранніх стадіях життєвого циклу розробки програмного забезпечення допомагає зменшити або усунути дорогі зміни.
Раннє тестування економить час і гроші (версія 4.0)
Дефекти, усунуті на ранній стадії процесу, не призведуть до наступних дефектів у похідних робочих продуктах. Вартість якості буде знижена, оскільки пізніше в SDLC виникатиме менше збоїв (Boehm 1981). Щоб виявити дефекти на ранній стадії, статичні та динамічні випробування слід починати якомога раніше.
Дефекти групуються разом (версія 3.1)
Невелика кількість модулів зазвичай містить більшість дефектів, виявлених під час попереднього тестування, або відповідає за більшість операційних збоїв. Прогнозовані кластери дефектів і фактично спостережувані кластери дефектів під час тестування чи експлуатації є важливими вхідними даними для аналізу ризику, який використовується для зосередження зусиль на тестуванні.
Дефекти групуються разом (версія 4.0)
Невелика кількість системних компонентів зазвичай містить більшість виявлених дефектів або відповідальна за більшість операційних збоїв (Enders 1975). Це явище є ілюстрацією принципу Парето. Прогнозовані кластери дефектів і фактичні кластери дефектів, які спостерігаються під час тестування або під час експлуатації, є важливими вхідними даними для тестування на основі ризику.
Остерігайтеся парадоксу пестицидів (версія 3.1)
Якщо одні й ті самі тести повторювати знову і знову, зрештою ці тести більше не виявляють нових дефектів. Для виявлення нових дефектів може знадобитися змінити існуючі тести та тестові дані, а також написати нові тести. Тести більше не ефективні для виявлення дефектів, так само як пестициди через деякий час більше не ефективні для знищення комах. У деяких випадках, наприклад, автоматизоване регресійне тестування, парадокс пестицидів має сприятливий результат, який полягає у відносно невеликій кількості дефектів регресії.
Тести зношуються (версія 4.0)
Якщо ті самі тести повторювати багато разів, вони стають все більш неефективними у виявленні нових дефектів (Beizer 1990). Щоб подолати цей ефект, може знадобитися модифікувати існуючі тести та тестові дані, а також написати нові тести. Однак у деяких випадках повторення тих самих тестів може мати позитивний результат, наприклад, у автоматизованому регресійному тестуванні.
Тестування залежить від контексту (версія 3.1)
Тестування проводиться по-різному в різних контекстах. Наприклад, важливе для безпеки промислове програмне забезпечення тестується інакше, ніж мобільний додаток для електронної комерції. Як інший приклад, тестування в проекті Agile виконується інакше, ніж тестування в проєкті життєвого циклу послідовної розробки програмного забезпечення.
Тестування залежить від контексту (версія 4.0)
Немає єдиного універсального підходу до тестування. Тестування проводиться по-різному в різних контекстах (Kaner 2011).
Відсутність помилок є оманою (версія 3.1)
Деякі організації очікують, що тестувальники зможуть запустити всі можливі тести та знайти всі можливі дефекти, але принципи 2 і 1, відповідно, говорять нам, що це неможливо. Крім того, помилково очікувати, що лише пошук і виправлення великої кількості дефектів забезпечить успіх системи. Наприклад, ретельне тестування всіх визначених вимог і усунення всіх виявлених дефектів все одно може призвести до створення системи, якою важко користуватися, яка не відповідає потребам і очікуванням користувачів або яка поступається іншим системам-конкурентам.
Помилка про відсутність дефектів (версія 4.0)
Очікувати, що перевірка програмного забезпечення забезпечить успішну роботу системи, є помилкою (тобто помилковим уявленням). Ретельне тестування всіх зазначених вимог і усунення всіх виявлених дефектів все одно може призвести до створення системи, яка не відповідає потребам і очікуванням користувачів, яка не сприяє досягненню бізнес-цілей замовника та є гіршою порівняно з іншими системами-конкурентами. На додаток до верифікації також має бути проведена перевірка (Boehm 1981).
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 1.3.
В цьому відео починаємо працювати з секцією 1.3. 00:00 Сім принципів тестування 00:16 Тестування демонструє присутність дефектів; Вичерпне тестування неможливе 04:29 Раннє тестування; Кластеризація дефектів 09:44 Парадокс пестициду; Тестування залежить від контексту 14:41 Відсутність помилок є фікцією
Продовжуємо опрацьовувати сілабус, секцію 1.2, а саме:
важливість тестування; внесок тестування в успіх проєкту
Quality Assurance (підтвердження якості) та тестування
Помилки, Дефекти та Збої
Дефекти, Кореневі причини та Вплив
Чому тестування є важливим? (версія 3.1)
Ретельне тестування компонентів і систем, а також пов’язаної з ними документації може допомогти зменшити ризик збоїв, що виникають під час експлуатації.
Коли дефекти виявлені та згодом усунені, це сприяє підвищенню якості компонентів або систем. Крім того, тестування програмного забезпечення також може знадобитися для відповідності договірним або юридичним вимогам або галузевим стандартам.
Чому тестування є важливим? (версія 4.0)
Тестування, як форма контролю якості, допомагає досягти узгоджених цілей у межах встановленого обсягу, часу, якості та бюджету. Внесок тестування в успіх не повинен обмежуватися діяльністю тестової групи. Будь-яка зацікавлена сторона може використати свої навички тестування, щоб наблизити проєкт до успіху. Тестування компонентів, систем і відповідної документації допомагає виявити дефекти програмного забезпечення.
Внесок тестування в упіх проєкту (версія 3.1)
Протягом всієї історії обчислювальної техніки досить часто програмне забезпечення та системи вводилися в експлуатацію та, через наявність дефектів, згодом викликали збої або іншим чином не відповідали потребам зацікавлених сторін. Однак використання відповідних методів тестування може зменшити частоту таких проблемних випусків програмних продуктів, якщо ці методи застосовуються з належним рівнем досвіду тестування, на відповідних рівнях тестування та у відповідних точках життєвого циклу розробки програмного забезпечення.
Приклади:
Залучення тестувальників до перегляду вимог або вдосконалення історії користувача може виявити дефекти в цих робочих продуктах. Виявлення та усунення дефектів вимог зменшує ризик розробки неправильних функцій або функцій, які неможливо протестувати.
Якщо тестувальники тісно співпрацюють із системними архітекторами або дизайнерами під час проектування системи, це може покращити розуміння кожною стороною архітектури або дизайну та способів його тестування. Це покращене розуміння може зменшити ризик фундаментальних дефектів архітектури та дозволить виявити тести на ранній стадії.
Тісна співпраця тестувальників із розробниками під час розробки коду може покращити розуміння коду кожною стороною та способів його тестування. Це покращене розуміння може зменшити ризик дефектів у коді та тестах.
Тестери верифікують і валідують програмне забезпечення перед випуском, щоб виявити збої, які інакше могли б бути пропущені, і підтримати процес усунення дефектів, які викликали збої (тобто, налагодження – дебаг). Це підвищує ймовірність того, що програмне забезпечення буде відповідати потребам зацікавлених сторін і вимогам.
На додачу до цих прикладів, досягнення визначених цілей тестування сприяє загальному успіху розробки та обслуговування програмного забезпечення.
Внесок тестування в успіх проєкту (версія 4.0)
Тестування є економічно ефективним засобом виявлення дефектів. Потім ці дефекти можна усунути (шляхом налагодження – нетестової діяльності), тому тестування опосередковано сприяє підвищенню якості тестових об’єктів.
Тестування забезпечує засоби безпосередньої оцінки якості тестового об’єкта на різних етапах SDLC (циклу розробки програмного забезпечення). Ці заходи використовуються як частина більшої діяльності з управління проєктом, сприяючи прийняттю рішень щодо переходу до наступного етапу SDLC, наприклад рішення про випуск.
Тестування надає користувачам непряме уявлення про проєкт розробки. Тестувальники гарантують, що їхнє розуміння потреб користувачів враховується протягом життєвого циклу розробки. Альтернативою є залучення репрезентативного набору користувачів до проєкту розробки, що зазвичай неможливо через високі витрати та відсутність відповідних користувачів. Тестування також може знадобитися для виконання договірних або юридичних вимог або для відповідності нормативним стандартам.
Quality Assurance та тестування (версія 3.1)
Хоча люди часто використовують фразу забезпечення чи підтвердження якості (Quality Assurance) для позначення тестування, забезпечення якості та тестування не те саме, але вони пов’язані. Їх об’єднує ширша концепція – управління якістю. Управління якістю включає всі види діяльності, які спрямовують і контролюють організацію щодо якості.
Серед інших видів діяльності управління якістю включає як забезпечення, так і контроль якості. Забезпечення якості, як правило, зосереджено на дотриманні належних процесів, щоб забезпечити впевненість у тому, що відповідні рівні якості будуть досягнуті. Коли процеси виконуються належним чином, робочі продукти, створені цими процесами, як правило, мають вищу якість, що сприяє запобіганню дефектів. Крім того, використання аналізу першопричин для виявлення та усунення причин дефектів разом із належним застосуванням висновків ретроспективних зустрічей для покращення процесів є важливим для ефективного забезпечення якості.
Контроль якості включає різноманітні види діяльності, у тому числі тестування, які підтримують досягнення відповідних рівнів якості. Тестування є частиною загального процесу розробки або обслуговування програмного забезпечення. Оскільки забезпечення якості стосується належного виконання всього процесу, забезпечення якості підтримує належне тестування. Тестування сприяє досягненню якості різними способами.
Quality Assurance та тестування (версія 4.0)
Хоча люди часто використовують терміни «тестування» та «забезпечення якості» (QA) як синоніми, тестування та QA – це не одне й те саме. Тестування є формою контролю якості (Quality Control).
Контроль якості – це орієнтований на продукт коригувальний підхід, який зосереджується на тих видах діяльності, які підтримують досягнення відповідних рівнів якості. Тестування є основною формою контролю якості, тоді як інші включають формальні методи (перевірка моделі та підтвердження правильності), моделювання та прототипування.
Забезпечення якості (QA) – це процесно-орієнтований превентивний підхід, який зосереджується на впровадженні та вдосконаленні процесів. Це працює на основі того, що якщо хороший процес виконується правильно, він створить хороший продукт. Контроль якості стосується як процесу розробки, так і тестування, і є відповідальністю кожного учасника проєкту.
Результати тестування використовуються QA та QC. У QC вони використовуються для усунення дефектів, тоді як у QA вони забезпечують зворотній зв’язок про те, наскільки добре виконуються процеси розробки та тестування.
Помилки, Дефекти та Збої (версія 3.1)
Людина може зробити помилку, яка може призвести до появи дефекту у програмному коді або в іншому пов’язаному робочому продукті. Помилка, яка призводить до появи дефекту в одному робочому продукті, може викликати помилку, яка призводить до виникнення дефекту в пов’язаному робочому продукті. Наприклад, помилка виявлення вимог може призвести до дефекту вимог, що потім призводить до помилки програмування, яка призводить до дефекту коду.
Якщо код виконується з дефектом, це може спричинити збій, але не обов’язково за всіх обставин. Наприклад, деякі дефекти вимагають дуже конкретних вхідних даних або попередніх умов, щоб викликати збій, який може відбуватися рідко або ніколи.
Помилки можуть виникати з багатьох причин, наприклад:
Тиск часу
Схильність людей до помилок
Недосвідчені або недостатньо кваліфіковані учасники проєкту
Непорозуміння між учасниками проєкту, в тому числі нерозуміння вимог і дизайну
Складність коду, дизайну, архітектури, основної проблеми, яку потрібно вирішити, та/або використовуваних технологій
Непорозуміння щодо внутрішньосистемних і міжсистемних інтерфейсів, особливо коли таких внутрішньосистемних і міжсистемних взаємодій велика кількість
Нові, незнайомі технології
Окрім збоїв, спричинених дефектами коду, збої також можуть бути спричинені умовами навколишнього середовища. Наприклад, радіація, електромагнітні поля та забруднення можуть спричинити дефекти вбудованого програмного забезпечення або вплинути на виконання програмного забезпечення, змінюючи стан обладнання.
Не всі несподівані результати тестування є невдалими. Помилкові спрацьовування можуть виникнути через помилки у способі виконання тестів або через дефекти тестових даних, тестового середовища чи іншого тестового програмного забезпечення, або з інших причин. помилкові спрацьовування повідомляються як дефекти, але насправді не є дефектами.
Може виникнути й зворотна ситуація, коли подібні помилки чи дефекти призводять до хибно негативних результатів. Хибнонегативні – це тести, які не виявляють дефектів, які вони мали б виявити.
Дефекти, Кореневі причини та Вплив (версія 3.1)
Кореневими причинами дефектів є перші дії або умови, які сприяли виникненню дефектів. Дефекти можна проаналізувати, щоб визначити їх першопричину, щоб зменшити кількість подібних дефектів у майбутньому. Зосереджуючись на найважливіших першопричинах, аналіз першопричин може призвести до вдосконалення процесу, що запобігає появі значної кількості майбутніх дефектів.
Наприклад, припустімо, що неправильні виплати відсотків через один рядок неправильного коду призводять до скарг клієнтів. Несправний код був написаний для історії користувача, яка була неоднозначною через неправильне розуміння власником продукту того, як розраховувати відсотки. Якщо в розрахунках відсотків існує велика частина дефектів, і ці дефекти мають свою першопричину в подібних непорозуміннях, власники продукту можуть пройти навчання з теми розрахунків відсотків, щоб зменшити кількість таких дефектів у майбутньому.
У цьому прикладі скарги клієнтів є наслідками. Неправильні виплати відсотків є збоями. Неправильний розрахунок у коді є дефектом, і він став результатом оригінального дефекту, неоднозначності в історії користувача. Основною причиною початкового дефекту був брак знань з боку власника продукту, що призвело до того, що власник продукту зробив помилку під час написання історії користувача.
Дефекти, Кореневі причини та Вплив (версія 4.0)
Люди роблять помилки (помилки), які породжують дефекти (несправності), які, у свою чергу, можуть призвести до збоїв. Люди роблять помилки з різних причин, таких як нестача часу, складність робочих продуктів, процесів, інфраструктури чи взаємодії, або просто тому, що вони втомилися чи не мають належного навчання.
Дефекти можна знайти в документації, такій як специфікація вимог або тестовий сценарій, у вихідному коді або в супровідному артефакті, наприклад у файлі збірки. Дефекти в артефактах, створених раніше в SDLC, якщо їх не виявити, часто призводять до дефектних артефактів пізніше в життєвому циклі. Якщо код виконується з дефектом, система може не виконувати те, що повинна робити, або робити те, чого вона не повинна робити, що спричинить збій. Деякі дефекти завжди призведуть до збою, якщо їх виконати, тоді як інші призведуть до збою лише за певних обставин, а деякі можуть ніколи не призвести до збою.
Помилки і дефекти – не єдина причина збоїв. Збої також можуть бути спричинені умовами навколишнього середовища, наприклад, коли радіація або електромагнітне поле спричиняють дефекти мікропрограми.
Коренева причина – це основна причина виникнення проблеми (наприклад, ситуація, яка призводить до помилки). Основні причини визначають за допомогою аналізу першопричин, який зазвичай виконується, коли виникає збій або виявляється дефект. Вважається, що можна запобігти подальшим подібним збоям або дефектам або зменшити їх частоту шляхом усунення першопричини, наприклад, її усунення.
В цьому відео починаємо працювати з секцією 1.2. 01:09 Чому тестування є важливим? 04:25 Внесок тестування в успіх проєкту 13:30 Quality Assurance (Підтвердження тестування) та тестування 23:05 Помилки, Дефекти та Збої 33:28 Дефекти, Кореневі причини та Вплив
Починаємо опрацьовувати сілабус. Розглянемо що таке тестування, типові цілі тестування, тестування і дебаг.
Що таке тестування?
Програми, програмні системи є невід’ємною частиною життя, від бізнес-додатків (наприклад, банківська справа) до споживчих продуктів (наприклад, автомобілі). Більшість людей стикалися з програмним забезпеченням, яке не працювало належним чином. Програмне забезпечення, яке не працює належним чином, може призвести до багатьох проблем, у тому числі до втрати грошей, часу чи ділової репутації, і навіть до травм чи смерті. Тестування програмного забезпечення – це спосіб оцінити якість програмного забезпечення та знизити ризик збою в роботі програмного забезпечення.
Тестування ПЗ – це набір видів діяльності щоб знайти дефекти та оцінити якість програмних артефактів. Ці артефакти, коли тестуються, стають тестовими об’єктами.Поширене неправильне сприйняття тестування полягає в тому, що воно складається лише з запуску тестів, тобто перевірці функціонування програмного забезпечення та результатів його роботи. Насправді, тестування програмного забезпечення – це процес, який включає багато різних стадій; виконання тесту (включаючи перевірку результатів) є лише одним із цих видів діяльності. Процес тестування також включає такі стадії, як планування тестування, аналіз, проектування та впровадження тестів, звітування про хід і результати тестування, а також оцінка якості об’єкта тестування.
Тестування може включати запуск на виконання компонента або системи, що тестується; таке тестування називається динамічним. Інше тестування не передбачає виконання компонента або системи, що тестується; таке тестування називається статичним тестуванням. Отже, тестування також включає перевірку робочих продуктів, таких як вимоги, історії користувачів і вихідний код.
Інше поширене неправильне сприйняття тестування полягає в тому, що воно повністю зосереджено на перевірці вимог, історій користувачів чи інших специфікацій. Хоча тестування включає перевірку відповідності системи визначеним вимогам, воно також передбачає валідацію, яка перевіряє, чи відповідатиме система потребам користувачів та інших зацікавлених сторін у своєму робочому середовищі.
І звісно, що тестування організовується та виконується по-різному в різних життєвих циклах розробки.
Тестування не є виключно технічною діяльністю. .Воно також потребує належного планування, керування, моніторингу і контролю.
Тестувальники використовують інструменти,але важливо пам’ятати, що тестування є інтелектуальною діяльністю, що потребує від тестувальників наявності спеціалізованих знань, використання аналітичних навичок, а також застосовувати критичне та системне мислення.
Типові цілі тестування
Для будь-якого конкретного проекту цілі тестування можуть включати (версія 3.1):
Запобігти дефектам, оцінити робочі продукти, такі як вимоги, історії користувачів, дизайн і код
Перевірити, чи виконано всі зазначені вимоги
Перевірити, чи тестовий об’єкт закінчений, і перевірити, чи він працює так, як очікують користувачі та інші зацікавлені сторони
Сформувати впевненість у рівні якості об’єкта тестування
Знаходити дефекти та збої, знижуючи рівень ризику неналежної якості програмного забезпечення
Надавати зацікавленим сторонам достатньо інформації, щоб вони могли приймати обґрунтовані рішення, особливо щодо рівня якості об’єкта тестування
Дотримання договірних, правових або нормативних вимог або стандартів та/або для перевірки відповідності об’єкта випробувань таким вимогам або стандартам
Типовими цілями тестування є (версія 4.0):
Оцінка робочих продуктів, таких як вимоги, історії користувачів, проекти та код
Ініціювання збоїв і виявлення дефектів
Забезпечення необхідного покриття об’єкта тестування
Зниження рівня ризику неналежної якості програмного забезпечення
Перевірка виконання визначених вимог
Перевірка того, що тестовий об’єкт відповідає договірним, правовим і нормативним вимогам
Надання інформації зацікавленим сторонам, щоб вони могли приймати обґрунтовані рішення
Формування впевненості в якості об’єкта тестування
Перевірка того, чи тестовий об’єкт завершений і чи працює, як очікують зацікавлені сторони
Цілі тестування можуть відрізнятися залежно від контексту компонента, який тестується чи системи, рівня тестування та моделі життєвого циклу розробки програмного забезпечення. Ці відмінності можуть включати, наприклад:
Під час тестування компонентів однією з цілей може бути виявлення якомога більшої кількості збоїв, щоб завчасно виявити та усунути основні дефекти. Іншою метою може бути збільшення охоплення коду компонентних тестів.
Під час приймального тестування однією з цілей може бути підтвердження того, що система працює належним чином і задовольняє вимоги. Ще однією метою цього тестування може бути надання інформації зацікавленим сторонам про ризик випуску системи в певний час.
Тестування і дебаг (налагодження) (версія 3.1)
Тестування та налагодження різні або нетотожні. Виконання тестів може виявити збої, спричинені дефектами програмного забезпечення. Налагодження — це частина розробки, яка знаходить, аналізує та виправляє такі дефекти. Подальше тестування підтвердження перевіряє, чи виправлення усунули дефекти. У деяких випадках тестувальники несуть відповідальність за початковий тест і остаточний тест підтвердження, тоді як розробники виконують налагодження, пов’язані компоненти та тестування інтеграції компонентів. Однак у розробці Agile та в деяких інших життєвих циклах розробки програмного забезпечення тестувальники можуть брати участь у налагодженні та тестуванні компонентів.
Стандарт ISO (ISO/IEC/IEEE 29119-1) містить додаткову інформацію про концепції тестування програмного забезпечення.
Тестування і дебаг (налагодження) (версія 4.0)
Тестування та налагодження є окремими видами діяльності. Тестування може викликати збої, спричинені дефектами програмного забезпечення (динамічне тестування), або безпосередньо знаходити дефекти в тестовому об’єкті (статичне тестування).
Коли динамічне тестування викликає збій, налагодження стосується пошуку причин цього збою (дефектів), аналізу цих причин та їх усунення. Типовий процес налагодження в цьому випадку включає:
Відтворення невдачі
Діагностика (виявлення першопричини)
Усунення причини
Подальше тестування підтвердження (confirmation testing) перевіряє, чи виправлення вирішили проблему. Бажано, щоб підтверджувальне тестування проводилося тією ж особою, яка проводила початковий тест. Також можна виконати наступне регресійне тестування, щоб перевірити, чи виправлення спричиняють збої в інших частинах тестового об’єкта.
Коли статичне тестування визначає дефект, налагодження спрямоване на його усунення. Немає потреби у відтворенні чи діагностиці, оскільки статичне тестування безпосередньо виявляє дефекти і не може викликати збої.
В цьому відео починаємо працювати з секцією 1.1. 02:35 Що таке тестування? 14:45 Типові цілі тестування 24:09 Тестування і дебаг