White Box Testing Vs. Black Box Testing
A casual analysis of software testing tends to break it down into main categories -- black box testing and white box testing. This distinction a bit strange though. Does it really exist? Do we really need it?
White Box and Black Box Testing Seem Opposite
White box testing and black box testing seem to be completely opposite each other based on name alone, but what do the terms really mean?
A black box means that you cannot see, or do not have access to, any of the inner workings of the product. You experience and test the product at the exact same level your customers do, the user interface.
Black box testing is a lot like inspecting presents on Christmas morning. You walk up to the tree and see packages stuffed underneath the tree, each wrapped and labeled a little different. You can pick them up and feel how light or heavy they are, or shake them and hear the insides rattle around, but you don't get to see what is inside (till a little later at least). Your whole perception of that package is based on information you get from outside of the package.
Basically, you can do anything you want.
The point is that you go deeper than the user interface. As deep into the product as you need to go in order to learn what you need.
The Technical Side of Testing
Software testing happens on a spectrum in most ways -- approaches, techniques, and distinctions like black or white box.
Other times I'll use frameworks like frisby.js to help me test a part of the software that lives below the UI, the API.
My focus is on using the appropriate tools to learn important things about the software I'm testing.
A lot of testers tend to be more comfortable when doing less technical work, at least early on in their careers. The closer they get to the black box part of the spectrum, the more comfortable they are.
It is hard to deny that our field is asking for more and more technical people. Take a look at some local job advertisements and count the number of positions focused on test automation, or performance, or have the acronym SDET somewhere in there.
Learning these technical skills in addition to being a great tester means you can move around the spectrum as you please; it also means that you will discover more and better opportunities when looking for a new job.
Software Testing Terminology
The truth is that this distinction has never really mattered. No one ever stops before opening Chrome Developer Tools and says "OK, Grey Box Testing! All teams go!". The change over from treating a product as a black box, to digging deeper bit by bit from the document object model (DOM), to the database, to the source code, happens fluid as you need it. I can't ever recall a time where I had to report on whether I was doing white box, black box, or something in between during a status meeting, in a bug report, or when explaining strategy to executives.
There may have been one time, a long time ago, where I was asked about the definition during an interview. Now that I think about it, we mostly talked about definitions during that interview. I still ended up with a job offer despite not having the exact definition they wanted.
There is no standard language in software testing, we are still developing as a field. Black box and white box are abstractions, words we use to describe to describe very general things, like the economy, rather than concrete ideas. What does matter is that when I (or you) hear phrases like this, we ask the question "What do you mean by that?".
Immersing Yourself in Developer Culture
If you currently find yourself testing mostly on the black box part of the spectrum, now might be a good time to start getting a little more technical. I have found a lot of people do this initially because someone, probably a manager, told them they need to automate testing, but that is a difficult path. Starting from the technology, tools tend to treat the browser or application as a black box - start it up, send it data, and see the results. This has a steep learning curve for people that have never written code because, as you have learn and apply so many new concepts all at the same time.
Personally, I started moving more toward the white box side of things by immersing myself in developer culture. I attended code reviews, went to local developer meetups and conferences, and tried to hang out with developers more daily. This allowed me to absorb terminology, concepts, and attitudes about terms and languages really quickly. After being immersed for some time, I picked a project, a small one, to work on. Since I had been around the conversations for a while, when I had a problem at least usually I knew what questions to ask. If I didn't, well I had developed a relationship with some developers and they were a little more willing to help out since I showed real interest.
Now that you know the spectrum exists, maybe you can spend some time going deeper. Learning to be technical is a lot like learning to play an instrument; no one ever regrets the decision.
Deliberate Application Testing in Agile with Dan North
Testing in an Agile Environment
WebRTC and Its Impact on Testing