This is guest post by STC team member Aparajita Jain. Check author details at the bottom the article.

An ownership comes with the responsibilities. Isn’t it true? When we decide to buy software, the very first thing that comes in our mind is the quality of the software. Without high quality, any software is a piece of junk for which nobody wants to pay or use. Now the question arises, are testers only responsible for the quality or it is a shared responsibility among testers, developers and other team members in an organization?

There are so many testing methodologies developing in the current market. Some are time boxed such as agile methodologies and some are flexible. If I talk about agile, changing requirements make it difficult for a tester to test everything in that time frame. That does not mean compromising on the quality but sharing the responsibility of the product quality among the other project teams too. Life would be much easier if the requirements would be clearly defined by the business analyst, developers have done some basic testing before handing over the application under test to testing team. In my opinion, it is a combined effort.

The following are some of the important key factors for the quality of the software:

1. Automation is the testing future: Automation saves our time on repeated test cases and focuses more on the REAL testing. Here, real testing means testing the new or improved features. For example, we know regression test is something which needs to be run repeatedly. Whether it’s a new change or a fix for an issue, we have to run regression to make sure nothing is broken while integrating that change into the system. It is always a good idea to automate regression if possible, it would save a lot of time for testing effort and tester can focus on the creation of new test cases and scenarios. Also, load or stress testing should be automated with the help of sophisticated testing tools such as Load runner, etc. to conduct the baseline and benchmark testing regularly since they are difficult to perform manually and do not fit the agile model of short sprints in order to catch up strict timelines ensuring the product quality.
2. The best time management: Time management is the key to low down the risk. When we release different versions of the software in a very short span of time, it is likely to be on the higher end of risk since time is limited and it has to manage very carefully. One of the major things here is to prioritize the test cases. For example, if a new feature is introduced in the software then that should be done on priority but if there is some major functionality which shouldn’t be affected then priority would change to test the regression and then the new change. And finally all the other areas should be covered. The bottom line is that, the testing team should able to cover all the test cases starting with the test case that has the highest priority to the lowest priority in the descending order. The benefit of this approach is that the probability of finding the defect is higher when we do testing on priority basis. The earlier detection of defect in the product gives the ample time for the development team to fix and get it retested without impacting the release timeline or the sprint deadline for the agile model.
3. Get involved the testing team in the early planning and development phases: Yes this is helpful. If the testing team is involved from the early phase, then they are more likely to understand the process and requirements very clearly. This would help them to write the test cases better and also improves the overall test coverage. They can give their input in planning which would make the overall process easier and every team would be on the same page. A good understanding of the project requirements to the testing team will help in fetching a quality end product after testing that project by such team.
4. The exploratory testing: It is very important especially when you have new features to test. Exploratory testing not only gives you confidence about the product but also, finds some of the difficult bugs. When you are short on time and really want to have an overall verification of the feature and the system as a whole then exploratory testing is the way to go. Again, I would like to add the dependent factor here; exploratory testing can only be proved effective if tester has the understanding of all the requirements clearly. So involvement in the planning phase would be beneficial and obviously the overall project experience of a tester about the product under test in that testing team matter a lot here.
5. Testing team skillset: The skillset of the testing team should be carefully considered. I don’t want to confuse you with the word “skillset”. Let me explain the meaning of this, skillset refers to the expertise of a person. For example, some testers are very comfortable in performing manual testing or exploratory testing whereas some are comfortable in using automation tools or writing automated scripts. In my opinion, the testing team should be a balanced mix of both: manual and automation. When you have a balance of both the worlds, you can manage your testing time accordingly without compromising the quality of the product. For example, repeated test scenarios can be given to the automation team to automate and meanwhile manual testers can test other areas. This mix of the skillsets will definitely help in fetching a quality tested end product.

Conclusion:

As I have mentioned earlier that, defining the clear requirements (business analysts), setting practical deadlines (project managers), performing unit / basic testing (developers) before handing over the software are some of the steps which could be taken by different teams or team members in order to contribute to the overall quality of the software. Once we understand this shared responsibility, productivity and the reliability of the software product will improve. By practicing this, we can never blame that the defect identified post product release was the sole responsibility of the Quality Analyst team as that will be the shared within the team that aims at delivering the quality end product.

About Author’s:

Aparajita Jain is a Senior Quality Analyst and a technical writer with more than 6 years of experience. She has expertise in test automation in various platforms Java, Ruby, and Python. She loves teaching and sharing knowledge through technical writing. Currently working full time as Lead automation engineer in one of the leading banks in Canada.

Happy Testing!!