How to improve QA team's product knowledge

Generally in Product QA team, manager/lead assign some components/features to each person and they become an expert on that feature. Each team member should have the knowledge on the entire product not only on a particular feature. This will help to improve the quality of product and reduces the risk for the company if some team changes are required. Each team member wishes to learn about other components/features, but they hardly get time to learn. We can create opportunity in the following ways.

Conducting training or technical sessions

Training will be benefited if we are forming a new QA team. Instead of each person learning about the product one lead/manager should provide some training to the team. This will save team's time and everybody will start from the same page.  Each team member should conduct technical sessions on their expertise feature. This will help other team members to learn about all the features of the product. This not only improves product knowledge in the team, but also improves the communication skills of the team members.

Sprint Reviews

Ref: http://agiletrick.com/wp-content/uploads/2014/05/Review-Meeting-300x155.png

QA team should attend each and every sprint review and listen carefully about stories presented by other team members. This will improve knowledge on new features. Somebody should maintain sprint review demo recordings. This will help us if any team member misses the sprint review. QA team should practice to give the demo for completed features in sprint reviews.

Answer a forum/support issue every day

Ref: https://goo.gl/RnVU7K

Answering a forum issue is a good practice to learn about the product. Even if we don't know the answer if you spend some time on that issue you will get the answer. If you cannot figure it yourself then you should contact respective dev owner. I am sure they will help you. Don't  worry if anybody answers that question before you. Still you learned something about the product. Management also should allocate some time for answering forum questions. This will improve customer support as well as team's product knowledge.

Changing QA owners for each release

This will provide an opportunity to each team member to get hands on exercise on each feature. When we provide ownership, team member will feel responsibility for that feature and put 100% effort to learn and test. It helps to reply forum threads quickly and also feels like missed the scenario or learn about a corner case if any customer reports any defects on that feature.

Conducting Product Quiz

Each team member can prepare some list of questions on their expertise feature. Conduct a quiz within the team. Each question can open a discussion and at the end of the discussion somebody (Lead) should note down some notes. This should be a fun activity, not a serious one.   

What is Touch Time? How it impacts Delivery

 In agile model, Dev engineers and QA engineers work on a story and deliver it at the end of the sprint. Touch time can be defined as the "The actual time spent developing a product or service with the ultimate goal being the addition of value to the end consumer". Let me take the following imaginary scenario to explain this concept.

A dev engineer completed the development of the story in 1 hour on Monday. QA engineer needed to start verifying it on Tuesday morning, but as QA engineer is already busy with another story, he couldn't pick it up. QA engineer verified that story on Wednesday in an hour and logged a critical defect. Dev engineer couldn't pick that defect immediately and he fixed it on Thursday in 1 hour. QA engineer picks it on Friday and closed the story. In this example, actual time spent on this story is 4 hours and story marked as completed in 40 hrs. Here the Touch time is 10%.

Why do we do multitasking

As part of resource utilization, we want to do something instead of waiting for a task to become unblocked. That exactly happened in above example. If the team multi-tasked to fill the waiting time, how many features get done? Few features or likely much fewer.

Single Tasking and Partner Pairing

In this Single Tasking approach, developer and tester becomes a small team, and work on a single task/story. Developer thinks about implementation and tester thinks about test cases. They should interact with each other. Tester can understand the implementation and developer can the understand about the advanced test cases. E.g. what happens if we enter internationalization characters. Tester can also prepare the automation test. If we follow this approach both will benefit and they can deliver the next story with more quality as they know how developer and tester thinks. We need not follow this approach if our current approach Touch time is ok. Need to consider other tasks like planning and deployment while calculating touch time.

single tasking is not realistic as we need to catch up on email, meetings, support calls ... etc. We should calculate Touch time frequently and we need to work on changes to reach reasonable Touch time.

Ref: https://hakanforss.files.wordpress.com/2014/08/flowefficiencyformula.png

Let QTP monitor your application's performance

While working with our applications, we see our application's performance going down on performing a particular action. Reasons for this might be different. We mainly see these kind of issues when resources reach its capacity. Resources can be CPU resources, memory, application, physical disk and network resources. So, finding these kind of bottlenecks is difficult in manual testing. If you are using QTP to automate your testing, then you have a solution for this.

Ref: http://goo.gl/FXePGx

QTP provides a functionality called Local System Monitoring. Enabling this functionality for a particular script lets QTP monitor and record resource usage for each and every step performed. Finally, it shows a graph with resource usage statistics. When a particular step is selected in result, corresponding resource stats will be shown in graph. So that, it would be easy to know on which action in application, performance is going down and the reason for this (memory leak/thread leak/gdi object count, etc..). In addition, you can export data from the System Monitoring tab for a variety of file types.

Following are few simple steps which need to be performed to monitor system counters:

• Enable Local System Monitoring from File->Settings->Local System Monitor.
• Provide the name of the application to be monitored.
• Add system counters to be monitored. We can even set limit to system counters. So that whenever a particular counter reaches the limit, your test run will fail.    
•  Once test run completes, result page will shows system monitor graph.

These statistics can be exported to any type of file for further investigation.