The author will show you how to organise work on product testing. As the QA Manager one can have own personal choices of features and changes but your main job is to get a starting idea of what resources and how much time you will need to get the new release tested according to your company's high quality standards. He presents the Grantt table and all what is needed to make you work easier.

Preparation is the Key: Things to do, and not to do, when you are told that your product is going to be developed across multiple platforms.

 

You walk into the requirements meeting for the next major release of one of your company's products. Everyone in attendance has their laundry list of features, enhancements, and changes that they feel need to be added to the product for this release. As the QA Manager you have your own personal choices of features and changes but your main job is to get a starting idea of what resources and how much time you will need to get the new release tested according to your company's high quality standards. The Vice President of Development opens the meeting by announcing that, while everyone will get their chance to give their input for new features and fixes, it has already been decided that this release will include native GUI clients on all supported platforms added to the Windows client that already exists. In order to add these platforms the underlying windowing code will be converted from MFC to Qt in order to support the new clients. Also, since many of the company's customers are worldwide, the product will now support the Unicode standard for native language input. Your brain begins to work furiously trying to calculate all of the combinations and permutations that this particular scenario has just produced. Just before your higher brain functions shut down from overheating you hear one last phrase: Our target release date is 9 months from concept design.

Now is the time when you should close your eyes, take a deep breath, and repeat my favorite mantra: Don't panic… don't panic… don't panic… . Actually, there really is no need for panic if you know how to prepare yourself, your team, and your resources for this Herculean test effort.

First prepare yourself. Whether you are a QA Manager, a lead tester on the project, or the developer who is assigned to organize the company's testing you can get through this in an organized manner.

Gather a list of all platforms that are expected to be supported by the new clients. Windows has XP, 2000 Server, 2003 Server, NT, ME, and 98. You may decide not to support some depending on what systems your target customer base is operating on. Apple has OS X over several versions. If your list includes Linux then be prepared to ask some tough questions. There are many, many different distributions each having many different versions. My suggestion is to pick the ones you feel are being used or are most likely to be used by your customers and test against them. One method that we developed for testing a large number of Linux distributions is to pick five distributions (we chose SUSE, Mandrake, RedHat Fedora Core, RedHat Enterprise Linux, and Debian) and perform full release testing on the most recent versions of those platforms. Earlier versions and other distributions will get a limited regression testing every year to insure that we can still support them.

Insure that you create test matrices for all new, changing functionalities in the release. This isn't just a list of things to test but a spreadsheet that takes into account the functionalities, platforms, required database integrations, integrations with other programs, etc. An example test matrix is shown in Figure 1. Have this matrix reviewed but several people from different departments such as QA, development, support, and sales. Yes, I did mention sales. Sometimes a person who is more removed from the effort is the one who will catch exclusions from the list. They are also likely to have "pet functionalities" that their customers have been asking for that may be in the release and they will be happy to make sure that particular item is getting tested.

Figure 1. Sample Test Matrix

Now that you know the scope of your test effort your will need some way to track all of this work as it is being done. In my case I found that one of the things I hated the most became my most useful tool… the Gantt chart. I never fully understood their usefulness until I had to track several parallel efforts going on at once with a limited number of resources to perform within those efforts. If your company runs a Microsoft shop then you would probably use Project as your planning tool of choice. For those of you with a bent toward the open source world might try Planner (formerly MrProject) which is a Gnome desktop application. KDE also has a tool in development named KPlato but as of this writing it hasn't yet released version 1.0. More about putting the Gantt chart to good use a little later.

sum:

0 €

» Library of the Month
» Workshop
» Software Engineering
» Programming Tools
» Interview
» High quality and
secure programming
» Reverse Engineering
» Portable GUI
» Artificial intelligence