Testing - Making Changes

So, in the last couple of blog posts, I’ve discussed incidents from my past that have driven me to take testing more seriously than when I first entered the field.  Today, it has become even more critical for the teams that I lead to address testing as a critical component of the software development lifecycle.  My teams produce applications that, at peak times, can process 10’s of thousands of transactions a minute.  If we make a mistake - we can propagate that mistake really quickly. 

In the past, we have relied on brute force to test the applications that we release into production. This included individual scripts, but they would be kicked off manually and the results were tracked manually.  As our environment has grown more complex and the pace at which we release software has increased, it no longer makes sense to continue to try and manage this activity manually.

What we are in the midst of doing is automating and exposing all of the test information.  If you’ve been reading along in my blog postings, you can probably figure out that I like process.  Process, when used properly can actually accelerate the volume of activity within a development team and can bring greater returns to the business.  I readily admit the process run amok can destroy a team. It’s a fine line and I attempt to be cognizant of where the benefits can occur and where the pitfalls are that can wreak havoc across the team.

So what are we doing?  Well baby steps first - and none of this is revolutionary:

1. I’ve asked our Quality Assurance Teams to own the organizational test plans.  I’ve moved them forward in the process to work alongside the business teams as functional and nonfunctional requirements are identified.  They are responsible for documenting what testing will be needed and how it will be accomplished.  Is this an app that needs load testing, have we thought about security, is there a user interface component?  By doing this, we are working through the test requirements at the same time.
2. I’ve asked our Development Teams to move towards a Test Driven Development(TDD) methodology.  We are beginning to implement these strategies in individual project initiatives and over time, this should spread to all of our ongoing project activity.
3. I’ve asked our Development Teams to move towards a continuous build/continuous test development paradigm where individual applications are either built nightly or weekly with automated unit, integration and regression test results accumulated and published to a central location.  Developers are notified of errors in the code base.  Management has insight into immediate reporting identifying key statistics including - code coverage, test success rate, conformance to best practices, etc..
4. I’ve asked our Development Teams and Quality Assurance Teams to communicate more closely so that QA has visibility into the tests being generated and executed during the development cycle and that they have visibility into the continuous build/continuous test results.  This allows our QA Teams to validate that development is properly exercising the code that is being generated and ensuring that they aren’t breaking things that already work.
   
   

If done properly, this will allow our Quality Assurance Team to focus on New Function testing - while validating the integration and regression testing performed via our automated build/test scripts. Additionally, this should allow us to produce reliable test reports that can be reviewed with management and ultimately the business teams as they validate their UAT’s.  This should give them a higher degree of confidence that the applications we are moving into production have been tested thoroughly.

Over the last few months the teams have made big strides in changing the paradigm of testing within our organization.  We have a long way to go, but I’m confident that the team members understand the benefits to their individual teams, to the organization as a whole and ultimately to the customers that we serve.

I’ll admit that this is the tip of the iceberg - there is a quite a bit more that we can do.  However, we are making changes that can be implemented relatively quickly and that have the highest payback to the organization and to our customers.  As time moves on, the teams will evaluate what additional steps can be taken to improve the process and harden the delivery of applications to our production environment.  Our QA Teams have done a superb job to date of managing the applications we move through the test phase of the lifecycle, now it’s time to expand the responsibilities associated with testing across the organization and to utilize tools that allow us to automate key portions of the test strategy and produce standardized test metrics across all project activity.

Tags: #SDLC #softwaredevelopment #metrics #lifecycle #qualityassurance #qa

If you'd like more information on my background: LinkedIn Profile