© 2017 by QS2 Point

  • Facebook - Black Circle
  • Twitter - Black Circle
  • LinkedIn - Black Circle

September 18, 2019

Please reload

Recent Posts

Translating Requirements to Work Packages

September 18, 2017

1/5
Please reload

Featured Posts

Building Effective Test Scripts and Requirements Traceability

September 25, 2017

 

One of the fundamental uses of documented requirements is to not only guide the project team during the design and build phases but the requirements but also serve as a measuring stick for quality assurance testing and can also be used during customer acceptance testing. The best way to manifest the requirements in a state that can be used during testing is to develop a set of test scripts that accurately depict the requirements in a way that can be tangible to the tester and/or customer using the application that the project team has delivered. This post will focus on how to build effective test scripts to validate your solution against business requirements.

 

From Abstract to Concrete – Correlate Requirements to Functionality

 

This is by far the most complex part of building a set of test scripts. It takes the collective knowledge of the business analyst who documented the requirements as well as the technical lead who oversaw the build of the solution. A good place to start is to extract a bullet point list of the requirements (if not already done so in that format). Easier said than done but if the requirements are documented in a well-organized fashion this should not be too daunting of a task. At that point each of those requirement points should be married up to a module or piece of tangible functionality built into the system. This relies on the knowledge of the technical lead to fill in those blanks (or a well-trained business analyst who knows the new system). Once this correlation is made, you can move on to the next step of describing the keystrokes and button-presses to allow the tester to validate the functionality.

 

Build Proper Guiding Steps

 

This step sounds easier than it is. And that is because when test scripts are written, they are commonly written by someone who has intimate knowledge of the system (i.e. the developer who wrote it). Why is this a problem – if the person knows the system it should be easy for them to write the scripts, correct? Wrong. Someone with intimate knowledge of the system should probably only be an advisor when it comes to documenting proper testing steps. What could be an inferred step for the expert might be completely relevant to add to the list of steps and can often lead to users getting lost and failing the test prematurely. Having a business analyst or dedicated tester develop these test scripts should yield far more comprehensive instructions on how to execute the tests with the delivered functionality and lead to far less ‘gotchas’ during testing for the customer. Not having that detailed knowledge of the system will force that individual to document every single step along the way (no matter how insignificant it’s perceived to be).

 

Once you’ve been able to marry up the requirements (which can be somewhat abstract depending on the solution) to actual tangible functionality and couple that with detailed instructions on how to successfully test the functionality, you are going to be setting your customer (and ultimately your project) up for success. Proving a link that goes right from inception (requirements) to delivery (your application) is the first step in proving real value to your customer with your solution.

 

Want to learn how our Digital Experience service can help you and your team? Let's talk!
 

Share on Facebook
Share on Twitter
Please reload

Please reload

Archive