White box testing, also known as glass box or clear box testing, is testing that takes place where the testing had working knowledge of the code. In the AST BBST Foundations course, glass box testing concerns are illustrated with the question, "Does this code do what the programmer expects?" This is in contrast to the black box concern of, "Does this product fail to do what users -- human and software -- expect?"
From a learning perspective, this can mean a number of things. Testers working at this level are often comfortable with programming, hardware, networks, databases and application servers. Depending on the software, specialized knowledge of certain programming techniques or specific technologies may be required. Examples could include custom protocols, effective use of connection polling, language-specific test frameworks, among others.
Here's what I normally recommend for people getting started down this path:
- Learn the basics of computer science: You can do this through schooling or through some well selected books with a good self-study ethic. I recommend looking for entry-level courses and books on computer organization, networking, databases and file systems, data structures, assemblers/compilers/interpreters, algorithms, and discrete mathematics.
- Get comfortable working in a language: Today, I favor Ruby. But I taught myself Pascal as a teenager, learned C/C++ in college, and used Java in my first job as a programmer. It doesn't matter what language you learn -- just get fluent. You need to be comfortable enough that you can turn out simple programs rather easily and you need to be able understand and follow more complicated code -- even if you couldn't write it yourself.
- Practice writing unit tests, stubs, and harnesses: As you learn a language, you'll want to be sure you learn how to do unit testing in that language as you progress. The reason isn't so you can write better code yourself -- that's a happy side effect -- but so you get comfortable looking at and editing those types of tests. Similarly, as you start to practice testing, you're more than likely going to encounter situations where you'll want to mock out part of your test. This is a common pastime for white box testers, as they often use custom stubs and harness to mock out parts of the component their testing or to add more visibility to the results of their testing.
- Download and play with tools: This type of testing usually involves some tooling help if you plan on getting anywhere fast. Anything from your common runtime analysis tools (memory profilers, performance monitors, code coverage tools, etc.) to simple static analysis tools can help you learn the lingo and can get you thinking about common problems in white box testing. There are several good open source sites where you can find tools in this area; I currently favor opensourcetesting.org.
- Learn about security testing: Get to know your buddies at the Open Web Application Security Project (OWASP). You can think of security testing as a capstone project for white box testers. Not only is it a practical application of the skills and tactics that make white box testers successful, but it pulls together everything else you're learning. If you work through the OWASP materials, you see that you'll need to understand a lot of the computer science materials. You'll need to be able to read code. You'll need to use tools -- lots of tools -- and it will be helpful to be able to write your own simple scripts. I find that OWASP makes all of their material accessible to the beginner or near beginner). They also have local groups -- perhaps in your area -- where you can get some peer support for your learning.
That should be enough to get you going. If you make a regular diet of alternating between those five areas you'll become a pro in no time. As you learn, share what you're learning with some programmers you work with. You may be surprised at how supportive they will most likely be, and more than likely they will start to look for opportunities to start pulling you into their testing and debugging work.
This was first published in August 2008