У традиційній інтерпретації, так би мовити, існує два основних визначення методів тестування: відкрита, прозора скринька (тестування “білої скриньки”) та закрита скринька (тестування “чорної скриньки”). Деякі перекладачі буквально перекладають ці терміни як техніка/методологія розробки тестів “чорної скриньки” та методологія розробки тестів “білої скриньки”. Коли постачальники послуг з тестування програмного забезпечення використовують перший метод, вони прагнуть дослідити внутрішню структуру програми і, навпаки, вдаючись до другого методу, вони досліджують функціональність продукту на основі специфікації. Отже, як випливає з назви, тестування відкритого коду відбувається, коли ви заглядаєте всередину коробки, і в цьому випадку вам потрібно знати внутрішню роботу програмного коду. При цьому інженер вивчає код, написаний програмістом, і вносить в нього свої поправки (наприклад, “Якщо значення цієї змінної вийде за межі, встановлені в керівництві користувача, цей цикл буде нескінченним” або “При підключенні до бази даних за допомогою цього методу і після його виконання неможливо розірвати це з’єднання, станеться так, що при якомусь наступному виклику методу з’єднання з базою даних не буде встановлено “). Як можна здогадатися, людина, здатна провести аналіз такого роду, повинна бути одночасно і експертом в області тестування (він повинен вміти передбачити, що може “проговоритися” користувач), і хорошим програмістом. Як правило, до посадових обов’язків QA-спеціаліста whitebox входить написання так званих юніт-тестів. Послуги регресійного тестування виявляються незамінними для того, щоб переконатися, що зміни в програмному забезпеченні не мають небажаних побічних ефектів.
Тестування закритого коду є найпоширенішим завданням і, знову ж таки, як випливає з назви, воно не передбачає можливості доступу до вихідного коду програмного забезпечення. На щастя чи на жаль, в цьому світі немає нічого абсолютно білого або абсолютно чорного. Тому існує поняття напівпрозорого тестування у сфері qa (gray-box testing). Воно має місце, коли тестувальник може лише частково зазирнути всередину коробки. До речі, автоматизація процесів тестування якраз входить в цю методологію. Напіввідкритий код означає, що тестувальник знайомий з архітектурою (наприклад, зі стандартною схемою промислових (ПЗ корпоративного рівня) додатків: Oracle - WebLogic - JavaApplet) ПЗ; він може зайти на сервер і переглянути журнал виконання; він знає структуру моделі даних для ПЗ, що розглядається, і якщо щось з’ясується, зможе написати SQL-запит для підтвердження результатів, виданих програмним продуктом (ПЗ). Тобто, він начебто не є фахівцем з комп’ютерного програмування (як whitebox QA), але в той же час, він вже не тільки тестувальник. Насправді, всіма трьома видами тестування повинні керувати фахівці саме в цій галузі. Послуги мультиплатформного тестування доступні для того, щоб дізнатися, чи є продукти сумісними або переносимими на різні платформи.