Gennadii_M 17 березня 2016 в 14:52

Тестування. Фундаментальна теорія

Тестування IT-систем

Tutorial

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

Нижче основи основ для повторення перед співбесідою для Trainee and Junior: визначення тестування, якість, верифікація/валідація, цілі, етапи, тест план, пункти тест плану, тест дизайн, техніки тест дизайну, traceability matrix, test case, чек-лист, дефект, error/deffect/failure, баг репорт, severity vs priority, рівні тестування, види / типи, підходи до інтеграційного тестування, принципи тестування, статичне та динамічне тестування, дослідницьке / ad-hoc тестування, вимоги, життєвий цикл бага, стадії розробки програмного забезпечення, decision table, qa/qc/test engineer, діаграма зв'язків.

Всі зауваження, коригування та доповнення дуже вітаються.

Тестування програмного забезпечення- перевірка відповідності між реальною та очікуваною поведінкою програми, що здійснюється на кінцевому наборі тестів, обраному певним чином. У більш широкому значенні, Тестування - це одна з технік контролю якості, що включає в себе активності з планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) та аналізу отриманих результатів (Test Analysis).

Якість програмного забезпечення (Software Quality)- це сукупність параметрів програмного забезпечення, які належать до його здатності задовольняти встановлені та передбачувані потреби.

Верифікація (verification)- це процес оцінки системи або її компонентів з метою визначення, чи задовольняють результати поточного етапу розробки умов, сформованих на початку цього етапу. Тобто. чи виконуються наші цілі, терміни, завдання розробки проекту, визначені на початку поточної фази.
Валідація (validation)- це визначення відповідності розроблюваного ПЗ очікуванням та потребам користувача, вимогам до системи.
Також можна зустріти іншу інтерпретацію:
Процес оцінки відповідності продукту явним вимогам (специфікаціям) і є верифікація (verification), водночас оцінка відповідності продукту очікуванням та вимогам користувачів є валідація (validation). Також часто можна зустріти таке визначення цих понять:
Validation - 'is this the right specification?'.
Verification - 'is the system correct to specification?'.

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

Етапи тестування:
1. Аналіз продукту
2. Робота з вимогами
3. Розробка стратегії тестування
та планування процедур контролю якості
4. Створення тестової документації
5. Тестування прототипу
6. Основне тестування
7. Стабілізація
8. Експлуатація

Тест план (Test Plan)- це документ, що описує весь обсяг робіт із тестування, починаючи з опису об'єкта, стратегії, розкладу, критеріїв початку та закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.
Відповідає на запитання:
Що треба випробувати?
Що тестуватимете?
Як тестуватимете?
Коли тестуватимете?
Критерії початку тестування.
Критерії закінчення тестування.

Основні пункти тест плану
У стандарті IEEE 829 перераховані пункти, з яких повинен (нехай може) складатися тест-план:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Економічні потреби;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн– це етап процесу тестування ПЗ, на якому проектуються та створюються тестові сценарії (тест кейси), відповідно до визначених раніше критеріїв якості та цілей тестування.
Ролі, відповідальні за тест дизайн:
Тест аналітик – визначає «ЩО тестувати?»
Тест дизайнер – визначає «ЯК тестувати?»

Техніки тест дизайну

Еквівалентний Поділ (Equivalence Partitioning – EP). Як приклад, у вас є діапазон допустимих значень від 1 до 10, ви повинні вибрати одне правильне значення всередині інтервалу, скажімо, 5, і одне неправильне значення поза інтервалом - 0.

Аналіз Граничних Значень (Boundary Value Analysis – BVA).Якщо взяти приклад вище, як значення для позитивного тестування виберемо мінімальну і максимальну межі (1 і 10), і значення більше і менше меж (0 і 11). Аналіз Граничний значень може бути застосований до полів, записів, файлів, або до будь-яких сутностей, що мають обмеження.

Причина/Слідство (Cause/Effect - CE).Це, як правило, введення комбінацій умов (причин) для отримання відповіді від системи (Слідство). Наприклад, ви перевіряєте можливість додавати клієнта, використовуючи певну екранну форму. Для цього вам необхідно буде ввести кілька полів, таких як «Ім'я», «Адреса», «Номер Телефону», а потім натиснути кнопку «Додати» - це «Причина». Після натискання кнопки «Додати» система додає клієнта в базу даних і показує його номер на екрані - це «Слідство».

Передбачення помилки (Error Guessing – EG).Це коли тестувальник використовує свої знання системи та здатність до інтерпретації специфікації щодо того, щоб «передбачити» за яких вхідних умов система може видати помилку. Наприклад, специфікація каже: "користувач повинен ввести код". Тестувальник думатиме: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код? ", і так далі. Це і є передбачання помилки.

Вичерпне тестування (Exhaustive Testing – ET)- Це крайній випадок. У межах цієї техніки ви повинні перевірити всі можливі комбінації вхідних значень, і в принципі це має знайти всі проблеми. Насправді застосування цього методу неможливо, через велику кількість вхідних значень.

Попарне тестування (Pairwise Testing)- Це техніка формування наборів тестових даних. Сформулювати суть можна, наприклад, ось так: формування таких наборів даних, в яких кожне тестоване значення кожного з параметрів, що перевіряються хоча б один раз поєднується з кожним тестованим значенням всіх інших параметрів, що перевіряються.

Допустимо, якесь значень (податок) для людини розраховується на підставі її статі, віку та наявності дітей – отримуємо три вхідні параметри, для кожного з яких для тестів вибираємо якимось чином значення. Наприклад: стать - чоловіча або жіноча; вік – до 25, від 25 до 60, понад 60; наявність дітей – так чи ні. Для перевірки правильності розрахунків можна, звичайно, перебрати всі комбінації значень усіх параметрів:

№	підлога	вік	діти
1	чоловік	до 25	дітей немає
2	жінка	до 25	дітей немає
3	чоловік	25-60	дітей немає
4	жінка	25-60	дітей немає
5	чоловік	старше 60	дітей немає
6	жінка	старше 60	дітей немає
7	чоловік	до 25	діти є
8	жінка	до 25	діти є
9	чоловік	25-60	діти є
10	жінка	25-60	діти є
11	чоловік	старше 60	діти є
12	жінка	старше 60	діти є

А можна вирішити, що нам не потрібні поєднання значень всіх параметрів з усіма, а ми хочемо лише переконатися, що ми перевіримо всі унікальні пари значень параметрів. Тобто, наприклад, з точки зору параметрів статі та віку ми хочемо переконатися, що ми точно перевіримо чоловіка до 25, чоловіка між 25 і 60, чоловіка після 60, а також жінку до 25, жінку між 25 та 60, ну і жінку після 60. І так само для всіх інших пар параметрів. І таким чином, ми можемо отримати набагато менше наборів значень (у них є всі пари значень, щоправда, деякі двічі):

№	підлога	вік	діти
1	чоловік	до 25	дітей немає
2	жінка	до 25	діти є
3	чоловік	25-60	діти є
4	жінка	25-60	дітей немає
5	чоловік	старше 60	дітей немає
6	жінка	старше 60	діти є

Такий підхід приблизно і становить суть техніки pairwise testing - ми не перевіряємо всі поєднання всіх значень, але перевіряємо всі пари значень.

Traceability matrix - Матриця відповідності вимогам- це двовимірна таблиця, що містить відповідність функціональних вимог (functional requirements) продукту та підготовлених тестових сценаріїв (test cases). У заголовках колонок таблиці розташовані вимоги, а заголовках рядків - тестові сценарії. На перетині - відмітка, що означає, що вимога поточної колонки покрита тестовим сценарієм поточного рядка.
Матриця відповідності вимог використовується QA-інженерами для валідації покриття продукту тестами. МСТ є невід'ємною частиною тест-плану.

Тестовий сценарій (Test Case)- це артефакт, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації функції або її частини, що тестується.
Приклад:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Кожен тест кейс повинен мати 3 частини:
PreConditions Список дій, які призводять систему до стану придатного для проведення основної перевірки. Або перелік умов, виконання яких свідчить, що система перебуває у придатному щодо основного тесту стану.
Test Case Description Список дій, що переводять систему з одного стану в інший, для отримання результату, на підставі якого можна зробити висновок про задоволення реалізації, поставленим вимогам
PostConditions Список дій, що переводять систему в початковий стан (стан до проведення тесту - initial state)
Види Тестових Сценаріїв:
Тест кейси поділяються за очікуваним результатом на позитивні та негативні:
Позитивний тест кейс використовує тільки коректні дані і перевіряє, що програма правильно виконала функцію, що викликається.
Негативний тесткейс оперує як коректними так і некоректними даними (мінімум 1 некоректний параметр) і ставить за мету перевірку виняткових ситуацій (спрацьовування валідаторів), а також перевіряє, що функція, що викликається додатком, не виконується при спрацьовуванні валідатора.

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

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

Error- Помилка користувача, тобто він намагається використовувати програму іншим способом.
Приклад - вводить літери на поля, де потрібно вводити цифри (вік, кількість товару тощо.).
У якісній програмі передбачені такі ситуації та видаються повідомлення про помилку (error message), з червоним хрестиком.
Bug (дефект)- Помилка програміста (або дизайнера або ще кого, хто бере участь у розробці), тобто коли в програмі щось йде не так як планувалося і програма виходить з-під контролю. Наприклад, коли ніяк не контролюється введення користувача, в результаті невірні дані викликають краші або інші "радості" у роботі програми. Або всередині програма побудована отже спочатку відповідає тому, що від неї очікується.
Failure- збій (причому не обов'язково апаратний) у роботі компонента, всієї програми чи системи. Тобто є такі дефекти, які призводять до збоїв (A defect caused the failure) і існують такі, які не призводять. UI-дефекти, наприклад. Але апаратний збій, що ніяк не пов'язаний із software, теж є failure.

Баг Репорт (Bug Report)- це документ, що описує ситуацію або послідовність дій, що призвела до некоректної роботи об'єкта тестування, із зазначенням причин та очікуваного результату.
Шапка
Короткий опис (Summary) Короткий опис проблеми, що явно вказує на причину та тип помилкової ситуації.
Проект (Project) Назва проекту, що тестується
Компонент програми (Component) Назва частини або функції продукту, що тестується
Номер версії (Version) Версія на якій було знайдено помилку
Серйозність (Severity) Найбільш поширена п'ятирівнева система градації серйозності дефекту:
S1 Блокуючий (Blocker)
S2 Критичний (Critical)
S3 Значний (Major)
S4 Незначний (Minor)
S5 Тривіальний (Trivial)
Пріоритет (Priority) Пріоритет дефекту:
P1 Високий (High)
P2 Середній (Medium)
P3 Низький (Low)
Статус (Status) Статус бага. Залежить від процедури та життєвого циклу бага (bug workflow and life cycle)

Автор (Author) Творець баг репорту
Призначений на (Assigned To) Ім'я співробітника, призначеного для вирішення проблеми
Оточення
ОС/Сервіс Пак і т.д. / Браузера + версія / ... Інформація про оточення, на якому було знайдено баг: операційна система, сервіс пак, для WEB тестування - ім'я та версія браузера і т.д.
…
Опис
Кроки відтворення (Steps to Reproduce) Кроки, якими можна легко відтворити ситуацію, що призвела до помилки.
Фактичний Результат (Result) Результат, отриманий після проходження кроків до відтворення
Очікуваний результат (Expected Result) Очікуваний правильний результат
Доповнення
Прикріплений файл (Attachment) Файл з логами, скріншот або будь-який інший документ, який може допомогти прояснити причину помилки або вказати на спосіб вирішення проблеми

Severity vs Priority
Серйозність (Severity) – це атрибут, що характеризує вплив дефекту на працездатність програми.
Пріоритет (Priority) - це атрибут, що вказує на черговість виконання завдання чи усунення дефекту. Можна сміливо сказати, що це інструмент менеджера з планування робіт. Що пріоритет, то швидше потрібно виправити дефект.
Severity виставляється тестувальником
Priority – менеджером, тимлідом чи замовником

Градація Серйозності дефекту (Severity)

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

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

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

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

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

Градація Пріоритету дефекту (Priority)
P1 Високий (High)
Помилка має бути виправлена якнайшвидше, т.к. її наявність є критичною для проекту.
P2 Середній (Medium)
Помилка має бути виправлена, її наявність не критична, але вимагає обов'язкового рішення.
P3 Низький (Low)
Помилка має бути виправлена, її наявність не критична, і не вимагає термінового рішення.

Рівні Тестування

1. Модульне тестування (Unit Testing)
Компонентне (модульне) тестування перевіряє функціональність та шукає дефекти в частинах програми, які доступні та можуть бути протестовані окремо (модулі програм, об'єкти, класи, функції тощо).

2. Інтеграційне тестування (Integration Testing)
Перевіряють взаємодію між компонентами системи після проведення компонентного тестування.

3. Системне тестування (System Testing)
Основним завданням системного тестування є перевірка як функціональних, і функціональних вимог у системі загалом. При цьому виявляються дефекти, такі як неправильне використання ресурсів системи, непередбачені комбінації даних рівня користувача, несумісність з оточенням, непередбачені сценарії використання, відсутня або неправильна функціональність, незручність використання і т.д.

4. Операційне тестування (Release Testing).
Навіть якщо система задовольняє всім вимогам, важливо переконатися в тому, що вона задовольняє потреб користувача і виконує свою роль у середовищі своєї експлуатації, як це було визначено у бізнес-моделі системи. Слід врахувати, що бізнес модель може містити помилки. Тому важливо провести операційне тестування як фінальний крок валідації. Крім цього, тестування в середовищі експлуатації дозволяє виявити і нефункціональні проблеми, такі як: конфлікт з іншими системами, суміжними в галузі бізнесу або програмних та електронних оточення; недостатня продуктивність системи серед експлуатації та інших. Вочевидь, що перебування подібних речей на стадії впровадження - критична і дорога проблема. Тому так важливим є проведення не тільки верифікації, а й валідації, з самих ранніх етапіврозробки ПЗ.

5. Приймальне тестування (Acceptance Testing)
Формальний процес тестування, який перевіряє відповідність системи вимогам та проводиться з метою:
визначення чи задовольняє система приймальним критеріям;
винесення рішення замовником чи іншою уповноваженою особою приймається додаток чи ні.

Види/типи тестування

Функціональні види тестування

Функціональне тестування (Functional testing)
Тестування інтерфейсу користувача (GUI Testing)
Тестування безпеки (Security and Access Control Testing)
Тестування взаємодії (Interoperability Testing)

Нефункціональні види тестування

Усі види тестування продуктивності:
o навантажувальне тестування (Performance and Load Testing)
o стресове тестування (Stress Testing)
o тестування стабільності чи надійності (Stability / Reliability Testing)
o об'ємне тестування (Volume Testing)
Тестування установки (Installation testing)
Тестування зручності користування (Usability Testing)
Тестування на відмову та відновлення (Failover and Recovery Testing)
Конфігураційне тестування (Configuration Testing)

Пов'язані зі змінами види тестування

Димове тестування (Smoke Testing)
Регресійне тестування (Regression Testing)
Повторне тестування (Re-testing)
Тестування складання (Build Verification Test)
Санітарне тестування або перевірка узгодженості/справності (Sanity Testing)

Функціональне тестуваннярозглядає заздалегідь зазначену поведінку і ґрунтується на аналізі специфікацій функціональності компонента чи системи загалом.

Тестування інтерфейсу користувача (GUI Testing)- функціональна перевірка інтерфейсу на відповідність вимогам – розмір, шрифт, колір, consistent behavior.

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

Тестування взаємодії (Interoperability Testing)- це функціональне тестування, що перевіряє здатність програми взаємодіяти з одним і більше компонентами або системами і включає тестування сумісності (compatibility testing) і інтеграційне тестування

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

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

Об'ємне тестування (Volume Testing).Завданням об'ємного тестування є отримання оцінки продуктивності зі збільшенням обсягів даних у базі даних додатку

Тестування стабільності чи надійності (Stability/Reliability Testing).Завданням тестування стабільності (надійності) є перевірка працездатності програми при тривалому (багатогодинному) тестуванні із середнім рівнем навантаження.

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

Тестування зручності користування- це метод тестування, спрямований на встановлення ступеня зручності використання, навченості, зрозумілості та привабливості для користувачів продукту, що розробляється в контексті заданих умов. Сюди також входить:
User eXperience (UX) - відчуття, яке випробовує користувач під час використання цифрового продукту, тоді як User interface - це інструмент, що дозволяє здійснювати інтеракцію «користувач - веб-ресурс».

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

Конфігураційне тестування (Configuration Testing)- спеціальний вид тестування, спрямований на перевірку роботи програмного забезпечення при різних конфігураціях системи (заявлених платформах, драйверах, що підтримуються, при різних конфігураціях комп'ютерів і т.д.)

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

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

Повторне тестування- Тестування, під час якого виконуються тестові сценарії, що виявили помилки під час останнього запуску, для підтвердження успішності виправлення цих помилок.
У чому різниця між regression testing та re-testing?
Re-testing - перевіряється виправлення багів
Regression testing - перевіряється те, що виправлення багів, а також будь-які зміни в коді програми не вплинули на інші модулі ПЗ і не викликало нових багів.

Тестування складання або Build Verification Test- Тестування спрямоване на визначення відповідності, випущеної версії, критеріям якості для початку тестування. За своїми цілями є аналогом Димового Тестування, спрямованого на приймання нової версіїу подальше тестування чи експлуатацію. Вглиб воно може проникати далі, залежно від вимог якості випущеної версії.

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

Підходи до інтеграційного тестування:
Знизу нагору (Bottom Up Integration)
Усі низькорівневі модулі, процедури або функції збираються докупи і потім тестуються. Після чого збирається наступний рівень модулів щодо інтеграційного тестування. Даний підхід вважається корисним, якщо всі або практично всі модулі, що розробляється, готові. Також цей підхід допомагає визначити за результатами тестування рівень готовності програми.
Зверху донизу (Top Down Integration)
Спочатку тестуються всі високорівневі модулі і поступово один за одним додаються низькорівневі. Усі модулі нижчого рівня симулюються заглушками з аналогічною функціональністю, потім у міру готовності заміняються реальними активними компонентами. Таким чином, ми проводимо тестування зверху вниз.
Великий вибух ("Big Bang" Integration)
Усі або практично всі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини, а потім проводиться інтеграційне тестування. Такий підхід дуже добрий для збереження часу. Проте якщо тест кейси та його результати записані не так, то сам процес інтеграції сильно ускладниться, що стане перепоною для команди тестування при досягненні основної мети інтеграційного тестування.

Принципи тестування

Принцип 1– Тестування демонструє наявність дефектів (Testing shows presence of defects)
Тестування може показати, що дефекти є, але не може довести, що їх немає. Тестування знижує ймовірність наявності дефектів, що у програмному забезпеченні, але, навіть якщо дефекти були виявлено, це доводить його коректності.

Принцип 2– Вичерпне тестування є недосяжним (Exhaustive testing is impossible)
Повне тестування з допомогою всіх комбінацій вводів і передумов фізично нездійсненно, крім виняткових випадків. Замість вичерпного тестування повинні використовуватися аналіз ризиків та встановлення пріоритетів, щоб точніше сфокусувати зусилля з тестування.

Принцип 3– Ранне тестування (Early testing)
Щоб знайти дефекти якомога раніше, активності з тестування повинні бути розпочаті якомога раніше в життєвому циклі розробки програмного забезпечення або системи, і повинні бути сфокусовані на певних цілях.

Принцип 4- Скупчення дефектів (Defects clustering)
Зусилля тестування повинні бути зосереджені пропорційно до очікуваної, а пізніше реальної щільності дефектів по модулях. Як правило, більша частина дефектів, виявлених при тестуванні або спричинили основну кількість збоїв системи, міститься в невеликій кількості модулів.

Принцип 5- Парадокс пестициду (Pesticide paradox)
Якщо ті самі тести будуть проганятися багато разів, зрештою цей набір тестових сценаріїв більше не знаходитиме нових дефектів. Щоб подолати цей “парадокс пестициду”, тестові сценарії повинні регулярно рецензуватися та коригуватися, нові тести мають бути різнобічними, щоб охопити всі компоненти програмного забезпечення,
або системи, і знайти якнайбільше дефектів.

Принцип 6– Тестування залежить від контексту (Testing is concept depending)
Тестування виконується по-різному, залежно від контексту. Наприклад, програмне забезпечення, в якому критично важлива безпека, тестується інакше, ніж сайт електронної комерції.
Принцип 7– Помилка про відсутність помилок (Absence-of-errors fallacy)
Виявлення та виправлення дефектів не допоможуть, якщо створена система не підходить користувачеві та не задовольняє його очікуванням та потребам.

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

Дослідницьке / ad-hoc тестування
Найпростіше визначення дослідницького тестування - це розробка та виконання тестів одночасно. Що є протилежністю сценарного підходу (з його наперед визначеними процедурами тестування, неважливо ручними або автоматизованими). Дослідницькі тести, на відміну від сценарних тестів, не визначені заздалегідь і не виконуються точно відповідно до плану.

Різниця між ad hoc та exploratory testing у тому, що теоретично, ad hoc може провести будь-хто, а для проведення exploratory необхідна майстерність та володіння певними техніками. Зауважте, що певні техніки це не тільки техніки тестування.

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

Вимоги до вимог:
Коректність
Недвозначність
Повнота набору вимог
Несуперечність набору вимог
Перевірюваність (тістопридатність)
Трасування
Розуміння

Життєвий цикл бага

Стадії розробки ПЗ- це етапи, які проходять команди розробників програмного забезпечення, перш ніж програма стане доступною для широкого кола користувачів. Розробка ПЗ починається з початкового етапу розробки (стадія «пре-альфа») і продовжується стадіями, на яких продукт доопрацьовується та модернізується. Фінальним етапом цього процесу стає випуск ринку остаточної версії програмного забезпечення («загальнодоступного релізу»).

Програмний продукт проходить такі стадії:
аналіз вимог до проекту;
проектування;
реалізація;
тестування продукту;
Використання та підтримка.

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

Життєвий цикл розробки ПЗ:
Пре-альфа
Альфа
Бета
Реліз-кандидат
Реліз
Пост-реліз

Таблиця ухвалення рішень (decision table)– чудовий інструмент для упорядкування складних бізнес вимог, які мають бути реалізовані у продукті. У таблицях рішень подано набір умов, одночасне виконання яких має призвести до певної дії.

Екстра - інтроверсія, нейротизм та психотизм у структурі особистості.

1) Екстраверсія – інтроверсія. Характеризуючи типового екстраверта, автор зазначає його товариськість і зверненість індивіда зовні, широке коло знайомств, необхідність контактах. Типовий екстраверт діє під впливом моменту, імпульсивний, запальний. Він безтурботний, оптимістичний, добродушний, веселий. Віддає перевагу руху і дії, має тенденцію до агресивності. Почуття та емоції не мають суворого контролю, схильний до ризикованих вчинків. На нього не завжди можна покластися.

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

2) Нейротизм – емоційна стійкість. Характеризує емоційну стійкість чи нестійкість (емоційна стабільність чи нестабільність). Нейротизм за деякими даними пов'язані з показниками лабільності нервової системи.

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

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

3) Психотизм. Ця шкала говорить про схильність до асоціальної поведінки, химерності, неадекватності емоційних реакцій, високої

конфліктності, неконтактності, егоцентричності, егоїстичності, байдужості.

Згідно з Айзенком, високі показники з екстраверсії та нейротизму відповідають психіатричному діагнозу істерії, а високі показники з інтроверсії та нейротизму - стану тривоги або реактивної депресії.

Нейротизм і психотизм у разі виразності цих показників розуміються як «схильність» до відповідних видів патології.

Концепція тестів. Можливості та обмеження.

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

Тести інтелекту. Призначені для дослідження та вимірювання рівня інтелектуального розвиткулюдини. Вони є найпоширенішими психодіагностичними прийомами.

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

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

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

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

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

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

Тести шкільних досягнень є в основному груповими та бланковими, але можуть бути представлені і в комп'ютерному варіанті.

Професійні тести досягнень зазвичай мають три різні форми: апаратурні (тести виконання або дії), письмові та усні.

Тести особистості. Це психодіагностичні прийоми, створені задля оцінку емоційно-вольових компонентів психічної діяльності - мотивації, інтересів, емоцій, відносин (зокрема і міжособистісних), і навіть здібностей поведінки індивіда у певних ситуаціях. Отже, тести особистості діагностують неінтелектуальні прояви.

Можливості.

1. Це короткі тести- читач витрачає зовсім небагато часу та розумових зусиль на їхнє виконання. Тут же він отримує нехитру відповідь – оцінку себе за однією, як правило, шкалою популярного тесту.

2. Це «гострі» тести – обговорюються особливо привабливі для читача особистісні та міжособистісні предметні відносини. Як не згадати тут «Тест на справжнього чоловіка» чи «Тест на справжню жінку». Вони дуже відповідають віково-психологічним потребам підлітків чи молоді.

3. Ці тести складені так, що не потребують розлогих коментарів і не вимагають пояснень фахівця. Вони призначені для «заочного» використання. Будь-який науковий тест у психології призначений для фахівця, який, як правило, дуже дозовано та конфіденційно ділиться із клієнтом отриманою за допомогою тесту інформацією. Тут немає проблеми дозування інформації, та й взагалі проблеми конфіденційності. Щоправда, сама конфіденційність є: адже заповнює такий популярний тест людина віч-на-віч із текстом у журналі.

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

5. Популярні випробування швидко виготовляються. Скласти такий придатний для друку у відповідних журналах тест досить просто. Найважче у таких тестах – дати шкали оцінки відповідей та принципи підсумовування отриманих балів.

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

7. Популярні тести зазвичай є «в наборах», тобто. "вивалюються" на користувача жменями, відразу розчленовуючи (торкаючись) цілі простори свідомості клієнта. Причому вибирає завдання сам читач. Тести не нав'язані, не наказані йому, а обрані ним.

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

Обмеження.

1. Популярні тести нерідко мають дуже розпливчасті чи навіть спеціально комплексні предметні області.

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

3. Відповідно такі методики ніколи не перевіряються на надійність: те, що сьогодні на тест клієнт відповів так, а завтра – іншим чином, не є недоліком тесту.

4. Оскільки предмет тестування у таких методиках ніколи не приховується (не маскується), дослідник часто може отримувати ефект «соціальної бажаності», демонстративності.

5. Оскільки такі методики ніколи не перевіряються на їх психометричні переваги (досить вони розчленовують вибірку) і тим більше ніколи не мають нормативів (нормативних, стандартних даних методики), ті, що виконали їх, ніколи не дізнаються, наскільки їх результати за методикою подібні або різні з результатами інших користувачів. Звичайно, якщо тільки два чи три читачі не заповнюють тест одночасно!

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

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

Розкажемо, що таке SHL тести та покажемо на прикладах, як вони допомагають у роботі HR-а. Наведемо приклади всіх різновидів SHL тестів із відповідями.

З цієї статті ви дізнаєтесь

Психометричні тести:

Що таке тести SHL

Психометричні SHL тести – інструмент рекрутингу, який дозволяє відсіяти невідповідних кандидатів ще до співбесіди. SHL тести не перевіряють знання претендентів, а оцінюють їхні інтелектуальні здібності. За статистикою, після проходження SHL тестів до співбесіди доходять 70-80% претендентів.

3 різновиди SHL тестів

1. Вербальні SHL тести

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

До тексту даються 2-3 твердження. Потрібно оцінити їх за наступною шкалою: «Вірно», «Помилково» та «Мало інформації».

2. Математичні (числові) SHL тести

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

3. Логічні SHL тести

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

Для чого потрібні тести SHL

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

Що можна перевірити за допомогою тестів SHL

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

Вербальні SHL тести

Вони дозволяють визначити, наскільки швидко кандидат сприймає текст, розуміє логічні зв'язки та оцінює запропоновані твердження. У цих тестах є «підступ» - відповідь « Мало інформації» часто плутають із відповіддю « Невірно». Оцінити різницю може лише справді грамотний фахівець.

Числові SHL тести

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

Логічні SHL тести

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

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

Приклади SHL тестів

Приклад вербального тесту SHL

Вихідна умова:

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

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

Правильну відповідь: Помилково.

Твердження 2: Роботу штатних співробітників, які перебувають у відпустці, можуть виконувати студенти.

Правильну відповідь:Правильно.

Твердження 3:Процедура подання скарги та накладення дисциплінарних стягнень поширюється на студентів так само, як і на штатних співробітників.

Правильну відповідь:Мало інформації.

Приклад числового тесту SHL

Завдання: «Працюючи разом, Том, Гаррі та Дік пофарбують 100-метровий паркан за 9 годин Поодинці Том пофарбує паркан за 18 годин, а Гаррі - за 36. Скільки часу потрібно Діку на фарбування паркану, якщо Том і Гаррі візьмуть вихідний».

Правильну відповідь– 36 годин.

Приклад логічного тесту SHL

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

Правильну відповідь: другий малюнок

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

Як аналізувати результати SHL-тестів

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

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

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

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

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

У завданнях необхідно знайти:

відсотки;
частки;
відносини,

використовуючи при цьому:

аналіз даних;
графічну інтерпретацію.

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

Сенс перевірки за допомогою вербальних та числових тестів – зрозуміти, наскільки добре претендентсправляється з логічними, математичними завданнямиза умов тимчасового дефіциту. Зрозуміло, що простий приклад із відсотками вирішить кожна грамотна людина, дай їй 10-15 хвилин, але коли лічильник відраховує 60 секунд, а може бути й менше, процес пошуку рішення утруднений.

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

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

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

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

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

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

Щоб розраховувати на високий бал, слід відповісти на кілька сотень завдань, причому вирішувати краще у найважчих умовах, наприклад, обмеживши час не хвилиною, а 40-45 секундами. Числові тести у різних компаніях відрізняються складністю, і буде корисно мати запас у часі.