The Association for Software Testing has recently started offering the Black Box Testing Course, designed by Cem Kaner, James Bach, and Becky Fiedler, as a free benefit to AST members. I took the first round (taught by Cem, Scott Barber, and Jon Hagar) and was very impressed. I expected that any course designed by Cem would reflect a deep understanding of testing – and it did – but what surprised me was the deep understanding of teaching. Pedagogically, this course stood head-and-shoulders above the previous online courses I’ve taken from UC Berkeley Extension and Foothill College.
I’ll write more about it soon, but for now I want to highlight one exercise in particular. We were told:
You are testing a program that includes an Integer Square Root function. The function reads a 32-bit word that is stored in memory, interprets the contents as an unsigned integer and then computes the square root of the integer, returning the result as a floating point number.
And then asked a number of thoughtful questions about what test strategy we would take, how many square roots we would(n’t) test, etc. It’s an interesting problem, and many different suggestions were made. One of common thread was the importance of testing around powers of two, especially just over and under boundaries of 8, 16, and 32-bit integers. Now, Doug Hoffman has an excellent article showing that interesting errors can occur far from any of these boundaries…but testing around powers of two was one of our baselines.
- 850 x 77.1 – 1 = 65534
- 850 x 77.1 = 100000
As a test engineer, I fully understand that not every bug will ever be caught…but it fascinates me that Microsoft‘s test team doesn’t seem to have thoroughly tested the boundary between 16-bit and 32-bit integers. This is of course being discussed on Slashdot, Digg, and many other places. I’m curious how Microsoft’ll react, and what the repercussions will be.