7 заповідей тестувальника або атланти забезпечення якості

Вступ

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

Цікавий факт:

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

«Для чого ти усе це нам розповідаєш? Як закони Ньютона, базар та жінки радянських керівників пов’язані із тестуванням?», можете ви мене запитати, шановні читачі. І ваш гнів буде цілком праведним, адже, на перший погляд, усі ці речі мають такий же зв’язок, як і рубанок із космічним кораблем. Але саме таким ковзким шляхом порівнянь я намагався підвести вас до теми цієї статті, яку ви вже, напевно, прочитали у заголовку. Вже відчуваю, як у вас виникла друга хвиля запитань: «Які заповіді? Які атланти? Це ж технічна стаття, а не клуб шанувальників грецької міфології!». Знову поділяю ваше обурення, але цього разу маю кілька аргументів у свій захист. Оскільки цей матеріал був написаний для початківців, які, зазвичай, погано запам’ятовують сухі факти та визначення, то мені здалось доречним вдатись до саме такого не зовсім звичного стилю написання. Тут залишається тільки зрозуміти та пробачити!

Цікавий факт: 

Якщо ви помітили, що в останньому реченні є відсилання до російського серіалу, то, по-перше, з вас, шановні читачі, будуть люди у галузі забезпечення якості, оскільки уважність – необхідна навичка у нашій справі, а, по-друге, цю фразу, як і багато чого іншого, непорядні автори просто сперли. Її справжня авторка — баронеса Анна-Луїза Жермена де Сталь-Гольштейн, більш відома як «мадам де Сталь». Декілька століть тому була така французька письменниця, яка й аристократів в лабетах тримала, і з Наполеоном конфліктувала. Ось така цікава особистість!

Частина 1: Невипадкова назва та підвалини теорії

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

Варто почати з того, що у цій статті я хочу розповісти про принципи або аксіоми тестування, яких існує всього 7. Пам’ятаючи, що заповідей, які, за Біблією, отримав Мойсей, було 10, я свідомо пішов на «підробку». Як на мене, слово «заповідь» краще запам’ятовується, ніж слова «принцип» або «аксіома», але, на жаль, я не можу відредагувати загальноприйнятий термін, принаймні на поточній посаді. Говорячи про число 7, його і так всі пам’ятають, бо воно є надто популярним: 7 днів у тижні, кожний зараз має СІМ-карту, багато хто має СІМ’ю, колись існувало 7 чудес світу і так далі, – тому доведеться запам’ятати лише новий контекст. Стосовно атлантів, то, за давньогрецькою міфологією, вони тримали на своїх плечах західну частину небосхилу, і ніхто крім них не міг впоратись із цією місією. А до якого ще поняття доречно застосувати таке порівняння, як не до основи основ? Тому завдяки таким гучним назвам я сподівався полегшити засвоєння теорії тестування. Сподіваюсь, у мене хоч трішечки виходить.

Цікавий факт: 

Говорячи про Мойсея, на думку спадає однойменний твір нашого Каменяра. У цій поемі, як і в Біблії, пророк Мойсей водив свій народ по пустелі 40 років, щоб вони прийняли заповіді та почали їх виконувати, а також, щоб зникло рабське мислення. Ось так і з принципами тестування: поки ви, шановні читачі, не зрозумієте ці принципи, не почнете їх застосовувати та мислити, спираючись на них, будете ходити тенетами теорії тестування і мучитись від інтелектуальної спраги.

Облишаючи назву терміну і переходячи до його суті, хочу для початку перерахувати усі 7 принципів тестування, але, щоб бути чіткішим, спочатку наведу інформацію із найавторитетнішого джерела та мовою оригіналу (тобто з ISTQB Foundation Level Syllabus англійською мовою), додавши переклад українською (не важливо в якому порядку ви їх запам’ятаєте, адже порядок тут не грає жодної ролі):

1. Testing shows the presence of defects, not their absence (Тестування показує наявність дефектів, а не їх відсутність)
2. Exhaustive testing is impossible (Вичерпне тестування неможливе)
3. Early testing saves time and money (Раннє тестування економить час і гроші)
4. Defects cluster together (Дефекти групуються разом)
5. Beware of the pesticide paradox (Остерігайтеся парадокса пестицидів)
6. Testing is context dependent (Тестування залежить від контексту)
7. Absence-of-errors is a fallacy (Відсутність помилок — це омана)

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

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

Але, як казав Гі де Мопассан: «Ближче до тіла!», – тому час перейти до більш детального розгляду кожного з канонічних принципів тестування, додаючи декілька прикладів їх застосування!

Частина 2: Теорія під мікроскопом із прикладами

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

Приклад:

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

Як краще запам’ятати:

Ви завжди ходите на озеро для того, щоб подивитись на лебедів, а не для того, щоб впевнитись, що їх там немає.

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

Приклад:

Ми приїхали копати картоплю, і нам доручено викопати 5 соток. Тож, чи можливо вибрати кожну картоплину з цієї території? Де-юре, може і так, а де-факто — ні, бо все одно хтось щось пропустить.

Як краще запам’ятати:

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

Далі слід розглянути третій принцип: «Раннє тестування економить час і гроші». З першого погляду, це твердження не зовсім зрозуміло, бо яка різниця коли починати, якщо обсяг тестів майже той самий? Усе не так просто! Насправді тестові активності мають розпочинатися якомога раніше. Цей принцип пов’язаний із поняттям «ціна дефекту» (cost of defect). Ціна дефекту істотно зростає протягом життєвого циклу розроблення ПЗ. Що раніше виявлено дефект, то швидше, простіше і дешевше його виправити. Для наочності наведу цікаву діаграму та розберемо реальний приклад.

Приклад:

Ми з вами є власниками інноваційного десктопного додатка калькулятора. Наша команда розпочала тестування продукту лише після того, як кінцеві користувачі почали скаржитись на помилки. Вартість виправлення знайдених багів буде просто космічна, адже тепер нам доведеться знов оплачувати послуги BA, PM, програмістів, дизайнерів та QA, які замість того, щоб працювати над новою версією, будуть правити стару. А якби тестування розпочали одразу після завершення формування вимог, то час та вартість виправлень була б у десятки разів менша. Ось така фігня, малята)

Як краще запам’ятати:

Народна мудрість каже нам: «Хто рано встає, тому Бог подає». Так і з початком тестування: чим раніше почав, тим краще результат отримав.

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

Цікавий факт:

Скупчення дефектів базується на «Принципі Парето», що також відомий як «Правило 80-20». Це означає, що 80% виявлених дефектів обумовлені 20% модулів у додатку. Автор цієї концепції — італійський економіст Вільфродо Парето.

Приклад:

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

Як краще запам’ятати:

Стосовно самого принципу, варто згадати таке комуністичне гасло (вибачте, що російською, але так краще зрозуміла абсурдність): «Пролетарии всех стран, соединяйтесь!». А до принципу Парето гарно підійде вислів: «1 дурень 4 лиха робить» (тобто проблем в 4 рази більше ніж дурнів, тому співвідношення 1 до 4 => 2 до 8 => 20 до 80).

Перейдемо до п’ятого принципу: «Остерігайтеся парадокса пестицидів». Коли в одному з модулів виявляється більше дефектів, тестери докладають додаткових зусиль для тестування цього модуля. Після декількох ітерацій тестування якість коду покращується, і кількість дефектів починає знижуватися, оскільки більшість дефектів виправляються командою розробників і скоро настає момент, коли дефекти взагалі зникають. І саме на цьому етапі важливо не зрадіти та розслабитись, а тримати все під контролем та періодично змінювати тест-кейси та тест-дату, бо в іншому випадку перевірки просто перестануть знаходити нові дефекти. Зазвичай, парадокса пестицидів уникають двома способами: повна заміна тест-кейсів та тест-дати або додавання нових екземплярів у вже наявний набір.

Приклад:

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

Як краще запам’ятати:

Паразити швидко звикають до певної отрути, тому її треба періодично змінювати, щоб зберегти врожай.

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

Приклад:

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

Як краще запам’ятати:

В цьому випадку підійде гарний вислів: «Кожному своє», бо тестування медичних програм має свої особливості, а, наприклад, банківського додатка – свої.

І останній з загальновживаних принципів – сьомий: «Відсутність помилок — це омана». Деякі організації очікують, що тестувальники можуть провести всі можливі тести та знайти всі можливі дефекти, але перші два принципи говорять нам, що це неможливо. Крім того, помилково очікувати, що просто виявлення та виправлення великої кількості дефектів забезпечить успіх системи. Якщо ж вимоги до програми були хибними, то додаток все одно буде провальним.

Приклад:

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

Як краще запам’ятати:

Якщо вам здається, що помилок немає, то вам просто здається. Змініть кут огляду!

Наостанок хотів би розглянути додаткові принципи, які не ввійшли до загальноприйнятих, у форматі питання відповідь:

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

Протягом усього процесу тестування ми повинні пам’ятати, що ми очікуємо отримати в кінці, бо якщо кейс є складним до виконання, то можна так зосередитись на дотриманні вимог, що забути про потрібний результат. А якщо кінцевий результат одразу занотувати, то його можна взагалі не запам’ятовувати.

Підсумок

У цій статті я розповідав вам, шановні читачі, про так звані «заповіді» тестування, які у більш класичному варіанті звуться принципами або аксіомами.

Починав я з внутрішніх правил систем (згадаємо радянщину) та обґрунтування назви (мова йшла давньогрецькі міфи та «Мойсея» Каменяра). Потім перейшов до самих принципів, яких є всього 7:

1. Тестування показує наявність дефектів, а не їх відсутність (про лебедів)
2. Вичерпне тестування неможливе (про недобрану картоплю)
3. Раннє тестування економить час і гроші («Хто рано встає, тому Бог подає»)
4. Дефекти групуються разом («Пролетарии всех стран, соединяйтесь» та «один дурень чотири лиха робить»)
5. Остерігайтеся парадокса пестицидів (про паразитів, що пристосовуються)
6. Тестування залежить від контексту («Кожному – своє»)
7. Відсутність помилок — це омана (змініть кут огляду!)

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

Завершити хотілося б коректним трактуванням термінів «принцип» та «заповідь»: це не якісь заборони, через недотримання який неодмінно прийде покарання, а ключі до успішного проєкту, які працюють у причинно-наслідковому режимі (якщо зробити так, то можна отримати це, а якщо не зробити, то ось це). Тому раджу розібратись із принципами тестування якнайшвидше, і ваше інтелектуальне блукання хибними шляхами тестування (згадаємо «Мойсея») майже одразу закінчиться!