daily post

Planning you PIs (Program Increments) is crucial (One PI typically spans for 6 sprints).

While planning architectural road maps for quality initiatives across different teams, I’ve noticed a couple of blind spots:

1. Planning for feature deliveries and enablers / architecture road map are very different, planning them both the same way does not work.

2. Test and learn – I am the planning type, plan so extensively and as soon as the rubber hits the road, all plans go up in the air. Have a long term vision, but how to get there is fluid – plan that for just ONE PI

3. Prioritizing enabler features. Depending on what your structure is, getting tech debt prioritized can be the toughest job. Try to get an agreement around that.

DevOps is a mindset change.. BUT

Also requires a hell lot of enablers:

CI/CD:

• CI tool in place (Jenkins, TeamCity..) with hooks to SCM, to creating environments, build & deploy the product, run the tests, and quality gates
• You may need multiple pipelines

Environments:

• Capability to spin up environments (Docker / OpenShift / Cloud..) on demand with desired configurations & tear them down

Static analysis:

• E.g. SonarQube or any other static analysis

Test data:

• Mocks / stubs for tests running on lower levels (unit / component)
• Synthetic data generation on demand
• Data creation and clean up routines

Test Automation:

• Unit tests, component tests
• API tests, contract tests, UI tests

…to mention just a few high level enablers.

The best part – engineers and product owners need to have confidence in all this.

So if you want to transform the way you release your product, have a plan for both:

• mindset change and how to develop all the enablers you need
• INCREMENTALLY (waterfall like DevOps is of no use..)

#RedefiningSoftwareQuality #Transformation #DevOps

Documenting your APIs behavior / contract on a confluence page enough for building common understanding?

In my experience, these pages often remain as static pages. The code keeps changing and the documentation does not.

I prefer using swagger to document workings of the API and use that as a reference.

This way you have a living document and no need to keep updating a static page.

Oh, and just to add, functional & contract tests are going to ensure if your building your services properly.

#RedefiningSoftwareQuality #TestAutomation #APIs #Swagger

A key area to consider while working on automation frameworks:

Complexity vs configurability.. and their inverse relation

To support more and more features, and make a solution scalable you’d want it to be more configurable

However as you make it configurable, it is bound to become more complex.

Sure using design patterns will ‘reduce’ the complexity, but inevitably will become complex as you make it configurable

There’s a balance you want to maintain between the two.

E.g. using libraries like cypress & robot you’d be able to create tests very quickly, but you loose control on certain configurability aspects, if you can live with them these are great

So it’s going to depend on your situation, But the principle remains..

#RedefiningSoftwareQuality #TestAutomation #AutomationArchitecture

Hiring for automation engineers / looking for a position?

Here is my list most important skills you consider / learn:

1. Programming aptitude. Can think and design algorithms, language does not matter.

2. Testing Acumen. Practical experience of developing and using heuristics & identifying risks.

3. Attitude. Enjoys solving problems.

4. Automation exposure. Have an understanding of typical pitfalls in automation frameworks and how to fix them.

Importan point: Don’t necessarily look for someone / stick to any one langauge / tool. Technology is bound to change.

#RedefiningSoftwareQuality #TestAutomation #Hiring

Who feels most emails are a waste of time?

FYI emails, cc’ed emails, bcc’ed emails, the long legal contract like emails, the confusing email with half the department copied in…

There are many reasons of this, most have to do with ways of working

Sometime no one wants to make a decision and let the focal point to keep spinning like a merry go round

Build a culture of test and learn, so people safe making decisions – Psychological safety

Also try to connect to people / have a quick group discussion as much as possible instead of long emails with a dozen people copied in.

#Transformation #Agile #HighPerformingTeams

One of the biggest challenge in #BigData projects is ensuring the ‘quality’ of data

Debugging ‘anomalies’ across #DataPipelines can be a nightmare. Certain teams end up spending more time debugging than actually coding new features.

That’s because usually there are no automated data quality checks in place to catch issues, and they have to trace back anomalies across huge amounts of data sifting through complex ETL processes.

With other development projects, the behavior is more predictive because inputs into the system are homogeneous.

For #BigData projects, there is no guarantee on the data we ingest & the how it get’s processed will always be accurate – the input is NOT homogeneous.

The solution to this: have #automated data quality checks running in #production across the data pipeline

#RedefiningSoftwareQuality #BigData #Testing #Automation

Project management – waterfall vs agile:

– Project phase 1: 50% over budget & 6 months late
vs
– In X budget & Y time we’ve managed to prove benefit hypothesis works / doesn’t work

Prime difference is:

In waterfall we benchmark spend against ‘planned spend’ (which is ALWAYS WRONG)

In Agile we benchmark spend against ‘value created’

Also – Can you sniff the BIG WALL / Them vs Us in waterfall

And agile is more about we as a group managed to achieve this

#RedefiningSoftwareQuality #AgileTransformation #Agile

Automation training projects should have a course on Git.

Mostly engineers don’t prioritize to learn how to effectively collaborate on source control management tools.

This causes lack of support & maintenance on the code base.

Get in the habit of collaborating more on code (code reviews, adding comments, contributing).

Otherwise we don’t document design decisions, or its in a document buried somewhere and never used because hard to find when needed.

“We don’t want to invest in tech debt right now, need to churn out more features”

That’s like saying, we’re not going to clean the house for a month, it’s just a waste of time..

(FYI, not investing in automation is accumulating tech debt)