License To Crack - Product Company vs. Project Company

A Project company survives on the number of contacts that the company has and the number of Projects that the company gets from other forms. Whereas a Product based company's existence depends entirely on how its product does in the market.

A Project Company will have the specifications made from the customer as to how the Application should be. Since a Project company will be doing the same kind of Project for some other Companies, they get to be better and know what the issues are and can handle them.

A Product company needs to develop it's own specification and make sure that they are generic. Also it has to be made sure that the Application is compatible with other Applications. In a Product company, the application created will always be new in some way or the other, causing the application to be more vulnerable in terms of bugs. When upgrades are made for the different functionalities, care has to be taken that it will not cause any other module to not function. When any functionality is being implemented, have to make sure that they are introduced in such a way that it will not cause problems in the future for up gradation and for implementation of any other new functions.

Challenges in testing

To report a mistake on someone else's work, is not that easy. People often feel hesitant to do that criticism. By not telling the mistakes, they do more damage to the work and the person who did it. It depends wholly on how you convey the issue rather than what you convey. There are people, by nature, who blame and who do not blame. When it comes to testing, we need to get rid of that subtle human mind block and call a spade a spade. Getting this mind set will be the first challenge.

The issues in software often surface as we start using the software. When a problem is identified when the customer uses, that puts more pressure on the people who tested the software and certified. This leads to project post-mortems late in the development cycle and it may even cause client dissatisfaction. So drawing the boundary of testing is another challenge.

Most of the fresh people who form the majority of the IT work force, do need action on the software. When a person codes, he/she sees the software running in front of the eyes; whereas in testing, you need to think a lot and document a lot. Many people are not used to this in their academia. This causes a discomfort in people and this takes time for people to gain the expertise of test planning.

The management teams always face time delays and pressure on testing. When sufficient time is not provided, the testing may not complete. The management will think of just completing the project schedule but may miss the project quality.

There is a great amount of difference between the service companies do testing and the product companies do testing. When people move from one type to the other, it takes time to adjust to the processes adhered by the companies. Process orientation is a human challenge every company faces.

In most of the countries, getting seasoned testers is a major challenge. Get the guy who cracks every software - very easy to say, but where are those guys? It takes a longer training period to create such a good code cracker. The reason is that the testing is more of a mind process and it involves a better understanding of the software than the creator of the software.

Tune your mind

Hope you had used the remote control to operate the television and the video player. Imagine that I sell a remote control unit to you and you want to ensure that it works perfect, before you pay me money. How will you test it?

Wait, do not start actually testing it. First write it down on a paper, a set of things that you will test on the remote control. How long do you plan to test the same? What else you need to test the remote control? Spend about 30 minutes and see how many tests you had written down.

You can observe a few things like this. First 10 minutes, you could have got a lot of ideas flowing in your mind and you would have written more tests. Then you could see some slow down in that process. During the last 5 minutes, you might have written only a few. Isn't it? You could see jump of thoughts when you read what you had written. Fifteenth point and sixteenth point, are they related to each other or different from each other totally? For example, 8th point would be to test the battery life and 9th point would be the forward option in video player panel. The tests will not be coherent when you read one after the other.

After 2 hours, you read what you had written. Do you understand what you had written? Or are you getting a doubt of why we had written this? Now, ask another person to read what you had written. Does that person understand what you had written or he/she has difficulties in understanding what you had written?

Now do this exercise, and spend 30 minutes for writing the tests for a lift (elevator), mobile phone, and microwave oven. You will see a change in you. What is that? Clarity in thought.