I was thinking for a solution to the question what should be the team composition to cover the maximum possible test scenarios that can be thought of, while testing an application/product. It was then that the idea of different people testing the same application in different perspectives came into my mind.
Different people always have different personalities and the same leads them look into things in with a different mentality. Once when I asked a person involved in embedded testing whether he wanted to look for a job into the application testing, the guy furiously refused it. I have had a similar experience from another person involved in application testing, regarding website testing. Another incident, which I have come across many a time, is that people get adhered and addicted to the environment that they had been working for a certain time period. There has been many a time that I listened to people complaining about the new work places due to be using some management application, just because they have been comparing it with the application that they used in their earlier company.
What these made me understand is that people become biased to the type of work that they do. If a person is involved in testing a Visual C# Application for some time, he molds his thoughts to such a direction where all applications behave in the same way that the applications he had been working with. This is a common human mentality, because we always make things to become habits.
Now, when I thought of a method in which we combine the efforts of different people who have different skill levels and domain backgrounds, into testing an application along with some who have been testing the application, it let me make some sense. I thought putting together some people from different domains into one test team, which is testing a totally new product, could prove better than a team of common minds. The thoughts and principles that testers from different backgrounds follow are different and this brings in a lot of variety in testing, once these people come together as a team. If a team which is testing a gaming application includes telecom domain testers, web application testers, network testers etc., then the coverage of testing would be overwhelmingly better than one could imagine. Of course, one thing that is implicit is that, it needs each to be good in their respective fields.
I tried this idea practically into one of those projects that we undertook for an IPTV application. That experience boosted my confidence in this ideology to a great extent. We were only a group of two along with the original testers who were involved from the beginning. Both of us had experiences from the past which are of different backgrounds – one a web tester with experience with different domain accounting systems and the other, experienced in embedded telecom devices, banking applications etc. Together, we were able to test the application and make the product owner change the work-flow a couple of times. The main reason, now I understand, is that we, having expertise working in different domains, were able to create and execute diverse scenarios which were unknown to the other fellow testers. Although the product owner had to change his architecture couple of times, this helped him deliver a product in which his clients, with their own test team, couldn’t find a single bug. This resulted in increased confidence of the client on us, helping us to bag some more projects of the same kind.
There are certain things which need care, while we deal with teams including testers from different domains. It is the fact that the team selection needs to be very even; else it may lead to the testing getting diverted into a single way more and the application development getting affected. A good management should always be able to handle this, because this is common with all teams. I would like to try and implement it in a more projects. Mixing and applying multi-dimensional thoughts for testing an application could prove much more worthy than the usual strategies.