What it takes to CoDE?
As enterprises start adopting DevOps and Agile development and delivery practices, development turnaround times are getting shorter. Testing teams are under intense pressure to quickly and thoroughly performance test web/ mobile applications, APIs, databases and back-end systems without sacrificing quality and security over speed of delivery.
Meanwhile, development teams, have traditionally relied on Test Center Of Excellence(TCoEs) teams to conduct massive scale load & performance testing. TCOEs are a virtual command center, with in testing organization, staffed with specialists that provision and maintain expensive testing environments and tools to server entire organization.
While the TCoEs, advocate best practices, unfortunately they cannot cope with the wide variety of applications that are under development and velocity with which these are released. Pressing teams to use tools that didn't come naturally will marginally be successful at best.
The move to agile development methodology, adoption of DevOps and API proliferation are forcing a change in how performance testing is traditionally done in organizations. And in today’s world, legacy testing tools that are tailor-made for specific technologies and specific type of deployments, are no longer practical to standardize, even within one business unit let alone entire organization.
So, relying on a testing process that is hard to scale, results in defects and performance issues frequently go undetected until after the application is deployed into production, causing disruptions and negatively impacting the business.
With higher than expected production costs and repeated delays in delivery schedules, executives are unable to accurately estimate the time and resources required to release an application into production and looking for new ways to cope with the dilemma of speed vs quality.
With CA BlazeMeter, teams can write performance tests as code in domain specific language (DSL) such as YAML, JSON to generate and instantly run JMeter, Gatling, Grinder, Locust tests without leaving their favorite application development tool (IDE). Same DSL can also be used to configure and launch tests and validate application performance at every stage of software delivery lifecycle (SDLC).
Testing at the Edge
Shift Left testing or Testing at the Edge, is an approach that necessitates involving testers much earlier in the software development life process, allowing them to understand the requirements, software design, architecture, coding and its functionality. With this knowledge in tow, they can ask tough questions about customer experience, seek clarifications, and provide feedback wherever possible that supports business outcomes. Most importantly, this allows them to carry out the testing activities continuously and enable the developers to take ownership of their code and increase shared responsibilities in delivering quality products.
Evolution of TCoE to CoDE
Rather than having large group of testers who are centrally organized, there is a need for people with quality focus embedded within Agile teams. Their new roles require them to understand the business context and come up with test strategies that minimize the risk in applications under development.
Some of the key steps in the evolution are:
- Empowering individual teams to manage and scale their quality resources with best practices and know how, so they can better respond to the new business challenges.
- Build quality into the development process by ensuring developers adopt quality practices such as keeping adequate requirements documentation and perform automated unit testing.
- Ensuring test automation is leveraged as the key tool for test coverage rather than be confined strictly for regression testing and is part of every code commit in ensuring that quality is baked into every step of software development lifecycle
- Fostering an environment where teams can leverage their core strengths such as using programming language of their choice for automating the test scripts and keeping the right talent engaged.
- Standardization on activities such as provisioning of test environments, generating, gathering or masking/scrubbing test data, creation of workspaces, handing of API keys, reviewing the dashboards and sharing the test metrics with entire team
With the right processes and modern performance testing tools, companies no longer need to assume lot of risk in releasing applications to market and stay competitive.
To learn more about the evolution of Test COE, please check my other blog.
You might also find these useful:
Interested in writing for our Blog? Send us a pitch!