Code Coverage with Manual Testing

Here’s a tip. Want me to write about something in particular? Ask me a question. It’s that easy. Tim Coulter had a question about my last blog post. He asked:

Would love to hear how you check code coverage of manual testing, actually. Is that just “feature coverage” (break it up into logical blocks and test those)?

I realized that a lot of people may not be measuring code coverage during manual testing – but it’s quite valuable to do so, as measuring code coverage still helps you find missing tests.

Let’s consider a silly command line app that does math operations. It takes 3 parameters, the first two are the values to operate on, and the third parameter is the operator to execute. For example, a command line of 2 3 + would return a value of 5. Let’s test it (manually).

c:\example>calul8r.exe
Usage:
calcul8r [value] [value] [operation]
for example:
  calcul8r 4 2 +

c:\example>calul8r.exe 2 3 +
The result of 2 + 3 is 5

c:\example>calul8r.exe 4 2 -
The result of 4 - 2 is 2

c:\example>calul8r.exe 5 5 *
The result of 5 * 5 is 25

c:\example>calul8r.exe 15 3 /
The result of 15 / 3 is 5

 

OK – looks like it sort of works. But are there test cases we forgot? Let’s look at what code coverage tells us.

1 int DoMath(int val1, int val2, int valOperator)

2 {

3       int result = 0xbaadf00d;

4       switch (valOperator)

5       {

6       case ‘+’:

7             result = val1 + val2;

8             break;

9       case ‘x’:

10      case ‘*’:

11            result = val1 * val2;

12            break;

13

14      case ‘/’:

15      case ‘\\’:

16            if (val2 ==0)

17            {

18                  printf("Invalid input. Cannot divide by zreo");

19            }

20            else

21            {

22                  result = val1 / val2;

23            }

24            break;

25

26      case ‘-‘:

27            result = val1 – val2;

28            break;

29

30      default:

31            printf("Unknown oprator – %d\n");

32            break;

33      }

34      return result;

35 }

The “meat” of this app is in the DoMath function, and the results show that I missed a few lines of code in my first round of tests. The first two lines I missed (lines 9 and 15) are a bit of discovery. It looks like the app can take the letter x as well as an * (asterisk) for multiplication, and a backslash (\) as well as a forward slash (/) for division. The functionality is the same, but it’s interesting nonetheless.

Oh – but I was stupid and forgot to test for divide by zero. It’s nice that there is some error handling for that, but if you look closer, you’ll see that executing this particular test would reveal a typo in the output string.

I also forgot to test with an invalid operator – and wouldn’t you know it, there’s another typo there. What I’ve done is used the code coverage data to guide my design for new tests. This app is simple, but the idea works on a larger scale too. I’ve known testers to discover large areas of functionality they weren’t aware of before, or (more often) hidden functionality within the areas they had tested extensively.

An important thing to remember is that once I’ve added those test cases (and reported those bugs), is that I’ll have 100% code coverage. Remember though, that 100% code coverage doesn’t mean bug free. In fact, this app doesn’t check for integer overflow. Sure enough, check this out:

c:\example>calul8r.exe 2147483647 1 +
The result of 2147483647 + 1 is -2147483648

Oops! Remember – just because the code is “covered”, it doesn’t mean it’s tested. Please don’t forget that (and don’t let your managers forget either).

Thanks Tim, for prompting this post – I hope you (and others) find it helpful.

Similar Posts

  • Oh, the places I’ll go

    I’ve been attempting to travel less recently, and I’m happy to say that beyond early November, I have no (work related) travel plans anywhere on the horizon. For better or for worse, I’ve had a deluge of great opportunities converge over the next thirty days.(for those of you who may be experiencing déjà vu, I…

  • The Secrets of Leadership

    Yesterday, Michael Larsen posted a review of Weinberg’s book, The Secrets of Consulting. I’ve been meaning to share a few thoughts about this book for at least year, so I thank Michael for spurring me to finally share my thoughts and experiences with TSoC. If you haven’t read this book, I bet it’s because the…

  • Who are you?

    I’ve been thinking about how professional testers describe themselves. We have high level labels like Tester, SDET, or Quality Engineer, but beyond those (mostly meaningless) titles, many of us have our own personal missions or visions – the words we want people to associate with us. For example, my twitter bio is, “Long time software…

  • Trust and Testing

    I threw out a few trust-based tweets this week. I’m a big fan of #trust in the workplace – hire smart people, coach & guide them, but give them plenty of freedom to do the right things You don’t have to (and shouldn’t) involve everyone in decisions. But build trust by sharing why and how…

  • Test This

    The “Test This” game pops up frequently in testing circles. Sometimes it pops up in the “How would you test a …” variety – e.g. How would you test a stapler. Participants in the game are expected to come up with functional tests (can it staple), as well as “out of the box” tests like,…

3 Comments

  1. This is nice little piece for showing how code coverage can be measured for a manual test of a simple command line based calculator. But how do I answer the question for “what’s the coverage of your testing?” for a multiple component-based application, consisting of a C/C++ major component, an application server, and customized business logic? Is there any way to get down to the code coverage level from a business perspective, or is feature/business rule coverage more appropriate here?

  2. I am looking for a tool that measures code coverage of manual testing for a PHP application. Similar to how XDebug can measure the code coverage of unit tests and produces an output, I would like to be able to tell my environment when to begin measuring code coverage, perform manual testing on a development website(i.e. login and place an order as a registered customer), end measuring code coverage, and produce an output similar to what you have shown in this article.

    Are there any tools that you can recommend that do this for PHP websites? I have only seen a tool like this that is part of Visual Studio.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.