Testing.....WHO? ME?

Testing.....WHO? ME?

Being into the IT industry for the past 4 years now has given me a fair idea of testing and the advantages it brings with it. But one thing that I have never done is thinking about what would be the best way to design a test case document, is there any formal definition of a test case, what all should a test case not have and so on.

Recently when I was given this responsibility of managing a project, i really thought of giving it a thought. We were supposed to implement ISO 9001:2000 in our project and this meant documenting each and everything, and test cases form an integral part of the software development life cycle. So, let me rephrase the statement as "I was FORCED to give it a thought".

A test case is an entity which fully tests all the related aspects of a requirement in an application-be it functionality, be it UI, be it database. In other words, it tests ALL the aspects of a feature or requirement. It includes:

• The reason why the test is being done.
• The process that would be followed for doing the test.
• The scenarios that would arise out of performing a particular test.
• The criteria which would decide when a test has failed.
• The criteria which would decide when a test has succeeded.
• Any specific software and hardware requirements for the test.
• The assumptions that have been done in order to write the test cases.

This is too much of work to do-right? So, then who knows about the project so much that he can write the test case document? The project manager? Does he have all the time to write these test cases? I dont think so...I can feel this now that I am doing project management. In most of the cases, it is mostly a Quality Analyst/Engineer or a team of QAs who sit down along with the Project Manager/Leader, understand the functionality of the entire task and then accordingly write the test cases. Once the test cases have been put down by the QA team, the document has to be reviewed by the peers.

Figure 1.0 lists a sample detailed test case document which the QA of my team Vidya Nair wrote for one on the various modules of the existing application I am working on.

Once the test cases have been reviewed by the peers, it should function as a tool to help the developers in their development. This is one reason why I believe a QA team has a BIG role in delivering the product bug-free and with the best quaity on time. One of the issues, which stops a QA engineer from coming up with a good test case is the plethora of information available to him/her. The key here, I guess is to "work smart"-Pick out the most important scenarios and frame your test cases accordingly-think about the scenarios which are critical for the application to function and work on them first. Then, if you have sufficient time, you can work on more test cases having a lower priority.

Some basic rules of development

Some Basic Rules of Development

1) A development team should have a single design authority. The best systems have one member of a team who dominates the design and development and has a clear view of where the system is going. Without this strong focus and lead, many projects throw together a set of conflicting ideas and the system will ultimately stagnate or become extremely difficult to maintain. This person needs to be big on communication and small on ego.

2) Code should be documented, but not overdocumented. Lots of documentation does not equal good design and will not guarantee a good, well designed system. A system can have a good design even with minimal documentation. Especially, keep in mind that the initial set of documentation is for the DEVELOPERS THEMSELVES.

3) Good people build good systems, bad people build bad systems. No amount of processes or documentation will change that, it will only make a relatively small increment in system quality. The overwhelming factor in developing a quality solution is to hire good people. NASA statistics have shown productivity differences of 1000% between their best and worst people.

4) Design for change and flexibility. Things will always change, do not tie your system to rigid principles or business processes that change frequently. Break your system up into its OOP oriented objects and define them as early as possible in the development cycle. Make sure everybody on the team understands what the objects are and what their purpose is, and how they will interact with each other.

5) Don't build a foundation on a sand dune. The first few steps in the project are usually the most critical: the choice of tool, platform, architecture etc. If the wrong choices are made, it can result in a lot of rework and will destroy the motivation of most development teams. If you find early in your process that a decision may have been wrong, be smart enough to change it instead of attempting to "Band-Aid" it into functionality.

6) Keep it simple, don't build in complexity that doesn't need to be there. Don't spend time making the system portable if it doesn't need to be. If you're using SQL 2005 and are going to stick with it, use all the SQL 2005 specific features you like. "Explicit code is easier to understand, which makes the code easier to modify" -- Martin Fowler

7) Use accepted and well-known technology. Niche tools/technologies are expensive, lack support and it can be difficult finding people with the right skills, particularly a couple of years later.

8) Deliver often. A project taking more than 6 months before delivering software will likely fail and the reasons for it being built may not even apply anymore. Delivering often provides good targets for developers and good visibility for the system in question. If you have 3 Alphas and 6 Betas over a short period of time, that's better than no Alphas and one Beta. User feedback is extremely important in being able to be flexible enough to make mid-course corrections.

9) Don't add extra people to a team to try and speed up development. Increasing the size of a team mid project will almost certainly slow development down. A team of 4 to 6 developers is enough for most projects. Large projects should be broken down into small development teams of this size.

10) Use of industry-accepted development methods: object-oriented design and modelling, well-structured development process, unit testing, sound documentation, use of version control tools, project management tools.

11) Communicate often within the team. You don't need four different people each creating their own Data Accesss helper class when if they had all sat down and discussed it first, everybody could all be using the same one, with better features.

12) Above all, do be nice to your development team. Developer turnover in the middle of a project can really send expenses through the roof, and morale down the toilet.

~Peter Bromberg