Рівень 1. Визначення тестування та якості
Рівень 1
Визначення тестування та якості
Подкаст рівня 1
прослухати урок як подкаст >
Шановний студенте! Наш курс допоможе краще зрозуміти цілі процесу тестування ПЗ в контексті наявних проєктних ролей, пов'язаних завдань та відповідних їм артефактів.
А я кажу, що потрібна практика, тільки практика і ще раз практика. Без реального застосування всі знання — нічого не варті!
Я даватиму тобі багато тестів, практичних завдань і проситиму Магістра перевіряти все ретельно, ретельно!
Після навчання ви зможете самостійно готуватися до тестування, планувати та виконувати процес тестування, готувати тестові середовища й набори тестових даних, складати описи дефектів та звіти за результатами тестування.
А також підтримувати процес розробки ПЗ та управління проєктом.
Забагато розумних слів. Краще поясни простими словами, що таке QA.
Як говорить нам стандарт ISO 9000:2005:
«Скоординована діяльність з керівництва та управління організацією щодо якості», а в примітці сказано, що вона «зазвичай включає розроблення політики й цілей у сфері якості, планування якості, управління якістю, забезпечення якості та поліпшення якості».
Гей, розумники! А що щодо QC? Я постійно чую про QA та QC, але що таке QC і чим «це» відрізняється від QA?
Quality Control (контроль якості) — це процес пошуку помилок у продукті з метою їх подальшого виправлення. Завдання Quality Control — підтримувати якість продукту в поточний момент часу. Quality Control орієнтований на продукт, що розробляється просто зараз.
Quality Assurance включає в себе Quality Control поряд з іншими процесами, що поліпшують якість роботи компанії.
Іншими словами, Quality Assurance гарантує, що процес побудовано правильно і він дає передбачуваний результат, тоді як Quality Control гарантує, що продукт відповідає заданому набору вимог.
Давайте розберемося: що ж таке якість?
Я думаю, що якість — це відсутність помилок!
- Автомобіль Mercedes визнано якісним, але мова не про помилки.
- Смартфон Apple iPhone визнано якісним телефоном. При цьому його не назвеш «ідеальним».
Тоді я думаю, що якість — це задоволеність замовника. Отак!
Хороший замовник завжди незадоволений.
Тоді скажу так: якість — це відповідність очікуванням. Робить те, що має, і не робить того, чого не повинно.
Стандарт ISO дає таке визначення: «Якість програмного забезпечення — це здатність програмного продукту за заданих умов задовольняти встановлені або передбачувані потреби».
Але я погоджуюся, що відсутність помилок — це фактор якості. До речі, поговорімо про це докладніше:
про фактори якості
Фактор якості — це вимога до програми, яка зазвичай не прописується в договорі із замовником, але тим не менш є бажаною вимогою, що підвищує якість програми.
R2D2, які фактори якості ти знаєш?
- Надійність — чи працює застосунок без збоїв, «зависань» і виклику виняткових ситуацій;
- Супроводжуваність — наскільки складно змінити програму, щоб задовольнити нові вимоги. Ця вимога також означає, що програма має бути добре задокументована, не надто заплутана і мати запас для зростання споживання ресурсів (пам'ять, процесор);
- Практичність — призначення ПЗ має бути зрозумілим із самої програми та документації;
- Ефективність — наскільки раціонально програма ставиться до ресурсів (пам'ять, процесор) під час виконання своїх завдань;
- Продуктивність — чи працює застосунок з прийнятною швидкістю, коли до нього звертається багато користувачів;
- Мобільність — легкість адаптації програми до іншого середовища: іншої архітектури, платформи, операційної системи або її версії;
- Функціональність — чи робить застосунок те, що від нього вимагається;
- Зручність використання: простота і зручність користування програмою. Ця вимога стосується насамперед інтерфейсу користувача;
- Безпека. Мається на увазі захищеність ПЗ від злому.
Матінко рідна! Скільки пунктів. Думаю, ми ще зустрінемося з цими поняттями, коли дійдемо до видів тестування.
Ти, мабуть, трохи втомився. Коли я втомлююся, я йду спостерігати, чим займаються сили зла. Це додає мені нових сил.
Так! Ті жахіття, що вони коять, додають мені сил для боротьби. Тепер я хочу запитати: звідки береться Якість?
- Якість Продукту визначається лише Якістю Процесу його розробки
- Якість Процесу визначається лише Рівнем Культури розробки в Компанії
- Якість Продукту визначається використовуваною методологією та підходом до управління процесами розробки / тестування
Ясненько. Ми весь час ходимо навколо та довкола. Але досі не з'ясували, що таке тестування?
Незрівнянний Гленфорд Майєрс у своїй книзі «Надійність програмного забезпечення» [М:Мир, 1980] дав таке визначення:
Тестування — це процес виконання програм з наміром знайти помилки. (класика)
Ти стара консервна банко! Даєш людям визначення 1980 року. Тоді інтернет був лише через dial-up. Це марний мотлох!
Старий — значить досвідчений! Воно досі актуальне!
Я перепрограмую тебе на мийника унітазів після таких визначень!
Валідація в техніці або тестуванні — процес надання доказів того, що вимоги конкретного зовнішнього користувача продукту або системи задоволено.
Бачу, ви втомилися від вивчення тонкощів тестування і почали застосовувати образи замість мудрості.
Вам потрібно виконати завдання. Для відновлення духовних сил.
Уявіть собі форму валідації введеного значення.
Вимога до роботи форми: якщо введено ціле значення від 0 до 9 (включно), форма має повертати значення VALID
Це щось на кшталт такого?
Вірно. Не поспішай, гарненько подумай, як протестувати цю форму. Чи треба перевіряти всі варіанти правильних і неправильних операцій? Поки що надія здебільшого на логіку, але з осягненням сили тестування ти почнеш бачити всі тести з одного погляду. Якщо раптом знайдеш баги у формі, повідом про них у формі наприкінці рівня — за це можна отримати бонусні бали.
Я нічого не зрозумів. Як проводити тести? Ця форма така дивна і незрозуміла. Що я маю з нею робити?
Кожен тест у цьому випадку — це варіант даних, що вводяться у форму. Наприклад, ти вводиш цифру 3, вона потрапляє в діапазон від 0 до 9. Тест пройдено, якщо форма видала VALID. Потім вводиш 342, і форма не повертає INVALID. У такому разі тест також пройдено. Сенс завдання полягає в тому, щоб придумати такий мінімальний набір тестів, який дозволить на 100% переконатися, що форма працює правильно. І врахувати всі можливі пари: введення — відповідь, при цьому не перебираючи всі числа світу.
Тепер зрозуміліше. Я маю вводити різні дані, доки не переконаюся, що в усіх випадках отримую коректну відповідь. Дякую, Магістре!
Це відповідь на запитання Магістра для самоперевірки. Коли захочеш звіритися, натисни на посилання.
Ура! Ти впорався. Робиш перші успіхи. Ну що, відчув себе тестувальником?
Успіхів тобі! Що стосується визначення тестування, зверни увагу на це слово:
Тестування — це процес виконання програм з наміром знайти помилки.
З цього зроби висновок, що пошук помилок не повинен бути в центрі зусиль тестувальників.
Хочеться розповісти докладніше про помилку. Помилки та дефекти, через які програма видає несподівану поведінку і, як наслідок, результат у тестуванні, називають багами.
Більшість багів виникають через помилки, допущені розробниками програми в її вихідному коді, логіці поведінки або дизайні. Все-все про баги ви дізнаєтеся на 5 рівні QA Academy.
На додаток до цієї теми я хочу навести визначення, придумане Полом Йоргенсеном:
Тестування зосереджене на помилках і збоях. Тест — це виконання дій над ПЗ з метою знайти помилки або продемонструвати його працездатність.
Мабуть, тут я погоджуся з тобою. Після такої-то роботи. І дам узагальнене визначення:
Тестування — це процес перевірки відповідності заявлених до продукту вимог і реально реалізованої функціональності.
Переваги визначення:
фокус процесу тестування зміщено в бік перевірки вимог
Отже, нарешті уточнімо визначення:
Тестування — це процес перевірки відповідності заявлених до продукту вимог і реально реалізованої функціональності, що здійснюється шляхом спостереження за його роботою в штучно створених ситуаціях і на обмеженому наборі тестів, обраних певним чином відповідно до потреб бізнес-завдання.
І не забувай про здоровий глузд! Головна аксіома тестувальника — всі помиляються. Програмісти, аналітики, автори вимог і документації. Усіх потрібно перевіряти!
Отже, еволюція уявлень про тестування
| 1980 | Процес виконання програми з наміром знайти помилки. [Г. Майєрс. Надійність програмного забезпечення. М:Мир, 1980] |
|---|---|
| 1987 | Процес спостереження за виконанням програми в спеціальних умовах і винесення на цій основі оцінки якихось її аспектів. [ANSI/IEEE standard 610.12-1990: Glossary of SE Terminology. NY:IEEE, 1987] |
| 1990 | Це не дія. Це інтелектуальна дисципліна, метою якої є отримання надійного програмного забезпечення без зайвих зусиль на його перевірку. [B. Beizer. Software Testing Techniques, Second Edition. NY:van Nostrand Reinhold, 1990] |
| 1999 | Технічне дослідження програми для отримання інформації про її якість з точки зору певного кола зацікавлених осіб. [C. Kaner, 1999] |
| 2004 | Перевірка відповідності між реальною поведінкою програми та її очікуваною поведінкою на скінченному наборі тестів, обраних певним чином. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004] |
Окей, ми нарешті з'ясували, що таке тестування. Я зрозумів, що завдання тестування набагато ширші, ніж просто пошук дефектів! Але в мене накопичилися запитання конкретного характеру, на які вся ваша теорія конкретної відповіді не дає.
Припустімо, я знайшов певну кількість помилок. Як зрозуміти, N знайдених багів — це багато чи мало? Наприклад, 3 помилки під час тестування попередньої форми?
Чудове запитання. Воно хвилювало не одне покоління роботів. Подейкують, що в робота R1F1 перегоріли всі транзистори під час пошуку відповіді. Подумай і ти.
Подумав? Тепер звір із відповіддю.
Дуже важливо подумати самому, перш ніж дізнатися, що з цього приводу думає R2D2.
Запитання з галузі філософії тестування: чому наші користувачі знаходять помилки, якщо ми витратили на тестування стільки часу?!
Я дам тобі хвилину, щоб подумати самому.
Потім ти можеш дізнатися мою думку.
Мені все-таки хочеться уточнити: ну знайшов я свої N багів, припустімо, 82 баги на всьому сайті. Я ж можу спокійно сказати, що роботу закінчено і я все протестував?
Запитання просте. Ти сам здогадаєшся, якщо подумаєш хвилинку.
Звіримося з відповідями
Тільки подумати. Якщо користувачі все одно побачать баги, а тестувальники не виловлять їх на 100%, навіщо вони тоді взагалі потрібні? Чому не доручити все користувачам?
Ех, молодь... Та жоден користувач не захоче купувати програмний продукт з помилками. Давно минула ера синіх екранів у Windows. Конкуренцію виграє найякісніший продукт, навіть якщо він коштує дорожче. Я для тебе спроєктую графік вартості виправлення дефектів. Тоді ти зрозумієш, що тестувальники потрібні на самому початку створення ПЗ. Адже з кожним етапом дедалі більше людей залучається до виправлення.
Користуючись нагодою, хотів би подати вам важливі факти про практику тестування:
- Тестування програмного забезпечення забирає від 30 до 50 відсотків усієї вартості розробки (класична метрика)
- Тестувати ефективно — означає вирішувати проєктні завдання в рамках процесу із застосуванням інтегрованих рішень
- Тестування — не лише процес контролю, а й потужний інструмент розробки, що дозволяє досягти певного рівня якості
Твоє завдання — тестувати ефективно. Зрозуміло?!
Будь чемним, R2D2. Перед тобою майбутній тестувальник. Магістр ним дуже задоволений. Отже, підведімо підсумки:
- Основна мета процесу тестування — досягнення певного рівня якості Продукту або Системи, що розробляється
- Процес тестування може не лише виявляти й визначати дефекти, а й запобігати їм
- Тестування стає процесом, ефективність якого кардинально впливає на вартість Продукту та терміни його виходу на ринок
Зрозумів, про що йшлося в першому уроці? Серйозно?
Супер! Тоді ось тобі перший теоретичний тест. Якщо тест буде пройдено — запуститься резервний генератор корабля. Енергії вистачить для переходу на інший рівень. Але знай, результати тестів вносяться до рейтингу тестувальників лише у користувачів, які придбали підписку. Зауваж, що в системі тестування тобі доведеться зареєструватися.
Щоб відчути знання тестування, ти повинен використати їх на практиці. Знаю, що це здається тобі важким, але якщо повіриш у себе, успіх знайдеш.
Протестуй сайт і знайди максимальну кількість дефектів. Надішли цей список мені через форму або на email
Мій дорогий падаване, сподіваюся, сьогоднішня пригода у світі QA була цікавою та захопливою для тебе. З нетерпінням чекаю на твоє завдання для перевірки.
Для безкоштовної перевірки зроби репост нашої академії в соцмережі. Але хочу уточнити, що детальний аналіз завдання отримують лише преміум-підписники або після оплати перевірки. Адже знання Магістра мають найвищу ціну в цьому нестабільному світі!