Bach Seat

Shh- don’t tell PMI, but as practicing Project Manager’s we all know that resources are limited. Sometimes the PMBOK process just won’t work. Resources are limited. One of the most limited resources I see is testers. After all, nobody wants to pay for someone to try to break things all day long – That’s what users are for. That is why a Project Manager can find themselves taking on the additional task of validating and testing software.

For the uninitiated, there is a difference in mindset between validating and testing. When you are checking that the finished product meets your project requirements, you are validating.

• Add a new customer? Check!
• Edit a customer? Check!
• Don’t permit deleting customers who have transactions associated with them?

Testing, however, shouldn’t be so structured. And there are some good tricks from Stout Systems that a project manager can rely on to find some bugs.

Do stupid stuff

When writing code, developers know what kind of data is supposed to go into a field. Good developers will error-check to make sure that stupid data isn’t being entered. But that doesn’t always happen. So when testing, try to enter numbers where letters go or letters where numbers go. Try to enter symbols—especially symbols that are used in programming like the various kinds of brackets <> or {} or () and the various punctuation marks like ! or @ or # or &. (rb– Make your CISO happy and read up on SQL Injection attacks and try a few of them.)

Another stupid thing to do is to be click-happy. Click on one control and then another control before the application has a chance to execute the first action. Impatient users do this all the time, as do users who have mistakenly clicked the wrong place.

Get two copies of the same web page open, delete something from one place, and then try to edit it in the other place. You’ll blow it up most of the time, and get an unintelligible error message.

Open a page up, do nothing, click the SUBMIT button. You should get validation errors that tell you that you didn’t fill in the required fields. But an amazing number of times the application will just blow up on you with another unintelligible error message.

Regression test

One of the most common problems in software development is that adding a new feature causes something else to break. Regression testing is testing what was there before to make sure that it still works—just as it did before. If you were previously able to add, edit, and delete customers—but only if no transactions were associated with them—then by George you should start your testing by making sure that you can still do this.

This should include using test records that you created before, too. So you add a new customer, edit the newly added customer… good, still works. Now open up a test customer you created previously. Can you still edit it? Maybe not! The new feature may have added fields to the database. The old records don’t have any information in those fields—but the information is marked as required—and the application cannot handle it.

The author points out that one of the biggest shortcomings she has witnessed in developer testing is that they test the new feature, sometimes with many use cases, but they don’t go back to validate that everything from before still works. It is lazy, lazy, lazy not to have someone on the team regression test the full application unless you are certain that the new features couldn’t have touched the old ones. But…hmm…are you really certain?

Look at things like a user

Developers are notoriously bad at certain niceties. Deliberately produce error cases and then read the error message that you receive. Is the message in techno-speak or is it easy to understand? Does it have typos? Grammatical errors?

Are the labels for the controls properly spelled? Is the capitalization consistent? The author says she often sees a mix of title case (where nearly every word is capitalized) and sentence case (where only the first word is capitalized). Some developers capitalize every word they think is important. Let’s face it: they didn’t major in English, so they shouldn’t be expected to get these things right. But there is no reason the application should be released widely with such simple-to-fix mistakes.

Look at the user interface itself. Are columns aligned in the layout? Are the margins uniform? If there is a style guide, is it being followed (the right colors, the right fonts, the right point sizes, the right button types, etc.).

Can you understand what you’re supposed to be doing? Sometimes a simple thing like changing the text used for a label on a control makes a big difference. And sometimes adding a tool-tip with an explanation that’s too long for a label makes a big difference.

Then check out the workflow

Can you actually get around in the application? Or do you need more navigational controls to take you where you want to go? If it’s frustrating to you, then count on it being frustrating to an end-user.

Use IE. The article says most developers prefer Google Chrome, so that’s the browser where all of their testing is done. He makes it a habit to do all of his testing in Internet Explorer. Each browser has peculiarities, so this exposes a number of bugs that developers never encounter. (rb- Will you have control of what browser the users will access your site from? Don’t forget about older versions, Firefox, Safari, IE 9 anybody?)

None of the things that are described above are rocket science. A good tester is going to do things substantially more like a rocket scientist than a Business Analyst or Technical Writer will ever achieve—test automation, database comparisons, validating data outputs, calculations, etc. But all the areas above, when tested and fixed, go a long way to improving the end user’s experience and acceptance of the released product.

Rb-

This kind of software testing will help the team develop much less fragile or brittle code. That saves a lot of heartache in the long run.

Happy bug hunting!

Related article

• How to manage the fear of change in IT projects (CIO.com)

Ralph Bach has been in IT long enough to know better and has blogged from his Bach Seat about IT, careers, and anything else that catches his attention since 2005. You can follow him on LinkedIn, Facebook, and Twitter. Email the Bach Seat here.