Software Development seems like a simple term to understand and as the consumer market grows day by day, it is creating a rather wide yet simpler effect on its users. The diversification of the users is increasing by the passage of time and we can clearly see that the average product (software) user is now a common man! It is now a common man game, and people don’t need to be specialists or have certain “titled” roles to operate the hardware and software. With the development on the internet and the evolution of the “Internet of things” the common man will have more access and power in their hands as ever before; But there is a catch to this revolution;
If we consider the looking glass in both ways then the consumer side is in far less complicated grounds than that of the manufacturing side; How? Well there are two words; Rapid – Deployments! Yes sir!, there is a huge number of users to a single application and they all want it running and healthy, because if that is not the case, then a whole mass of users will simply shift themselves to another one and will forget about it in the next hour;
It is not a hidden secret anymore that if we want to run an “efficient” software development, testing, deployment and support operation, we need to have a database that can reflect the status of this activity anytime we want and anywhere we want; The Project managers would want data to be represented in a manner that it reflects their team performance, criticality of the current issues and above all the resource time allocation in regards to the cost of the project! Now, for this several tools are available in market and most of these are free of cost; Now, I am not going in details and comparisons of issue to bug tracking systems that are available in the market, you can simply Google the terms and will be amuse yourself that how many are there!
In 2008 we were using Visual Source Safe for our shared repository of files and data; It was not an issue as we had a limited number of clients and with a centralized mechanism and fewer roles, the things were running fine, but interesting fact was that there was no testing team in between! Management were pushing roles here and there to cater for certain “checking” rather than proper testing of requirements and requests from customers and then releasing the fixes to the clients on need to have basis; it was a quick approach but very risky, as the number of releases and the track of the developer and deployment consultant load was not even there; if you ask about the past trends, the only thing you can get from the Project manager was an excuse because even though the data was there, it required an extensive amount of time to extract it from a number of excel files; We also tracked down the release frequency and was surprised to find out that that frequency was hitting the threshold on daily basis; So in so many words we were going to hit that wall soon and the problem was genuinely risky!
The point I am trying to make here is that in our case we went for the “Issue Tracking” not because we wanted it for granted or just to flash something at our customers that says “Hey look, we are using Issue tracker and all your problems shall be resolved!” – No, we went for it because without it there seemed to be nothing else which could get us out of the mess – so for us it was important that when the tool is implemented it should also deliver the right results and with the right intentions; Because at the time when we started using it in testing mode there was a hush around the floor that this tools is a management gimmick and will be used to monitor “my” performance.
The tool we used was an open sourced web based application developed in PhP, with multiuser / multi-project and Multirole functionalities; In general, it was providing us with the following features / functions:
1. Users and their roles
- Admin – To manage all projects, contents, assign roles and rights
- Manager – This was project instance based, with the access rights for Bulk status update
- Developer – The worker ant! Access rights to everything as Manager, except the “Bulk” feature
- Reporter – Controlled role basically for someone who can work on her Change requisition only, or has been added to a “Notification List” in a requirement
- Viewer – Can only view the data listing
2. Ticket Status (Bug Track):
- Waiting Internal
- Waiting External
- QA Verified
- On Hold
Now, the real question was how we were going to implement this or 5 different teams on different product line, different development cultures, and different release policies; Plus who is going to drive the ship in the first place as a support and implementation lead;
For this the task was to conduct separate meetings with all teams; show them what was to come and gather feedbacks; This gives us a common ground for all teams and we can see that a solution can be reached; What we received from each team was the Status (Track) of the requirements in consistent color coded form, like, for requirements / bugs under processing or consideration we used the shade of “Blue”, for requirements in Finished mode, we used the shades of “Green” and for the requirements coming under as Re-work the color was obviously “Red”.
In the mean time, we started to develop the policies and processes for changing the Status of the requirements and then assigning the tasks to different assignees, why we do that? Because certain roles in the loop can abuse the status of the requests and may cause damages;
To control the access points and shedding the load off the development project wise instances were created, which were then further modified into location wise instances; for example “Product-1” or “Team 1 – Mumbai”, and with this the restricted access was given to the clients; here the roles were mostly reporter and viewer.
Now, what happens, the customer lodges the ticket under their own authority, without making a call, that is accessed by the Support staff and is then scrutinized for further action; Either this will go to development for fixing, QA for testing, or remains at the Support for assistance and closed down;
We did not rest at this point, we introduced excel based reports accessed from the tables; which reflected the bugs , changes, enhancements, support, and other matrices such as open issues, development load, client wise reporting, assignees, trends and chargeable works;
It took us about 1 year to completely network the system; and 4 quality audits to conform this to the existing Quality Management System; we then further introduced several Standard Operating Procedures (SOPs) to make sure that the interim audits and compliances are carried out throughout the year;
What we have learned from this experience is that running after tools, or simply stating that we are using an issue tracking tool is a lame term! There is a whole new ball game you enter, when you and your company decide to acquire and implement an issue tracker, because logging bugs does not get the things done, it’s what comes after this does; The research, data analysis, management reports, status reports, internal audits, walk through, inspections, and operating procedures; The turnaround time for a request to create and end, the load on the resources, client handling, feedbacks and follow-ups – are all part of this huge yet very simple setup.
Arslan Ali has more than 14 years of Experience related to IT, Industry and Training Institutions with exclusive experience of 5 years in teaching various disciplines and projects in IT Institution. He has worked in various roles in capacity of Software Engineering, Software Tester, Trainer and Quality Assurance Roles.
Arslan is currently an active member of TestersTestified and Outtabox as a training consultant. You can follow him on twitter @arslan0644