English | EN 
In case my message on practicing the ‘no-but-allowing-code’ 3rd era of Test Automation (TA) didn’t come across adequately in my previous 3 blogs, I decided to rephrase some of my messages in more widely known role-based User Story and acceptance criteria informing ways. Let’s begin this many-faceted journey at a fundamental Epic level. Our initiation point is the organizational ambition to successfully obtain a real state of DevOps. To keep it short, real DevOps requires real Continuous Testing which requires in-sprint TA – which is only achieved by practicing the 3rd TA era in focus.
The Successful Test Automation Epic
If you have been following my series, you may recognize some of the below Epic contents. Based on the Epic definition, an interesting question for organizations to address is, to what extent do our DevOps teams fulfill any conditions leading to the success of achieving that precious real DevOps state?
In selected IT delivery prone new or changed deployments, DevOps-pursuing and “permanent-until-becoming-obsolete” core teams are established. Each team must be self-sufficient taking on the full quality, development, deployment, operational, and maintenance responsibility in their dedicated IT-supported area. Depending on pre-analyzed core team demand, each core team gets members assigned by the cross-functional and sufficiently skilled roles of a Business Analyst (and eventually also partly allocated Product Owner), a Developer, a Tester, and an Ops-specialist.
A sprint duration usually varies from 2 to 3 weeks, depending on the complexity, to facilitate frequent and limited Product Increments (PI) with high-quality deliverables at good speed and scale. Depending on the size, DevOps teams may be organized into Agile Release Train(s) (ARTs) and eventually subsequent ART Tracks, where the team efforts are PI-Planning coordinated at an agreed frequency. The tooling for the CI-/CD-pipeline processing is present either as a 3rd TA era integrable or such tooling integrated interface.
The business’s desired cadence in which to deliver/deploy is usually challenged a lot (delayed) with the test efforts which are meant to provide confidence in quality – but in this successful case in mention, even real Continuous Testing is achieved.
With the help of an external consultant (like me), the Tester role of one team (a Senior Test Analyst) recently proved to be change-adaptable in-sprint testing, self-healing and even autonomously self-automating TA capabilities provided by means of ‘no-but-allowing-code’ 3rd TA era AI-/ML-applied tooling – cascade enabling other teams to do the same. Although quality is built into all team efforts and by all members, the successful implementation of the new tooling quickly becomes a cardinal point of the organization’s real DevOps obtained success.
On the other hand, some other organizations may focus more on Business Process Intelligence than on TA autonomy across many test varieties. Since a huge written requirement complex had been difficult to maintain and get a proper overview of, it had been enriched, in some cases it was even replaced with flowchart drawings.
Therefore, their successful TA tool acquisition is different, while their tool includes enablers for Model Based Testing (MBT) which allows them to visualize flowchart drawings at User Story level in order to facilitate optimized dialogue and improved Business Processes. The TA tool in this case then scopes and highlights the desired coverage-paths and generates executable tests based on the flowchart path taken. A flow- or code-change may then lead to tool ML-issuing of a new flowchart, and ML-compared with a baselined one, the tool reveals/scopes what is currently not being regression tested but eventually will be.
Another organization may prefer the human behaving computer vision TA approach and tooling, both of which also have their own pros (instead of cons); as mentioned in a couple of my prior blogs.
Essential User Stories Leading to Test Automation Success
As an Organization doing our business, and even though a dedicated sub-organization of ARTs, Tracks, and DevOps Teams may be a required investment,
we want to have high-quality IT deliverables deployed at speed and scale,
so that we can keep up with customer satisfaction and business growth at a competitive pace,
in order to become even more competitive in our market(s)
As an ART, being an organizational entity of Tracks of DevOps Teams,
we want to coordinate our prior internally coordinated PI-planning with other ARTs at a 12-weeks frequency,
so that we can align our planned activities effectively, share resources and avoid getting in each other’s way,
in order to ensure timely delivery of DevOps deliverables at ART-coordinated level with confidence in quality
As an ART Track, as an organizational entity of DevOps Teams, IT-system responsible for and dealing with the dedicated business areas,
we want to coordinate our prior internally coordinated PI-planning with other tracks in our ART at a 4-weeks frequency,
so that we can effectively align our planned activities, resource sharing and avoid getting each other’s way,
in order to ensure timely delivery of DevOps deliverables at ART Track-coordinated level with confidence in quality
As a DevOps Team, comprising of a Business Analyst, a Developer, an Ops-specialist, and a Tester,
we want to practice the ‘no-but-allowing-code’ 3rd era of TA in a (eventually Spike-item) PoC-proven use of proper tool technology enablers,
so that we, guided by our Tester can do Continuous Testing as in-sprint intended and timely deploy IT deliverables at speed and scale with confidence in high-quality,
in order to become and remain increasingly highly valued by our Organization/Business and ART
As a Product Owner
I want to concurrently have our product backlog items refined, prioritized and Kanban-pulled into sprint backlog re-/planning
so that I can properly facilitate effective DevOps team efforts and efficiently enable our business and customer end-users,
in order to fulfill organizational demands of frequent deliveries with confidence in quality
As a TA providing role (any in the DevOps team)
I want to be tool equipped with technology enablers that, for multiple test varieties are web platform based, and efficiently AI/ML (and eventually MBT) driven, can be utilized to realize in-sprint TA,
so that my Team, suddenly now real Continuous Testing enabled, always and timely gets confidence in quality,
in order to help my Team achieve and maintain the real DevOps state
One Abstract Acceptance Criteria Leading to Test Automation Success
Given proper TA tooling is being implemented sustainably, initially with the professional help of a tool SI-partnering (Solution Implementation) external consultant,
when in-sprint TA activities support actual Continuous Testing (CT),
then the CI/CD pipeline runs smoothly and can achieve the real DevOps state
Endnote
We cannot ignore the fact that reality continues to grow more complex. It may be the goal of DevOps to simplify software prototyping and development through normalization of requirements down into small, more overview-able and frequent result/deliverable providing pieces, each taking a lot less time and effort. Agreed, even with many such pieces that’s also a better foundation for creating a fuller overview – i.e. while complexity keeps growing and facilitated by organizational means of ARTs, ART Tracks, and DevOps Teams.
Despite complexity, only all collateral aspects playing well together, may lead to successful empowerment. Again, that may appear rather complex, but at the same time it’s the reality to which organizations must relate – may our joint forces be with us all!
