Requirements (Re)Engineering - Featured TestSphere Card

One hundred cards. One hundred Test-related concepts.
Here on the club, we’ll feature a card from the TestSphere deck for people to write their stories about every month.

I challenge you:
Take a few minutes to think about your experiences with the featured card.

What bugs have you found that are related? Which ones have you missed?
How have you tackled testing for this concept?
What made it difficult or more easy?
What have you learned? What can others learn from your experience?

Take one of those experiences and put it to prose.
Telling your stories is as valuable to yourself as it is to others.

4%20Techniques

A couple of projects back, my team and me were asked to test the completely new application for the back office of a recruitment agency.
They already had an application, but it was getting outdated. Management decided they would build it completely anew, but in a new technology. … and add some extra stuff of course.
Funnily enough and thankfully so, there was an analysis team that reverse engineered the old application and created requirements for the new one.
Their oracle was the old application. Ours, the test team’s, was both the old, the new and the analysis.

More than once I asked a tester to write their own (high level) documentation on the old product, listing the features and especially the peculiarities, then compare that to the new documentation before anything was even written.
We found plenty of ‘bugs’ or rather, inconsistencies when grokking through the old application and transferring that knowledge to the new.

What’s your story?

1 Like