Monday, August 10, 2015

Improving a release process



Dear friends, 

I am back after long time and here I will try to share the experience and recommendations to improve a release process to make a quality product delivered to client. I am working in a very large integration project and all this input are based on my experiences and study. There may be chances for improvement and suggestion, so as always, I will be happy to take them as input in my comments box.

When we are part of end to end testing team where we mainly test integration of multiple systems. We put lots of effort for a bug free production go live and we invest huge amount of money  and effort to make this possible. Hence we are supposed to be very practical and have to use optimistic approach. Being a test lead / manager , it our duty to lead the approach from front and help project team to make a successful build and deployment of a bug free code to production.
This all depend of test management process and team whether we give client a buggy software or a quality product. We all know now days it’s all about making our client happy with our innovative ideas and suggestion as if we are not able to do so, client have lots of options in market J
Here I will talk about additional point apart from common one which I am sure all of us using and following.
  1. Avoid Implementing the New Features/Change Request during test release-  Never stop testing for any CR in between. If you are dloing so you are compromising with quality, time and cost.  Learn to say NO to management.  I understand that as per the business requirements, to satisfy the external customers or at least to meet the demands of the management steering committee or sometimes the sales / marketing teams, we come to such situation, but here talk to stakeholders and justify the excuse. Ultimately it’s not your own personal work, they will for sure understand you.
CR/Features are most welcomed, but it should be properly planned and implemented before the release of the software to the testing team or in next release. And should come through proper channel in our requirement.
  1.  No oral communication among teams (Specially development and testing team)- When it comes to work, Strictly avoid this as it highly impacts the quality of the software release. This is seen that when we are old in project, we start treating people like our friends or you can say we are very used to discuss the project work verbally. Even if your manager say something related to any feature and you take that to implementation, project is in risk for sure. Make sure any requirement related stuff must come through a proper channel, via mail or document. It is not like that , your boss say to you that “hello dear, I was talking to client in bla bla call, and they agreed to implement XYZ with abc changes” and you do as you think boss……. Please don’t do this.
  2. Return the Build to the Development Team- If the build fails in Smoke or Sanity Testing. Strictly, testing should not be continued. There should be no compromises. This will save lots of time and effort and improve the quality of the software released in the subsequent releases. Do not practice doing testing with known issues. If you are failing end to end and some one says it is known issue, and we are fixing this parallely , please try avoid continuing testing until it fix or you are very much sure that this is not impacting others areas.
  3. Arrange session to development team by testing team- This is very common issue especially when you are working in a big integration project where number of different systems coupled together. Most of the system’s development team work within their boundary and never take interest in other systems. While it is required to all to understand the system as a whole and also this helps in reducing defect aging as many time defects just lying here and there because of not understanding the process or system as a whole. So always go for cross team sessions time by time.
  4. Manage a test release repository- I believe this is always in place but issue comes as when the responsibilities are not defined.  For example, during the test release , if any CR comes or any defect is found during review process, who will update that in requirement, who will make sure that this is communicated to all stakeholders ect. So define the roles and responsibilities for each task.
  5. Proper estimation of testing activities- Estimate the testing effort based on the experiences and previous projects work. Always distinguish the estimation for test design and test execution. Writing test cases is totally different from executing the same. The testers should understand what to test, how to test and when to test, otherwise the efforts given to the testing cycle gets wasted, even though multiple rounds of test cycle happened.
As this is a start of talks to improve the quality of product/process, I would prefer to have great comments which will help me and others to go beyond limit.