Software testing is a meticulous process in impersonating the end user by trying out various input scenarios and comparing it diligently with the expected results. With careful introspection of automating a program the stakeholders are never at stake by invoking the idea of letting the computer to work on the job. Nevertheless we understand that manual interruption to any detail in the program is needed to make it error proof but automating large aspects would help the delivery be more effective. If a customer requests for a quick change or enhancements to the program, by effective process and automating the right stages we eventually end up testing every build leading the project to proof-read every stage.
Though it sounds easy, the complexity of automating the process on its own is a nightmare. The identification of test cases and the number of test cases executed is directly proportional to the correctness to the program.
The efficacy of the process here lies in deciding in the number of test cases to be executed to the number of people deployed in each area of testing the builds. The era of businesses using resources for assembly line to execute, test and deploy has diminished with arrival of Continuous development which uses automation in continual process for continuous integration, infrastructure automation and release automation. Successful products which can be put to test with any amount of enhancements and changes are the one which would undergo the best practice of Continuous Development.
Illustration with example
Two new hire’s join different company’s; A and B at the same time. Company A follows traditional methodology for software delivery whereas Company B follows a Continuous delivery approach.
As already mentioned the company follows a traditional method where communication between the business, Operations, development and QA takes places at various levels during various intervals often leading to data slippage or mismatch.
When the new hire is asked to work with his new mentor for adding a new feature to the existing product, he is given a schedule sheet with the intervals at which each process would be followed. To start with he works with the requirement gathering team which predominately did second-guessing of details and scenarios what customers actually wanted which took them few days. Secondly, he was engaged with the coding team which had the requirement specifications where every coder was making changes to their copy of the application creating duplication of efforts; which ended up in coding for a week. Then comes integrating the feature where merging the code into a single codebase was a challenge considering the number of conflicting changes which was directly proportional to the number of developers working on it. Testing the product; translating the business requirements into test plans, identifying test cases – whether to automate it or not; resulting in hurried testing which in turn affects the quality of the feature produced. And before the final release of the product, it undergoes a set of tests that is been involved in pre-production environment. After several weeks of planning and execution the small feature of the product is been released in a stressful and into a not-so-quality product.
The company had pre-planned its software delivery value stream and identified the processes which were time-consuming, costly and prone to errors. They eliminated, streamlined and automated the identified pain points in the process to set-up a cost effective, prompt and consistent process. This is practice is what they call Continuous Development.
The other new hire was asked to work with his mentor on a new feature when he encountered continuous development for the first time. He along with his mentor identified the purpose of the new feature by going through the specifications formulated by the entire delivery team where the business and QA worked together to write executable tests in business-level language. After which they wrote a failing test and implemented the code resolution. The code was now ready to be pushed to the repository.
The mentor then explained the new hire how continuous integration server would pick up the modification from the code repository and run the unit and integration tests, and deploy their service to a test server. After health check monitoring system would interrogate the test server to ensure that the service was running deployment system would automatically deploy the code to production. The test they had written proved that code change was fixed and the complete test suite would exercise the codebase with the new feature. The whole process took the team less than a day.
The best way to find effective solution in Continuous Development is to identify ‘Wastage’. In the above example it is evident that Company B had outperformed Company A due to elusion of ‘Waste’ that was involved in each process.
How to improve cycle time by reducing ‘wastage’ in the process?
In this approach a group of Business analysts, developers, testers and Operators together formulate and prepare new ideas to approach a particular problem. The idea must ensure that the end-to-end team is on the same page nullifying conflict of interest and implementing the idea effectively. The entire spectrum of service delivery is covered up by the agile team which enables a successful product.
Analysis and Understanding
The key component to Continuous Delivery of the fast changing business environment is the execution speed of time-based strategy. The vital categories that need to be considered in this process are:
- Project and
- the Team for the particular implementation.
Action-orientated analytics provide the ability to identify the areas of improvement in the process and the best-quick methodologies to approach the problem.
Planning would include action items that the team had derived from the previous stages. In testing a program the following could be included in planning;
Fundamentals – Automation
- Planning of automated Compilation and Packaging
- Planning of automated Builds and Continuous Integration
- Planning on how to perform Automated Testing
- Planning of how to do Automated Deployments
- Planning on Automated Production Deployments
Implement a Deployment Pipeline:
- How to Model Your Pipeline
- How to Identify Non-automated Activities and Gateways
- How to Implement Your Pipeline
- Planning of Implementation Monitoring/Metrics
- Planning how to Implement Rollback
- Capture Audit Information
The process of selection of test cases and putting it into a framework and testing non-functional aspects of an application is easy to take advantage on. Automating the process would help us achieve it while applying it with a more robust automation suite to every process included.
The process that lead to a quality outcome within a speculated amount of time in an effective and efficient way is known to be best practices. Metrics help in identifying the health and quality of software testing efforts. Metrics which are simple, measurable and meaningful to identify current status, past performance and foresee future trends is supposedly to be effective to the business.
The journey to Continuous Development – be it small or big is essential to take many steps. The most difficult one would be in analysing how to reduce the cycle time in the process by changing ideas into actionable items with keeping the factor of costs in mind. With streamlined workflows, lowering your staffing costs at areas by implementing an automation suite, enhanced teamwork and faster iteration it would be possible to reduce the cycle time between initiation and execution of a program.
Latest posts by Naveen Srinivasan (see all)
- How to implement a robust Retail POS Automation testing strategy - May 25, 2017
- How continuous development shrinks cycle time between initiation and action - August 25, 2015
- Planning your browser compatibility tests - October 21, 2014