You are here

You are here

How to clear up QA complexity: Use spikes and a feature test review

public://pictures/Yoav-linkedin.jpg
Yoav Weiss QA Manager, Hewlett Packard Enterprise
 

When working in large, complex R&D organizations, testers often find themselves testing software or a particular feature without fully understanding the implications of the feature or the nuances that they need to cover. Challenges for testers include dealing with the complexities of products and solutions that support thousands or more users and a lack of alignment with other internal teams. Combined, these challenges result in a risk to delivering a quality product.

As the QA portion of a large and distributed R&D organization, my team had to deal with these challenges, and we had to find creative ways to get a broader view of products and solutions. We did that by maintaining control of testing-related processes, bringing all product stakeholders to the table, and taking responsibility in order to make sure that the results matched the requirements of our customers’ needs.

This article describes how we used a concept from the agile extreme programming (XP) methodology, along with an original process for better managing complex features, especially when they are under development by distributed teams.

Our solution: Spikes and the 'feature test review'

The challenges mentioned above are explained in the Spikes Abstract, a segment of the Scaled Agile Framework that describes a special type of story called a "spike." Spikes are used to gain the necessary knowledge to reduce the risks associated with a technical approach and to better understand the development and testing requirements that testers and other team members may face. But spikes were not the sole solution to our complexities. 

In order to mitigate the challenges, we created a process we call the feature test review (FTR). An FTR enhances the agile philosophy by providing more detail for each feature and coordinating how and when it should be tested. Our FTR-based approach concentrates specifically on the testing aspects of a feature and exposes and highlights challenges and barriers to testing the feature. It also highlights areas that require special treatment, such as performance, scalability, usability, and security.

We have discovered that spikes and FTR meetings are particularly useful for handling complex features developed by collocated teams or distributed teams, and even across different development organizations.

Spikes

The term "spike" originated with the agile methodology XP. XP guru Ward Cunningham describes how the term was coined:

I would often ask Kent [Beck], "What is the simplest thing we can program that will convince us we are on the right track?" Such stepping outside the difficulties at hand often led us to simpler and more compelling solutions. Kent dubbed this a Spike. I found the practice particularly useful while maintaining large frameworks.

According to the Scaled Agile Framework (SAFe), spikes are used for activities such as research, design, investigation, exploration, and prototyping in order to reduce software delivery risks. On our QA team, we invest significant time and resources conducting a spike, because it is the basis for test planning, and for reassessing the scope of the development work. In addition, the research conducted during a spike empowers the tester, because it clarifies the time and environment constraints and boundaries of what needs to be tested for a particular feature. We found that the research often helps with adjusting the size of the entire Scrum team to support the delivery plan.

The spike research is done with the customer in mind, and it is based on their requirements as well as on feature specifications. 

The FTR meeting

The FTR enriches the product manager’s analysis and uncovers additional information that the product manager uses to ensure that the development team’s priorities are fully aligned with customer needs and expectations. FTR meetings should take place after each spike, where research results from the sprint can come into focus and be shared with other team members.

FTR meetings should generally be led by the chief tester for the feature. Meetings should be conducted in a way that crystallizes product needs in a presentation format and that reviews and summarizes what can and cannot be achieved for a particular feature. During the FTR meeting, the leader should share any relevant knowledge collected during the research phase, including customer requirements, feature plans, etc. The meetings should be structured, with part of the intent being to use this forum to shorten long email threads and make the planning and design process more efficient.

The research spikes and FTRs should be held early in the feature’s lifecycle, before significant parts of the product have been developed. Conducting the meeting early also provides an opportunity to collaborate with all stakeholders involved—including developers, testers, and product owners—in order to identify and resolve any potential problems that may lie ahead.

The ultimate goal of the FTR is to create better alignment within the broader R&D organization, as early as possible. The sooner in the process these meetings are held, the less chance you have of straying from the initial product specifications. 

An agile way to manage the scope of features

FTRs benefit testers by teaching them how to work with and manage release-related time constraints and their associated risks and how to identify these issues early in the process. FTRs also help testers enhance their skill and knowledge base. Through FTRs, testers can:

  • Improve overall testing skills and efficiencies
  • Understand how best to break down a large feature into manageable parts
  • Gain more knowledge on how to release better products and influence the product roadmap

FTRs are a valuable component of our agile processes today. FTRs help empower our agile teams by saving time, shortening endless correspondences and email threads, and eliminating potential product defects. When used correctly, FTRs help manage the scope of features by cutting releases into multiple phases, breaking the “silo” between the product stakeholders in early stages, and aligning customer requests and expectations.

Keep learning

Read more articles about: App Dev & TestingTesting