PDCA – Plan Do Check Act..
The old and gold secret to superior quality
Although PDCA’s roots were from TQM, I feel its the same concept of ‘lean’ which has been defined and refined through Agile & DevOps
It’s all about planning ‘enough’, doing what’s important, delivering it and analyzing the results.
Testing does not have to be ‘they’ vs ‘us’.
Traditionally teams talk about what should be done ‘before’ a user story is handed over to testing.
Shouldn’t be that way, if everyone is testing in some capacity, the need to ‘hand over’ wouldn’t be there anymore.
What is a PR pipeline?
PR (Pull request) pipeline is a CI pipeline to run tests on EVERY pull request.
Let me explain the terms in there:
– CI : Continuous Integration – term used to run jobs to merge code, deploy code, run automated tests and give alerts.
– CI pipeline: A group of CI jobs stringed together to complete a set of activities on any event trigger
– Pull Request : A term used by Git users when an engineer has created some new code on his feature branch and raises a request to merge his / her code with the master branch
– Tests on PR : Tests running on every PR have to be very quick and localized since the application is not deployed at this stage.
Let’s repeat, what’s a PR pipeline?
Tasks & activities that run once an engineer raises a Pull request.
For more details on which tests can run on a PR pipeline refer blog post on #DTMS (link in comments).
Also doing we webinar on #DTSM, again link in comments.
#RedefiningSoftwareQuality ✔ #TestStrategy #DevOps #DevOpsTestStrategyMindmap #TestAutomation
Trying to change behavior – Carrot & stick might help..
Unfortunately most of the time we don’t change until it becomes a necessity (the stick).
That’s why ‘necessity is the mother of all invention’.
Recently I’ve been banging about a specific topic with teams for a while, and somehow still struggle to get buy in.
Once, out of necessity they are being forced to do it and they have no choice, suddenly all the problems are starting to go away.
Take remote work for example. Pre-coivd some folks were hell bent that remote working cannot work.
Now that we all are forced to work from home, suddenly those problems don’t feel challenging anymore.
The ‘stick’ can be many things – a declaration to achieve something, create circumstances to force certain behavior.
Summary:
Preaching, explaining, collaborating is all needed to change behavior – but sometimes so is the stick.
#RedefiningSoftwareQuality ✔ #Testing #Automation #Transformation
Are testing skills and technical skills mutually exclusive?
IMHO:
1. let me start from: being technical does NOT mean being an automation engineer
2. Technical skills would be: Understanding of how your product’s tech stack works, ability to understand the product’s control flow and code base.
3. Having testing skills does not mean you cannot have technical skills or vice versa
I think the problem stems from when we see technical skills and exploratory testing on two opposite sides
To me they are both very related and compliment each other, one SHOULD fuel the other.. therefore:
1. One cannot test a product very well UNLESS they understand the tech stack
2. One cannot develop a great product UNLESS they understand looking at the product from different perspectives..
This argument of testing vs development skills is not helping anyone – ALL ENGINEERS ON THE TEAM SHOULD KNOW BOTH
Yes some would be better at on thing, and might play a bigger role there, but should have the capability of doing both.
That’s why the very first thing I talk about in #RedefiningSoftwareQuality is #TechnologicalExcellence
#RedefiningSoftwareQuality ✔ #Testing #Automation #Transformation
Why do folks assume test automation = people loosing jobs?
I think because elsewhere automation = loosing jobs.. let me explain:
Over the past few decades, to build efficiencies we’ve automated every mundane task we can, and has been growing exponentially ever since
And this is not limited to a specific industry, this has happened all over, finance, medical, manufacturing, services you name it
Mundae tasks that were done by humans, have been taken over by machines, from small things like a bank teller vs an ATM / deposit machines to robotics on a manufacturing assembly line
Subconsciously we end up equating this automation to test automation, and start inferring the same results
However – test automation isn’t actually automating the whole testing process, it’s actually ‘automation in test’
A major portion of testing is exploring, collaborating and thinking compared to checking, which cannot be done by a machine.
#RedefiningSoftwareQuality ✔ #Testing #AutomationInTest #Automation
When starting to get in the habit of writing unit tests, don;t start with an expectation of 80% code coverage ..
I’ve also experienced teams where they start with 80% code coverage, it becomes so difficult to get there at the start
Teams ended up not pushing code to the master branch which caused even bigger problems
Her suggestion was to start with something like all new code should have a decent amount of code coverage, which makes more sense
Writing unit tests sometimes can be tricky, and time consuming without libraries and frameworks to support
It takes a while to get some helping libraries in place, so take it step by step.
Treat it as an evolution, not a revolution !
#RedefiningSoftwareQuality ✔ #QualityTransformation #UnitTesting #TDD
We always say “Quality is a team reponsibility”,
But how do we actually make it everyone’s responsibility?
1. Everyone, that means ‘everyone’. Engineers (dev & test), the PO, Scrum master, end user and everyone in between
2. Every person is affecting quality of the product negatively or positively, regardless if they think they are or not, you’d ask how?
Every person in and around a software product is helping in shaping the outcome, quality is an inherent attribute of what we do & how we do it
3. To make every person (role) feel responsible, they should hands on contribute to quality practices at each stage
4. Dev role engineers write sensible code, do code reviews, pairing on risk analysis, write unit & component tests,
5. POs actively particiapte in designing BDD acceptance tests, test the product from a customer’s perspective
6. Tester role engineers write integration, system integration and other automated tests and to exploratory testing
7. All engineers ensure the pipeline remains green and make it a top priority to fix it as soon as it goes red
A few ways to implement ‘quality is everyone’s responsibility’
#RedefiningSoftwareQuality ✔ #QualityTransformation #DevOps #AgileTesting
We have a very unique emerging industries like Immersive reality & human enhancement.
How to prepare to test these products?
IMHO there are three values engineers (yes engineers, not testers) must embrace to test well:
1. Technological excellence – having in depth understanding of the technology they are working with, not the business rules – the technology
2. Testing Acumen – Learn techniques to explore, collaborate, identify & communicate risks. You don’t just ‘wing it’, this is an art which has to be learned
3. Business value – Understanding how the product will help the customers, what is of strategic importance to the business and translate those into technical goals
I believe adapting these are three values will drive excellence in any software product.
#RedefiningSoftwareQuality ✔ #EmergingIndustries #Testing #Quality
https://atelier.net/strativerse/
Regression testing is not a phase in SDLC (at least not anymore)
Regression should be happening at multiple levels across the development process.
In a waterfallish setup, you’d typically have a few days where teams try to execute all ‘regression’ test cases
While there are a lot of things wrong with that picture, I want to focus only on what we call ‘regression testing’
In simple terms, all functionality we want to check & see if it’s still working after changes we’ve made – that’s regression.
In a DevOps culture, there should be decent automation in place, at unit, integration & System integration level.
All these automated tests are ALSO REGRESSION. Yes, a unit test which is important for us to ‘regress’ on is regression. I don’t know how come UI tests became synonymous with regression.
So holding on to that behemoth set of test cases which are supposed to be run ‘just before release’ is not efficient
And if that’s happening in your team, I wouldn’t be surprised if testing is considered a bottleneck.
#RedefiningSoftwareQuality ✔ #Testing #TestAutomation #RegressionTesting #AgileTesting
