Change agents and transformation
Developing change agents in an org transformation is crucial.
Few important things to consider when doing this:
1. Competency:
Change agents should be competent / an expert in the relevant field. This might seem obvious, you’d be surprised how many times I’ve seen this being violated
2. Drive:
– It’s not uncommon to have resentment and a very pessimistic view about the change.
– Your change agents need to be positive and energetic personalities. (BTW Most people with the right motivation can cultivate this)
3. Clarity:
– The goals and vision should be clearly ‘demonstrated’ to them, not just explained in slides.
– Living, breathing, practicing management demonstrating the change gives clarity
Any kind of transformation is not easy, but if any entity does not adapt / change, will die out eventually.
#RedefiningSoftwareQuality #QualityTransformation #Transformation
Stay positive
Situation for many businesses is becoming desperate
In such times, it’s very important to stay positive:
1. Try not to feed on doom and gloom news and look on the bright side
2. All of us might have things we have been putting off to do, which can be done now
3. Be compassionate to others. It’s a stressful time for all
This will end eventually and things will get back to normal.
Tough times don’t last, but tough teams do…
Avoid taking decisions which will impact you far after things go back to normal !
Importance of computing basics
While teaching a Java class yesterday I realized something:
Years ago, we didn’t have a lot of platforms to help develop code quickly.
People learning to code back then had to understand fundamental concepts in detail to develop an application
As things have advanced, platforms have emerged which a lot of heavy lifting for you.
That makes writing code quick and easy, however I feel students then lack fundamental concepts
This creates challenges when they have to debug programs
Some programming concepts might not seem like important to write code, but help a lot with developing and debugging programs.
#RedefiningSoftwareQuality #Automation #Training #LearningToCode
BDD Workshop main points
BDD workshop is the first course in the automation training I put together,
Here are few of the important points I try to drum in:
1. BDD is NOT just cucumber. I always ask how many people know cucumber, depending I spend time on them ‘unlearning’ that first.
2. How come people end up having different understanding of what is to be implemented
3. How does the three-amigo session help bridge this gap
4. How to do example mapping and difference between rules and examples
5. A quick brief on feature slicing
6. The best way to specify something is to describe how to test it
We do a few group exercises to instill the message across the 2.5 – 3 hour workshop, these are just some of the points.
#RedefiningSoftwareQuality #BehaviorDrivenDevelopment #BDD #Testing
Transformation starts at the top
‘Sometimes we are the problem, and need to change ourselves’ – This should be the corner stone of every transformation
Transformation projects usually are more focused around technology and ways of working
While that’s important, the willingness to change, especially at the management layer is vital
Black death of childbed case in point, for decades doctors refused they were the cause of deaths and kept on looking for other reasons (more in linked video)
Transformation starts at the top, and results will trickle down.
Will be speaking about IT transformation at #AgileTestingDays-US in June
#RedefiningSoftwareQuality #Transformation #Leadership
BDD Workshop Main Points
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
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
Don’t shoehorn DevOps everywhere
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
KPIs & Stats
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
API Automation Learning Path Summary
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
Be ready to learn and be Hands on
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
Testing synergies across the customer journey
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
Designing Test Automation Training
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.
Test data for Big Data projects
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
Disliking long written test cases
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
Automation Engineers to follow 2020
I’ve always believed living a life bigger than yourself.
Thank you Joe Colantonio ⚙️for adding me to the top 28 Test automation engineers to follow in 2020.
My vision since 2013 has been “Redefining Software Quality”
I believe testers and testing practices need to evolve considerably to deliver value to businesses
Instead of trying to shoe horn ‘our way’ of how we do things into what people do,
We should develop skills and practices that support the industry’s needs of today.
IMHO there are three values which will help us get there:
– Technological Excellence
– Testing Acumen
– Business Value
#RedefiningSoftwareQuality #RSQ #Automation #Testing #TestersGoingTechnical
Three types of test data to manage
Test data management for automation is not just adding some fields in cucumber…
Test data management can include:
– Developing & using mocks for running low level tests in the pipeline
– Data creation & cleaning on the fly (more here: http://bit.ly/QS_tdc)
– Using masked production data & refresh it on a regular cadence (for exploratory / behavioral tests)
For all three, the data generation, storage and usage techniques are going to be very different.
And if you are working in a large enterprise, you most probably will need ALL THREE
P.S.
No one said automation is easy..
#QsDaily #Automation #TestData
Data quality across the pipeline
Before any analytics can run on data, sometimes a number of ETL (Extract, Transform, Load) processes happen.
Data might pass through a series of data engineering / ETL processes to make it fit for purpose and categorized as needed
Quality across this process is all about ‘Data Quality.
I’ll explain the concept further and talk at length about how to check data quality in the upcoming #AutomationGuild
https://lnkd.in/fMp9Quf
#QsDaily #Automation #BigData #DataPipelines
Develop your API Contracts
I know implementing the automation pyramid is hard,
And to a large extend, is not a problem with just testing practices either..
I’ve seen teams where products don’t have contracts written up properly (API contracts / JSON schemas)
Back end services are not designed for anyone other than the developer to consume..
Such places do make it hard to implement the pyramid, i.e. 70 – 80% tests at the back end,
The solution: The whole team work on developing those contracts, and then write tests for those contracts..
Easier said than done, but until you don’t have that, testing isn’t going anywhere.
#QsDaily #Automation #Testing #ApiAutomation #AutomationPyramid
Change is the only constant
The only constant is change, especially in tech, regardless what role you play.
Similarly, dear testers, we need to change and adapt.
Change is uncomfortable and scary at best, but not a good enough reason not to change.
There is no choice but to work on ourselves “throughout our lives”! Doesn’t matter what occupation you are in.
The next time you are exposed to a new technology, language, testing technique, lean ways of working, don’t hold back.
Pushing yourself never comes naturally to ANYONE
I still ‘train’ my mind to push through my fears. And when I stop training it, I start to give into fear.
To train your mind and subconscious, one ritual can be to listen to motivational content, these days it’s Les Brown for me (linking sample video below).
#QsDaily #TechnologicalExcellence #Motivation #TestersGoingTechnical
Do NOT Automate regression 100%
Automation regression percentage – The metric I hate the most..
Many times the only use of this metric is to provide false assurance that we are efficient in testing.
And the ultimate goal soon becomes to automate regression 100%, which is a bad idea,
And automating just UI tests makes it even worse.
More on why not to use it and what should be done in the linked video
#RedefiningSoftwareQuality #Automation #RegressionTesting #KPIs
Data quality quick list
Data quality is one of the biggest problems with data science projects,
I’ll be talking about these at the #AutomationGuild, here’s a quick list:
– Accuracy. Is the data accurate in the context to be used
– Validity. Is the data fresh enough, still valid?
– Consistency. Data from different sources / time frames matches
– Completeness. No parts of data are truncated / missing
– Uniqueness. Enough data to uniquely identify records
– Timeliness. Data being collected at the right time & processed in a timely fashion (efficient enough)
More on the conference here:
http://amp.gs/Dydu
#QsDaily #BigData #DataScience #Testing
Test data and masking
For large enterprises with many interconnected applications, generating test data can be a challenge.
Even more so for big data projects, which is where masking comes in..
Take a copy of production DB from different products around the same timeline and mask the data for GDPR compliance.
Surely easier said than done, but can be very effective.
IMHO three main requirements to build this:
1. A quick guideline to identify what data will be classified as ‘sensitive’ and ensure it’s GDPR compliant.
2. A masking platform which masks value the same way across, helping with consistent data
3. Creation and usage of test environments is efficient and fit for purpose
#RedefiningSoftwareQuality #TestData #Automation
Using mocks
One of the main reasons for flakiness in automation is test data.
Therefore use mocks to run scripts executing in the CI pipeline.
For most folks, automation scripts are executed only in nightly runs with data created on the fly.
And unfortunately these tests are mostly UI tests, another blunder.
I gave a talk yesterday in which I said – 50% of your automation scripts should run in the CI pipeline triggered on each pull request.
And all these tests should use mocks instead of real data from downstream systems / components.
(I hope it’s needless these tests are on the services / API layer..)
So don’t forget your mocks when automating.
#RedefiningSoftwareQuality #QualityTransformation #Automation
Knowing isn’t enough to get paid well
“If I know my stuff, my employer will pay me well” that’s a lie we’re taught from childhood.
And here’s my take on this:
The industry is not there to fulfill your needs, it’s there to protect the entity’s interests.
If you want to get paid, knowing your stuff is a given,
Then there’s a heck lot more to do before you get paid well.
As engineers mostly we’re oblivious of social skills, and that’s the next big piece.
Learning how to deliver value and sell it appropriately
A few people I follow who have great content around this:
Seth Godin
Grant Cardone
Thank you Umair Sheikh for inspiring this post.
How to become a well paid tester?
How to become a ‘well paid’ tester?
I call it “The next generation” tester and here are the main skills…
Quality Engineering
– Agile practices and DevOps culture
– Ability to match testing goals with product’s goals
– Figuring out KPIs / OKRs which help ‘deliver value’
– Enterprise & Vendor management
Testing
– Risk based testing
– Defining a practical, efficient and effective test strategy
– BDD practices
– Context driven testing
Automation in test
– Algorithm design aptitude and programming proficiency
– Automation framework design
– API / UI / Mobile Automation
– OAT (Performance and security basics)
Continuous Integration
– Branching & merging
– CI tools (Jenkins / M. Azure)
– Provisioning environments Containers / VM / Cloud)
Technical Leadership- Technical acumen
– Team leadership
– Collaborating with architects- Thought leadership
Details of each in the linked article
#RedefiningSoftwareQuality #NextGenerationTester #TestersGoingTechnical