Про навички black, gray та white box тестування

В одному з попередніх дописів ми розглянули важливість так званого gray box тестування — практики на перетині поглядів кінцевого користувача та розробника. Як було зазначено там, така практика потроху формує нову норму — QA, що обізнані в архітектурі, процесах розробки, CI/CD, принципах і підходах до написання коду, мають більше способів спроектувати тестування і спрогнозувати потенційні проблеми. Вони стають повністю інтегрованою частиною команди.

Може здатися, що варто працювати тільки так, забувши про black та white як про застарілі крайнощі. Мовляв, ніхто вже не тестує, просто натискаючи кнопки, на таких QA вже давно нема попиту. А давати QA на аналіз увесь код і проєктувати тести за ним немає часу; до того ж, самі розробники покривають кодові ділянки тестами, навіщо QA дублювати роботу?

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

Black box — це складний процес збору інформації, проектування тестів та перевірок. Це перевірка функціоналу, роботи з БД, структури запитів та відповідей, інтерфейсу, текстів та перекладів тощо. Але якщо прибрати комплексні подібності з іншими box’ами, то однією з особливостей black box’a залишиться погляд користувача, який не знає тонкощів розробки, що, де і як було зроблено. Того самого користувача яким ви, напевне, є в десятках застосунків. Все, що муляло око, все, що “можна було зробити по-людськи”, все, до чого ви звикли, необхідно відрефлексувати не як даність, а як рішення, прийняті і втілені з певною метою.

Сюди також відносяться більш витончені або експертні перевірки, які починаються з позиції нульових знань про застосунок. Наприклад, пентестінг зазвичай починається з максимального збору даних про стек і особливості застосунку. Чи можна з особливостей респонсу дізнатись версію та конфігурацію серверної частини? Чи лежать в респонсі чутливі дані? Як налаштовано ендпоінти? А чи можна перейти за посиланням на AWS, де лежить картинка, а потім трохи піднятися за каталогом і отримати неочікуваний доступ до багатьох файлів? Все це також black box тестування, хіба що це вже позиція не кінцевого користувача, а скоріше зловмисника. Ключовим тут є вміння перемкнутися на позицію, коли про застосунок ізсередини нічого невідомо. Що можна про нього подумати? Що можна про нього дізнатися? Куди можна глянути в першу чергу?

White box тестування живе хоча б в популярній на ринку й відносно свіжій позиції SDET. Ринковий запит демонструє, що світові таки потрібні тестувальники, які б чудово розуміли, що відбувається “під капотом”. Не для того, щоби тестувальник робив те, що міг би робити розробник, а для того, щоби тестувальник ще краще консультував зі свого боку.

Уявімо застосунок, в якому є такий код:

Почати тестувати цей блок коду можна було б із бази firstNumber = 2, secondNumber = 1, потім навпаки firstNumber = 1, secondNumber = 2, далі межовий кейс firstNumber = 2, secondNumber = 2. Не забудьмо також і про негативні числа. Аж раптом із частини коду ми помічаємо, що вхідні параметри calculate ніяк не типізовані, тож починаємо відправляти літери, строки, спецсимволи. В більшості випадків кодовий вираз навіть відпрацює без видачі помилок, але чи та це поведінка, яку ми передбачили в спеці?

White box чудово демонструє себе там, де тестувальник міг би виступити містком між бізнес-світом замовника та технологічним світом розробника. Хоч приклад вище занадто спрощений, він демонструє цей спосіб мислення. Ми знаємо як написано код, знаємо, чого хоче замовник, і маємо, зрештою, певне загальне бачення усього застосунку. Ці знання в ідеалі мають застосовуватись не точково, а як спосіб задання напряму. Власне, це зазвичай і є одним з обов’язків SDET — консультувати девелоперів їхньою мовою, але аргументацією і баченням тестувальника.

Цими описами я хотів продемонструвати, що попри нормалізацію gray box підходу, вміння за потреби перемкнутися в одну з крайніх позицій може бути корисним інструментом. Це складно і навіть дуже складно з точки зору підходів — black box ви ще умовно можете зробити у себе в голові, але про повний доступ до коду доведеться домовлятися, більше того, треба буде розуміти його і прийняті архітектурні рішення. Тож варто одразу окреслити для себе перспективи та зону застосування.

Наприклад, перемикання в точку абсолютного незнання — ключова техніка тестування UI/UX, безпеки, навантаження тощо. Повний доступ до коду важливий, коли ви спостерігаєте певне скупчення дефектів або повторення одного типажу або ж в ключових логічних елементах застосунку на кшталт розрахунків чи дерева прийняття рішень в залежності від умов.