Re-thinking the Test Case Preparation

The previous role I held was QA Group Lead, in a digital financing product company. My
responsibilities implied constant aim for innovation and efficiency, considering the workflows and
processes of the QA engineers. The overall context was very dynamic, disruptive thus challenging -
meant to shift the traditional mentality over banking solutions towards a modern one.
It was a continuous and ambitious drive, to ensure that QA group's - collective and individual
objectives were aligned and serve to met the company mission-critical goals. The "house rules"
were set by caring for customer satisfaction - through a qualitative product and a short time to
market - through frequent releases, with a short lead time. Given the above directions, I've started
to review the actual processes, identifying the waste (focused on time management but maintaining
highest quality standards) and searching ways to remove it.
One of the time consuming steps within the feature testing process was the test case
preparation. Test cases design was performed using Test Lodge, a test case management tool. Test
cases were written as phrases (using the traditional way of defining the preconditions, steps to be
executed, expected results etc.), taking a lot more time than actually executing them. The tool itself
enabled this test description process and offered some reporting features, similar to other tools
available on the market, having also some disadvantages (e.g. searching functionality was not
retrieving proper results, repetitive steps needed to be performed etc). The activity itself was rather
demotivating for the QA engineers, not adding much value to testing, considering both the time/
effort spent for test cases writing, but also the inefficiency to review the long list of scenarios (by
any team member). The limited time available for this testing phase was consumed inadequately, to
the detriment of identifying relevant test directions, brainstorming about corner cases, business
implications or possible integration issues. Involving other team members was rarely enabled.
The need of changing the tool was evident, but the other similar tool options were not
resolving the waste itself. We needed to change the process, so that test cases design phase would
become a valuable and also efficiently-spent time, focused on entire team participation. For that
entire context, I proposed switching to mind maps preparation, a different yet simple approach. It
was a way of having a central item (the feature to be tested), then listing as first branches the test
main directions (UI, APIs, DB, Logs checking, Integrations etc), to be, then, spread by distinct
screen/ request/ action types, continued – in deeper detail – by relevant fields, associated test types,
etc. Tracking of the testing progresses was required, by marking the tested branches as Passed/
Failed, associated issues found & relevant screenshots.
For the long term perspective, I imagined that this approach could also serve for easier
product business learning, e.g. during new colleagues on-boarding. Therefore, mind maps needed
to be link-able, so we could ‘zoom in’, starting with a general overview over the product, then
looking into the main modules, then digging into features. All these needed to be performed in a
collaborative way, similar to a shareable ‘Google document’ so that all team members – not only
QA engineers – could contribute by their own perspective / business knowledge. More over, history
feature was considered helpful, to track all the adjustments.
 Considering the above requirements, together with the team, we followed a set of usual
steps: did some research, short-listed options, followed demos, asked for license proposals,
confirmed compliance with information security policies & get the final budget approval. Initially,
we got the trial for MindMeister tool, to test its features and do a Proof a Concept, then purchased a
set of user licenses – to be extended, based on users need.
In practice, using the mind maps instead of the traditional definition of the test cases did
help (even more than initially predicted) to grow entire productivity but also motivation –
promoting creativity over routine. The time spent for tests preparation was decreased to maximum
30% of initial time, focusing on value adding details.
As an image worth more than 1000 words, reviewing and collaboration was enabled,
between all team roles: QA Engineers to create & review, SDET to select & mark relevant
scenarios for automation, PO & Support teams to add suggestions (having a closer customer
perspective). Test-driven development was facilitated also, by this way, as the DEVs and QAs
collaborated closer, to prevent issues rather then discovering them later. It was a good moment to
also split ‘who’s testing what’, also in terms of new test scripts implementation (automation wise).
As the entire team was impacted, Definition of Done list was also affected by this change:
we added ‘Acceptance Test Agreed’ option, to define the activity where all the team takes the time
to brainstorm, review and agree the possible ways of testing the new product changes planned to be
done. This innovation, yet simple as it was, contributed silently to a mindset shift – less ‘silo’
approach, more rowing in the same direction.