Skip to main content

The Top 4-Ways to Build the Right Test Strategy

Top 4 ways to build the right test strategy


A Test Strategy is created to guide all teams on steps to achieve software quality objectives. With software companies adopting agile practices in a big way, an effective Test Strategy becomes even more important with iterative / sprint-based application development.

A test strategy being a live document, should ideally plan to integrate the business, development, testing, and management teams, define the quality objectives for the intended application and chart-out a path on how all the teams can help achieve these.

The test owner and the team can build an effective test strategy with these 4 best-practices:

A)   Focus on Prevention – Helps avoid major issues and rework on projects.

ü Prioritize requirements and business rules.

ü  Communicate changes in priorities immediately and effectively to important project stakeholders.

ü Strictly review and implement common requirements that ensure a consistent product.

ü Review product designs with an architect that can help implement future requirements with ease and optimization.


B)  Design the Right Metrics – To iteratively “measure quality” for the project.

ü Application go-live metrics should cover the base metrics for requirements, design components and development progress along with the test output.

ü To pick the right metric, consider ease of collecting data regularly and generating reports.


C)  Make an efficient Test Design – Provides high-coverage and build a scalable test architecture for complex applications.

ü Understand, why “test design” is important. For example, having basic UI checks as part of a checklist helps to start defining and building a simple “test design”.

ü An efficient test design provides a basis to automate redundant user activities.

ü Define “test scenarios” instead of “test cases”. Reuse documented requirements and business rules to build your test scenarios.


D)   Build Cross-Functional and Cross-Technical Testing Teams.

ü Build cross-functional and cross-technical testing teams. Allow and educate team members to delve deeper into the application architecture and core design to unravel design bottlenecks and limitations.

ü Testing team should interact with the business team to gather deep domain expertise to identify preventive measures.

- Written by Anand Nanavati (SupraDigit Solutions)

Comments

Popular posts from this blog

Reduce Your App Development Costs by More than 50% by "Simply Preventing Bugs"!

"Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”— Steve Jobs Everybody loves to avoid a disaster, but there is a “proactive” effort to do activities that can prevent a disaster from happening. Most of the executives do not want to “get involved” in such “proactive” efforts, simply due to the love of fixing urgencies Or having a mindset that it’s not important.   I remember, when once I was working with the Quality Assurance team on a product. The development team simply refused to spend efforts on the most essential “unit testing” for their developed components! The intent was to release the software to the QA team as soon as possible and focus more on so-called “core development”. Over the years, looking at multitude of projects failing in-spite of highly experienced resources, reasonable time and the intent, I have uncovered that, prevention is the “Most Important” and “Ignored” part of software development. Why should we

Change the World by Keeping Your Inner Fire Ignited

A decade back, when I was working on a huge enterprise program (with multiple projects) along with a big team (of close to 300 people), we were a group of managers who were evaluated and pushed by the senior management to “proactively” deal with issues and to work on finding new solutions. I used to think of how - we can become “proactive”, when we were already focusing our efforts on fighting our daily “fires” or urgencies of our project work. When I delved deeper into our daily work habits, it struck me that till the time we are not excited about “getting things done”, the willingness to explore more out of our comfort zone just doesn’t happen. The innate human behaviour is to follow a routine and establish a comfort zone over a period. The 1st factor – “an external stimulus” can upset us and force us to think or act out of our comfort zone.  The 2nd factor that can make us “move” out of our comfort zones is about having an excitement of a future or coming up with a vision th

The Confusion Between Software “Metrics” Vs “Matrix”

When I was studying in class 10 th , I asked my English teacher a very basic question about why two words in English sound the same but mean different. That time, we never had a separate subject on “phonetics” and I was quite unaware of this part of the English subject then. She smiled and very smartly told me that – “English is a ‘funny’ language” and went away! I was amused by her answer the whole time. Only later I learnt that in English there are so many words with a spelling, that are used “as per the context” to mean different than their similar sounding words with a different spelling. In quality assurance and in general in project management, many testers and project managers make the same mistake with a misunderstanding and confusing these 2 words – “Metrics” and “Matrix”. They use them interchangeably! Metrics in the quality management context means “to measure” (check its meaning here - https://www.dictionary.com/browse/metric) and … Matrix has different meanings based o