alikhalid

Few important things I stressed on while delivering a BDD / Three Amigo session workshop today:

Cycle of BDD
1. Collaboration to clarify system behavior
2. Formulation of behavior in business terminology
3. AT THE END, Automate documented behavior – WHERE POSSIBLE!

BDD != Cucumber !!

Write stories in the format: As a if I do , I should see

Slice your stories vertically, each story should have an action and corresponding behavior

Write stories, rules & examples clearly, so someone can understand it even 6 months later

#RSQ #BDD #ThreeAmigoSession #Agile #TestAutomation

It might seem common wisdom for every software product should be able to deliver at a daily / weekly cadence,

However the Gartern’s Pace layered application strategy would beg to differ.

Some products require a lot of experimentation and rapid adaptation according to the changing surroundings.

However for other products being precise and efficient are far more important.

And that’s in a nutshell what the PACE layered strategy talks about, and divides software products in three types:
– Systems of innovation (revolutionary product)
– System of differentiation (improved product)
– Systems of records (efficient & legacy product)

#RSQ #ProductStrategy #DevOps

http://quality-spectrum.com/intro-to-pace-layered-application-strategy/

Engineers usually dislike talking about KPIs and stats, you hardly see any useful ones

Managers mostly want to talk about just stats and KPIs, and feel they are all valuable..

IMHO KPIs & stats are required to take decisions based on objective data, so they are needed

However understanding that stats don’t give you the whole story is vital

To engineers I say: better you come up with a stat, or someone with no clue of what you do will come up with one

To management I say, use KPIs & stats, but do factor in qualitative measures and listen to your engineers, not everything can fit on a spreadsheet.

#RSQ #RedefiningSoftwareQuality #KPIs #Transformation

The summary of Automation learning paths I designed over the past few months.

API Learning path – Beginner level:

> Testing fundamentals
– BDD
– Risk based testing
– Test strategy fundamentals

> Programming
– Basic Java

> Technical knowledge
– How do APIs work
– JSON & XML structures
– Swagger fundamentals

> How and why of automation
– How to do automation the right way

> Automation tools
– Rest Assured
– Basic API framework

Each course has online content or a workshop designed along with assessment material.

#RSQ #Automation #Training

If your in IT, you have to be open to learning ALL THE TIME.

Was reminded of this while developing an app in PowerApps today,

For a massive training program, was trying to figure out a more intuitive way to do registrations,

After few days of searching couldn’t find anything in-house I could use, had three options:

1) Use whatever mechanism we have even if it’s shitty, 2) wait on some one to get free and do it or 3) do it myself.

Ended up learning PowerApps and building a crude version of the app in a day

Could have easily said, we don’t have a solution, let’s just call it quits

Instead I learned something new, enjoyed it, and made others life easier to get the training

Bottom line, if your in IT, always be ready to learn and work hands on.

#QsDaily #Learning #Coding

A major lacking in large software enterprises is:

Lack of a holistic test strategy across the customer journey

Scrum teams are mostly thinking within their small box,

Worried about getting just the next story out the door, and I don’t blame them. That’s what they are judged on.

But to stitch all that together and build synergies between teams should be a prime objective of testers

The customer does not care about what happened with one story

The customer deals with the complete end product, which is a conglomerate of multiple products with many stories

Let’s not be penny wise pound foolish and ignore investing in the big picture.

#QsDaily #Testing #TestStrategy #TestingAcumen #RSQ #RedefiningSoftwareQuality

Busy designing an automation training program, here are the six main areas:

1. Testing Acumen
2. Programming fundamentals
3. Learning the tech stack
4. Building automation enablers
5. CI / DevOps basics
6. Automation tools and framework design

Drop any of these, and you wouldn’t have people who can build useful automation practices.

I know that’s a lot to do and to prepare, but that’s just me. Mr. Perfectionist.

I want anyone that goes through the training should be self sufficient.

Got a great question in my talk’s Q&A at the #AutomationGuild 2020 :

How to create test data for #BigData projects?

Generally there are three types of ‘test data management’ you want to focus,

1. Mocks / stubs
2. Generate synthetic test data
3. Masked production data

For big data, the most important one is masked production data.

You would also need to create synthetic data too, but will not be enough to see if the model is working properly or not

So make an effort to get masked production data to have greater confidence in your data pipeline and data models.

#QsDaily #BigData #TestData #Testing

Over the years I’ve started to dislike writing formal and long test cases

We need test cases, but written in a better way..

Traditionally we write them detailing each step along the way,

The idea was even if someone is not a domain expert can use them, or to make sure we don’t miss a step and know what exactly was tested

These monster documents become shackles: time consuming to write, a nightmare to update

Instead I prefer writing the ‘test scenario’ in brief with the most important check / validation over a full blown detailed list of steps

Also, importantly, using mind maps instead of test case management tools / documents

One does sacrifice the details this way, but makes things much quicker

Also provides a great holistic view of the many test types / scenarios

#QsDaily #Testing #TestCaseWriting #LeanThinking