Хто з нас не бажав би мати суперздібності — літати в небі, як Супермен, лазити по стінах, як Людина-павук, переміщатись у просторі так само швидко, як Флеш? На жаль, у житті так не буває. Але чи можемо ми здобути якусь суперздібність у професійній галузі? Якщо ми з вами інженери із забезпечення якості (QA), то відповідь — так!
Щоб пояснити, як нам отримати таку суперздібність, а саме «Суперзір», подивімося для початку, як на запитання «Що таке тестування?» відповідає Вікіпедія:
Тестування програмного забезпечення — процес перевірки відповідності заявлених до продукту вимог і реально реалізованої функціональності, який здійснюють шляхом спостереження за його роботою в штучно створених ситуаціях і на обмеженому наборі тестів, обраних певним чином.
Як бачите, тут ми вже маємо купу викликів: це і штучно створені умови, й обмежений набір тестів. Тобто перед нами постає доволі нетривіальна задача: як створити умови й обрати саме ті тести, які дійсно будуть корисними й ефективними.
Тут читач, знайомий з теорією тестування, може запитати мене: «Навіщо мені якісь суперздібності? Ми маємо купу технік тест-дизайну: граничні значення, попарне тестування, таблиці прийняття рішень і техніки зміни станів... То нащо мені якийсь там суперзір?». Запитання слушне, тож розберімо його на прикладі.
Кейс «Нявкаюча коробка»
Уявімо, що ми влаштувалися QA-інженерами в компанію «BlackBox Inc.» і потрапили на проєкт «Нявкаюча коробка». Відкриваємо ТЗ і бачимо там:
Створити непрозору коробку у формі куба зі сторонами метр на метр, яка буде хоча б раз на годину видавати звук "Няв" (у японській версії — "Ня"). Відкривати коробку суворо заборонено.
Озброєні техніками тест-дизайну, поки чекаємо, як із «відділу розробки коробок» нам принесуть виріб, створюємо набір перевірок:
- Перевірити, що коробка непрозора.
- Перевірити, що кожна грань коробки має довжину 1 метр.
- Перевірити, що коробка раз на 60 хвилин «нявкає».
І ось коробка в наших руках! Приступаємо до тестування: коробка має чорний колір, і коли ми світимо ліхтариком на будь-яку з її сторін, з іншого боку світла не бачимо. З рулеткою вимірюємо кожну з граней — результат 1 метр. Крім того, щойно ми отримали коробку, вона жалібно нявкнула, а ще через годину звук повторився.
Формально всі вимоги перевірені. Чи зробили ми необхідний набір тестів? Добре, додамо до набору ще кілька перевірок, які базуються на досвіді (техніка Error Guessing). Виходячи з того, що якщо щось нявкає, то це кішка, підсунемо під коробку котячого корму (кішку ж треба годувати) і подивимося, як коробка зреагує на це...
Але питання залишається: якщо ми не можемо зазирнути в коробку, то ніколи не можемо бути впевненими, що перевірили достатньо.
ДЛЯ ТИХ, КОМУ ЦІКАВО, ЧИМ УСЕ ЗАКІНЧИЛОСЬ: у коробці був радіоприймач, який приймав сигнал із передавача. Передавач знаходився у «відділі розробки коробок», і тамтешній співробітник нявкав у мікрофон раз на годину — тоді коробка і видавала звук. Але коли коробку відправили замовнику, приймач опинився поза зоною досяжності передавача. Розгніваний замовник повернув коробку до «BlackBox Inc.» і подав до суду.
Чи могли ми запобігти цьому й виявити критичний дефект? Ні, такий тестовий сценарій майже неможливо уявити, не зазирнувши в коробку.
ЯК ПРАЦЮЄ СУПЕРЗІР
А ось якби в нас був «суперзір», який би дозволив побачити, що знаходиться всередині, то ми б знали про наявність радіоприймача! Ми б оновили наші тести відповідно до цього знання і мали б можливість попередити таку прикру ситуацію.
У реальних умовах для QA-інженера таким «суперзором» є вміння програмувати.
Саме воно дає нам можливість зазирнути за межі «непрозорої коробки» та зробити відбір тестів більш ефективним. Ми знаємо не тільки, як об'єкт тестування має працювати, але й розуміємо його внутрішню структуру. Базуючись на цих знаннях, ми можемо знайти та створити такі тестові сценарії, які без цього придумати вкрай складно. Оскільки розробники одну й ту саму вимогу можуть реалізувати безліччю різних шляхів, QA повинен мати можливість проконтролювати цю реалізацію.
Крім того, розуміння того, як працює код і як влаштована архітектура, дає можливість зазирнути на нижчі рівні «піраміди тестування» — а саме на інтеграційний і модульний (API, Unit). Не розуміючи основ програмування, тестувальнику там нічого робити, хоча саме на цих рівнях зазвичай відбувається найбільша кількість тестів.
ВИСНОВОК
У наш час можна впевнено сказати, що міф про те, ніби QA не повинен вміти програмувати, остаточно зруйновано. Без цієї суперздібності ніколи не буде стовідсоткової впевненості, що обмеженого набору тестів достатньо для покриття всіх ризиків.
До того ж, саме розуміння архітектури систем (а чи можна її розуміти, не знаючи хоча б основ програмування?) робить sanity-тестування дійсно раціональним. Бо як ми можемо передбачити вплив змін, якщо не розуміємо, як система працює зсередини?
Залишається відкритим питання: яку мову вибрати? Це вже на ваш розсуд, але я б радив мови програмування з низьким порогом входу — JavaScript або Python. Адже далі, якщо вмієш програмувати хоча б однією мовою, то без проблем розберешся і в будь-якій іншій.
