Recently in Testing Category

There were a number of movies about war that I have watched and they always used a statement "fire for affect".  And in most cases when someone said that, you could expect to see some serious explosions.  So what about testing for affect?  I suppose if you do some and its done right you could see the same.  What a minute!  You do not want to see things blow up in your face or do you?  Well you are testing right?  So the purpose of the test is to fully exercise all facets of your application.  So some bad things may happen along the way.  I have been a big proponent and user to test coverage analysis tools like gcov and tcov.  These tools enable you to find the holes in your testing procedures.  They pretty much all work the same, you compile your code with a flag to indicate that you want to do test coverage.  Then you go off and run through your test procedures (you have these right?).  Once you are complete, you run the analysis tool and it adds comments to your source code file to indicate what items were tested.  In addition it give a test coverage percentage.  The higher the percentage the better job you did in testing.  At my old job, our code have to obtain a minimum score of 85% (then it was 90%) to be accepted for integration.  Now, I know things like this seem ancient to some of you folks.  But they do have their place in higher ed just like they did in the defense industry.  Writing good solid code is only part of the equation, you must make sure its tested well (testing for affect that is).  That is why tools like test coverage analysis and testing frameworks exist to help you make sure you are putting out the best, fully tested product.

That's a pretty good question, isn't it?  Typically a test plan is a document that describes how you will test a piece of software.  Sounds pretty simple doesn't it?  The problem is most people never take the hour or so to write one.  Then when it comes to testing their application, he/she just tests things until they run out of time.  At that point they probably feel that the software is good enough to released.  The problem is, most times the software really is not ready.  There are probably hidden bugs the developer never even dreamed of.  In addition, if its a web-based application, you have to worry about browser support. 

So at this point maybe you are somewhat convinced that having a test plan is a good idea.  OK, so what's next ?  Well the test plan needs to be written very early on in the development process.  How early you ask?  Well before one line of code is written.  Wait a minute, how can you write plan for something that you have not written?   Well the answer is simple, the test plan is based on the requirements.  The requirements found in the specification lay out what the software is supposed to do.  So you write the test plan based on those requirements.  Remember you are at the design phase, so the technical details are extremely abstract.  Test plans that I have written over the years, talked about the testing environment, and basically how the software will be tested.  There is another companion document that typically follows the test plan and that's the test procedures.  The procedures are just that, procedures on how to test a particular aspect of the software.  When you write the procedures, you will specify the test, the expected test results and the actual test results.  If those results differ, you will need to address that problem.

Now at this point, you are probably thinking well this is going to take too much time to do.  And you probably correct.  All good things take time.  What you need to do is tailor the whole plans and procedures to your development process, just like you did with the specification.  If you are in a fortunate situation to have a dedicated testing person, even better.  The test engineer should be the person testing the code, not the developer.  The developer is too intimate with their code and if he/she knows a problem area, may avoid it during testing.  The test engineer on the other hand is there to test code.  He/she really doesn't care about the feelings of the developer.  In essence the test engineer is looking out for the customer's needs, because its their requirements that must be addressed.

With all of this said, I hope you realize how important it is to have a test plan (how formal it is, is TBD), but just having a plan is a start.  Testing by throw darts at a board really isn't going to prove that the software meets the user's requirements.  Because after you run out of darts, you walk away...