Why take a Black Box Software Testing course?

I was recently telling a friend about the BBST Bug Advocacy course I was working on and he asked why I was taking a black box testing course. I think what he meant was why would I take a course on black box testing as opposed to glass box (or white-box) testing?

This is the more thoughtful answer I wish I had given.

I fell into the testing profession. The University I went to taught some technical skills as part of the degree (programming, database design, etc.) but I never learned anything I would consider fundamental to understanding software testing, nothing that helped me deal with testing problems. Since I work in software testing I wanted to learn more about the domain, to better understand it and be able to differentiate between testing and other types of problems (technology, communication, requirements, etc.). It just so happens the courses that focus on the domain of software testing also focus on black box system level testing.

Black box and glass box testing approaches focus on different things. Black box is testing and test design without knowledge of the code. A black box tester will approach testing based on the interactions of the stakeholders with the system’s inputs and outputs. Contrast this to glass box as testing and test design with knowledge of the internal code. The glass box tester will approach testing based on the interactions of the underlying code, as in “does this code do what the programmer intended it to do?”

Testers using either approach can benefit from understanding the domain of software testing. Understanding what oracles are, how they are heuristics, advantages / disadvantages to measurement, how to communicate and write bugs effectively or even how to design appropriate tests affect both the black box and glass box approaches. That’s why someone would take a black box testing course (specifically the BBST series of courses); that’s why I did.