Revamping automation framework with Product Mindset logic’s.

Often we really don’t care to look at the material which we don’t understand or which is not eye-catchy. In this space, I will try to share a real-time example of how we as a team understood and deliver a problem that our Product owners and stakeholders were facing at the client-side. And thus helped us as a team in better collaboration over the certain things which we were doing in chunks. Alright to start with..how about this, can you read this? Very few people can connect to this…right?

Not easy to understand

And now this? More people can understand.

A Simpler way to understand a complex code.

And this one here? 

Even simpler way!

Looks interesting and more connected?

Yep!! Reason :- We used the common language here which almost all of us understands i.e. Native English

. The same concept is applicable to the software when we don’t understand the code which makes us uncomfortable and is time-consuming to understand for that matter , we try to make our OWN rather digging into much of it by applying the best practices we know or other way is pair-programming with the one who has written it from the root. In one of my project , we observed that our Business Analysts and Product owners team had a hard time understanding the code we have written as its not their forte to do such work as DIY.

As a team, we tried to implement an idea by understanding their perspective which will help them in understanding the code , by writing the code in language they understand.

Thanks to BDD.

For achieving this we tried ‘cucumber‘, as they are familiar with the gherkin language in which they are writing the User stories/Product backlog item we decided to incorporate the same in the code as well.

Thanks to Behavior Driven Development

Extending the Testing Center of Excellence

Cucumber feature file

Feature: Covering all priority scenarios of  application
    Background: open application as admin user
        Given open application as admin user
        When go to admin panel 

How difficult is this file to read when delivered to a product owner or Business analysts?

The answer would be much easier to understand as it is simple English.

Build to outcomes Action

This was way more easy to deliver feature files in sync with the Product Backlog Item’s Acceptance criteria. And we put our legs in their shoes to ease up the things.

As a result we started getting lot of new scenarios and cases from them which we started implementing as a part of the extension of the automation framework.

Lesson Learnt

This way we were able to achieve lot of pointers from the product mindset thinking:-

Minimize time-to-value– Though there was a time wherein we put a stretch to make this change in the framework architecture but now definitely as a team we can firmly say that was Worth-it!

Excel at change Action – By retrospecting, where we are lagging to make it happen, This was in our mind that the change is happening for a reason which is Customer Delight.

Focus feature development on a specific measure of customer engagement– This we have achieved my taking baby-steps at initial , as the challenge was to make a smooth transition from a basic project to BDD. Wherein we chose to do it in MVP way , so as to take small chunks first and then enhance as we go with the flow.

#productMindset #Agiledevelopment #BDD #BehaviourDrivenDevelopment #AutomationTesting #AgileTesting #cucumber