Here is a small article that I have penned down to talk about the modern Qa models or more precisely approaches in the test executions to make the targeted software as much bug free as possible to ensure a robust " CLOUD " implementation of the same.
While its true that almost 80% of the software industry in every given domain has embraced "CLOUD", both the word and its allied terminologies, to match the ever changing and fast growing vast technical business needs in a range of its offerings across the multiple domains barring any legacy systems that still need some time either to switch over or to get converted in to the CLOUD models from their respective On-prem implementations,
the question is...
Where exactly is the CLOUD in the software..?
Is it in the handover/delivery....?
Is it in the implementation..?
Is it in the onshore (at the customer base) / offshore (in the engineering base) execution...?
Is it in the approach...?
Is it in the engineering and architectural skeleton..?
or is it in a combined view that interlaces together all the above SDLC entities and the various names attributed to them.
( PrgM / PdM / Dev / Sus / Qa / B&R / Ops and so on )
Going with the generic terminology of a 'CLOUD' in terms of calling it an SDLC approach with decoupled business logic and simplified provisioning mechanism, this perception is not only at the end user level but also is subsumed at every engineering level in the modern age software engineering and the new age Qa journey too is an all-inclusive phenomenon of the above CLOUD embracement.
A decade ago it used to be a complicated JAX-RPC and then a JAX-WS web service implementation and now the same got revamped to a much versatile recreational state transfer web service approach where decoupling business logic has gone a long way beyond the annotations with the provided endpoints vested with the flexibility of allowing any authoritative user to build his/her own ideation on top of the already provided plain vanilla functionality.
A decade ago, much of our time and efforts were in to the environment creation and thus dealing with many compatibility issues setting aside the main business logic issues. Now with the advent of simplified containerized computing environments, unless there is a version difference in the docker image being used across the teams, all the team members are ideally supposed to be on the same page w.r.t the environments being used and thus proceeding towards the targeted business logic testing draws the key efforts to make a much better software with quick turn around times.
A decade ago replicating customer issues in the in-house engineering systems used to be a herculean task in analysing the huge Java dumps and the output of the decompilers to arrive at the actual business logic issue and now with a simplified image delivery mechanism the entire customer environment can be bundled in to a docker image for the engineering teams to download / spin off a container for the same to fix and deliver the issue on the go...
With its diverse global customer base, each and every organization has its own established approach towards their respective CLOUD delivery models and by ensuring the right tools and infrastructural usage, the modern age Qa is thus a CLOUD Qa where in the approach towards making a better software has taken a dynamic and scalable path in minimizing the efforts spent on the non-business logic areas and by focusing on the areas of software vulnerabilities in the core business logic implementations.
With a rampant increase in the mobile software implementations, transforming the core engineering business logic implementation in to a platform agnostic / device agnostic approach is rapidly gaining momentum there by making the already established CLOUD Qa to expand its horizons in to the mobile software world to reinvent itself in making the mobile software usage a much seamless experience to an end user both in-terms of the coverage and the localized usage of the same.....
An e-commerce software implementation may use Kubernetes as its container orchestrating infrastructure where as a
banking and stock trading software application implementation might go with the Amazon equivalent of the same to fit their EC2 environments...
Based on the domain we are spending our efforts in, the tools and the tech stack keeps varying while conceptually the Qa engineering remains the same w.r.t its roots in making every targeted software better and butter smooth in the usage.
No comments:
Post a Comment