So my manager, from what appeared to be a whim, recommended that I take a class on White Box testing techniques and give a presentation to my team. Eager to try something new I obliged. However, at the time I was unaware that the class would have a four hour sessions every day this week.
Anyways, I just finished with ‘module 2’ and it has been simply amazing. So many ideas, so little time to implement them all!
So what is White Box testing you ask? The opposite of Black Box testing of course 😉 Well actually, a good description of Black Box testing will help for our discussion.
Black Box testing is testing where the tester assumes no knowledge of how the application works. Testing therefore is mostly focused on user inputs and expected results. So Black Box usually takes the form as core functionality testing. It is crucial because more than 80% of the bugs you find are discovered through Black Box techniques. (User-perspective bugs.)
White Box on the other hand is testing where you try to integrate aspects of the code as closely as possible. Code coverage, function verification, Unit testing, etc. (Developer-perspective bugs.)
Previously all a tester could realistically do was Black Box testing. Unmanaged code and White Box testing is possible, just a huge pain. In the new, managed world however White Box testing is in some cases easier than Black Box- thanks mostly to our friend System.Reflection.
I could easily write a book on how much you can do with just System.Reflection to automate tasks in Managed Code but I will leave that for another day. (Besides, there are still two more sessions to go to, so who knows what new awesome things I’ll learn about tomorrow!)
When I am done with the class and have my presentation prepared I’ll be sure to post the notes!