Тестування. Помилки при сертифікації або ISTQB мені дуже потрібен

Стаття корисна тим, кому небайдужа їхня кваліфікація і хочеться стати краще. Вчитися ніколи не пізно.
Будь-тестувальник рано або пізно замислюється про якість не тільки в робочому процесі, а й у ставленні до себе, як свого освіти і здібностей. У даний момент далеко не всі вузи здатні підготувати такого спеціаліста. Залишаються всілякі курси, як правило, дистанційні, щоб була можливість повчитися у людей з цієї ж області, які домоглися успіху. Але є і ще один спосіб самоствердитися. Це сертифікати. Їх багато, перераховувати, сенсу немає. Але практично у всіх областях вони є і їх отримання, скоріше плюс, ніж мінус.
image
Мені б хотілося написати про ISTQB, т. зв. International Software Testing Qualifications Board. Це визнана в усьому світі сертифікація для тестувальника. Якщо ти таке отримав, то по ідеї володієш базовими знаннями та теорією, тобто і плюсик тобі на співбесідах добути можеш, і в загальному самоутверждаешься.
У статті я б поговорила про помилки. Про дурних і не дуже. Про тих, які я особисто зробила в такому тесті або могла. І не хотіла б, щоб хтось теж так попався.
Вичерпне тестування
Хотілося б для початку, щоб запам'ятали наступне, «вичерпне тестування неможливо, незалежно від того, скільки зусиль витрачено на тестування (т. зв. Принцип # 2)». Цей принцип доведеться запам'ятати. Багато посилань на матеріали для підготовки кидати не буду, наведу одну в кінці статті. Пункт, в якому я засумнівалася, був “При достатніх зусиллях та інструментальної підтримки вичерпне тестування можливо для будь-якого програмного забезпечення". Перші думки були про те, що терпіння і труд все перетруть. Це вірно тільки для тривіальних ситуацій, в будь-якій реальній системі передбачити всі ситуації не зможемо, залишається тільки звести до мінімуму кількість проблем.
image
Стадії та завдання
Інформація для запам'ятовування. Основний процес тестування можна поділити на етапи, напрямки діяльності:
  • Планування (Етап 1)
  • Аналіз та проектування (Етап 2)
  • Впровадження та реалізація (Етап 3)
  • Оцінка критеріїв виходу і створення звітів (Етап 4)
  • Дії по завершенню тестів (Етап 5)
Ці всі етапи варто знати. Вони виділені не випадково, всі мають особливості. Але це не означає, що вони не можуть накладатися один на одного або відбуватися одночасно в конкретній ситуації.
Питання, з яким я зіткнулася, по суті, був таким, які завдання ми виконуємо на етапі аналізу і проектування. Були різні варіанти відповідей.
  • Визначення цілей тестування
  • Рецензування базису тестування
  • Створення тестових наборів тестових процедур
  • Аналіз накопиченого досвіду для покращення процесу
Вхопившись за слово проектування, я припустила, що саме на цьому етапі проектуються всі тест плани, тому створення процедур і тестових наборів здавалося відмінним відповіддю. Як я була не права.
Тому коротко розгляну всі етапи, щоб прочитавши мою статтю можна було не читати величезні мануали. Спеціально пронумеровала етапи посилання на кожен.
Отже, етап номер 1, планування. На цьому етапі найважливіше визначити мету тестування і описати для себе (або вищестоящому особі) завдання, які цю мету допоможуть досягти. Тут і обсяг, і ризики, і підходи, і люди. Цей етап також включає ще і управління тестуванням. Ми не тільки план склали, але і протягом всього процесу стежимо, що він виконується, завдання за завданням. Таким чином, не тільки ставили завдання, але і займаємося їх моніторингом.
На другому — ми аналізуємо і займаємося проектом. Що входить? Як раз рецензування базису тестування. У нього входить вимоги на цілісність проекту, звіт про аналіз ризиків, архітектура, дизайн, тех. вимоги до інтерфейсу. На цьому етапі, по суті, складаємо звіти про ризики, оцінюємо характеристики, розставляємо пріоритети, у проекту вимальовується архітектура. Вибираємо тестове оточення і встановлюємо всі інструменти.
якраз на третьому етапі дається воля для написання тестових сценаріїв, тут же виконується вся відповідальна робота для виконання їх в ручному або автоматичному режимі. Етап впровадження та реалізації я б хотіла віднести до найголовнішим у житті тестувальника, в ньому без сумніву й відбудеться найбільше часу, найбільше буде знайдено проблем, які, як не прикро визнавати, нас надихають для подальшої роботи.
На четвертому етапі в основному займаємося звітом, оцінюємо характеристики, які можемо, дивимося знайдені баги, аналізуємо які б ще тести могли б провести, все це формуємо звіт для зацікавлених осіб.
І нарешті, п'ятий етап, це скоріше набір досвіду. Дивимося, які результати ми отримали, які змогли досягти мети, аналізуємо дані для майбутніх релізів і використовуємо далі. На цьому етапі теж не обійтися без документації, яку треба зробити детально, щоб віддати на етап супроводу.
Тестування в період супроводу
У чому була моя помилка, я припустила, що на цьому етапі можна займатися розбором скарг по системі під час приймальних процедур. І ця основна задача. Насправді, до тестування в період супроводу відноситься робота системи після зміни оточення. Тобто до цього пункту відноситься вплив цих змін на діючу систему або якісь додаткові модифікації.
Наприклад, зміна платформи. Що буде тестуванням супроводу? Всі експлуатаційні тести, тестування змін, варто так само додати в список планів регрессионное тестування тих областей, які при цьому не були порушені. При цьому основна проблема — це межі області, яку варто включити до тестування. Якщо дозволяє час і ресурси, то варто включити їх все. Але на це часу вистачає далеко не завжди. Тому для прийняття рішення доведеться оцінити ризик і співвідношення розміру системи до розміру внесених змін.
Системне і компонентне тестування
Головне пам'ятати, що компонентне тестування зазвичай є відповідальністю розробників, в той час як системне тестування — типова відповідальність тестувальників.
При компонентному тестуванні займаємося тим же пошуком дефектів, тільки в різних шматочках системи, наскільки можливо систему на ці частини поділити. Важливо, щоб кожну з таких частин можна було тестувати ізольовано. Є безліч способів і підходів, але це дуже широка тема, яка відведе від самої суті, від різниці між видами тестування. Ще однією особливістю компонентного тестування є те, що воно включає не тільки функціональне тестування, але і перевіряються нефункціональні характеристики. Наприклад, до таких відноситься тестування поведінки ресурсів, відстежуються витоку пам'яті. Як правило, при компонентному тестуванні доступний код.
Протилежним тестуванням є системне. Якщо в компонентному ми розглядали кожну частину, як окрему, то тут ми дивимося на систему, як на єдиний об'єкт. При тестах застосовуємо безліч методів, і досліджуємо як функціональні, так і не функціональні вимоги. Тут вже підходять для дослідження тестові опису, варіанти використання системи та інші всілякі способи пошуку багів, але сама система розглядається у вигляді «чорного ящика» без доступу до коду.
Формальне рецензування і його кроки
Коли для системи сформовано множину вимог до коду, вимог до вхідних даних, якісь юридичні моменти повинні бути враховані, і інше, і інше, то як етап тестування додається рецензія. По суті є список, що ми повинні врахувати для завершення кожного модуля в системі. Можливо, що в цьому процесі доведеться вдаватися до експертів в потрібній нам області.
Основні фази формального рецензування — це планування, старт, індивідуальна підготовка, вивчення/оцінка/запис результатів, повторна обробка, відстеження. Етапи насправді всі послідовні і логічні. Спланували, які критерії потрібні, і вибрали людей, при запуску поділилися з усіма своїми планами, підготувалися індивідуально, враховуючи всі особливості і вимоги саме цієї системи. Далі отримали результати, які показали нашим експертам, і всі проблеми, що спливали, поправили. І далі стежимо, щоб ніде нічого не порушувалося.
Висновок
Даний матеріал не створений, щоб вирішити всі питання, пов'язані з майбутньою сертифікацією. Сподіваюся, хоча б те небагато, що я встигла висвітлити, вкладеться в голові напевно. Якщо хоч в якійсь мірі стаття була корисна, то можу продовжити розбір найбільш, на мій погляд, неочевидних помилок, яких було просто уникнути.
Завжди готова до конструктивної критики. Якщо виникнуть запитання або у моїх твердженнях знайдеться предмет для дискусії, буде привід зайвий раз повернутися до теорії.
Корисні посилання
Матеріали для підготовки
Гарна стаття про тестуванні від Наталії Руколь
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.