Jul 12

Why Write Test Cases?

There was a recent question raised that asked “why write test cases if you already know the functionality of the application?”   This an interesting point of view that unfortunately is fairly common actually.  I think a lot of people take this perspective because they have so much work to do that taking the time to write detailed test cases becomes very time-consuming and they prefer not to do it.  However there are some very valid reasons why you should write detailed test cases even though you already know the application.

  1. Ideally you should already have a baseline set to test cases that cover your regression testing, but not your new functional test cases – these need to be written as there’s a good chance that you will not be the only tester having to test this functionality, therefore you need to document how to test a feature so another tester can execute the test case if they need to.
  2. Environments following a SDLC methodology normally will produce some form of requirements and design documents for new functionality (all depends on how formal their process is).  For these new projects this is obviously new functionality and therefore not something you know yet.  So using these documents you will build test cases that take you through the process of validating that the functionality was implemented properly.  Likewise you then accomplish building you test case/requirements coverage association/linking in order to be able to assess whether you have address/tested all the requirements for an application/project.
  3. Ideally you will be building automated test scripts.  These should be built to address as much of the manual testing process as possible and the intent is that this would replace any of the existing manual test cases.  In addition, the person creating the automation scripts is not always the same person writing the manual test cases or even performing the manual testing and therefore the automater needs a detailed test case to know what to script.
  4. Having detailed test cases is a great way for a new member of the QA team to learn the application.  I will typically have a new team member execute regression test cases in order to get “hands on” experience with the application.  This process enables them to learn the application, learn our Test Management system & process, and learn the applicatin without having to use up a lot of time from existing team members.
  5. Finally, the position of not writing test cases can be viewed as “job security”, which is viewed as someone not willing to share knowledge in order to maintain the company dependency on a person “as they can’t afford to loose them because that person is the only one who knows about xyz”.  Some people view this as a strategy to staying employeed.  However what this really does is limit your own opportunities.  If you are the only one who knows about a part of the system, then the company can’t afford to have you take on any new responsibilities because no one else can do what you do.  Now you don’t get the chance to go to training classes, take time off, take on a new position in the team or company, transition to a new development effort, etc.  Share the knowledge by documenting the test cases so that someone else can also help out in your area and enable you to take on new opportunities for career growth.


by sloporto | About the author:

Related Posts

  • No related posts found.

You must be logged in to post a comment.

Name (required)

Email (required)


XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Share your wisdom