Each day brings something new and something beautiful which you might understand at that moment or it might take months. I remember one such day which taught me the importance of one of the key artifact of testing which I was aware off and used in past but never understood the importance of it till that day.
I was working in a web based testing project lets call it “Project Wolverine”. I don’t want to reveal the name of my project and this way it is fun and let’s face it we all love Wolverine from X-men. To give a little background, the project is about performing functional testing on a web based application which has multiple tabs with various workflows affecting the data to flow from one tab to another. I would not say that is the most complex project I have worked in but it wasn’t the easiest one either.
We started working on the project with various stake holders from different directions to come together in a workshop to make this dream project come true. There were no written requirements so we as test leads needed to make as much as notes possible. Everyday I use to put all my notes into a format which can be understood after a month as well. Time was flying and with-in a month the development and architecture team started to work things out and soon there was a draft deployed for us to test.
The team was excited to test the new product with high energy to find 100s of defects everyday. I would not blame Development team for all the defects because there could easily be miscommunication of understanding the requirement.
The first cycle of testing was over and development request for some time to make a good defect fix build to reduce down the number of errors. We as testing team got some time out. We went out for lunch, games, movies and many more outings to celebrate our 1st journey through the mysterious island. Now we had to utilize the time and so we book a room. Sit together everyday, discussed each functionality in depth and build a document which had all the requirements that we tested as per our understanding. We sent it to the business and there were many rounds of review and changes and finally we came up with a good enough documents, called ‘The Black Book for Project Wolverine”
We were all set to take another ride but who would know that the disaster was about to come. From a team of five resources, three of them left the organization with-in two weeks. We two knew most of the functionalities but we never tested all of them. So we started to recruit few people internally and we found two awesome testers.
We decided to build a regression cycle to work along with our defect fix cycle and now the people with knowledge of some functionality are gone so it became hard for us to find the right test cases for regression testing cycle. I was in a discussion with one of the manager (let’s call him Boss X) over lunch and I still remember his response to my question, word to word:
I asked “We built the requirement document, we built the test cases, we have all the knowledge and we are the once who raise the defects even then why is it so hard to find out the correct regression suit?” I sounded frustrated. He was not the Test manager for Project Wolverine; He replied:
“Do you know in how many ways you can reach to our office from here?”
“Yes, there are three roads leading to it” I said and thought has he lost it? Was he even listing to me?
“Think again, and this time as a tester” He said and I gave it a thought and replied
“Ya, may be more” He looked into my eyes and said
“You might know the shortest part or the easiest path because that is what you will choose as a regular driver but what about if you can rent a chopper and fly, what about if you walk, can you trace pass few apartments or go from a walking alley. What about public transport, will it take the same route. The whole point is you may know all the paths but what you actually need is a way to find out all the traceable paths to reach then you will be able to choose which one will give a good coverage” I was still processing his statement and trying to relate it to my issue of building a regression cycle and suddenly it stuck to me what he was asking me to do is to build a Traceability matrix.
“Traceability matrix!!! you could have told so.” He looked at me and replied
“You know what it is. I just needed to remind you the importance of it.”
I went back to office and called my team in the room and started building a traceability matrix. It took us two days to map all the requirements to test plan and test cases. Another 1 day to map all the defects and risks to it. The only thing left was to use filter function to choose the right test cases for our regression suit.
Well the project was a good success and it went into production in few more months. I was happy with our performance and it was time for me to move on to another project. Boss X came to me and said
“Can you put down just 10 points about the learning from project, could be things you followed and could be things you should have followed. You don’t have to send it to anyone but you will thank me later.”
Here are the points I gave and I still think they make most sense for any project that I worked before and after that project. These points make a lot of difference if they are followed.
- The requirements were not given but that doesn’t mean the knowledge was not given. We as a team can always find sometime out to built a ‘Black Book’ by ourselves. Which made a huge impact in project wolverine
- If there would not have been any peer reviews (static testing) development and testing teams would have invested a lot of time in rework.
- Ad-hoc testing is as important as regular functional testing as it gave us few paths which were left unattended and not tested. It gave testers a freedom to think and explore without test cases.
- Never accept a piece of code without being signoff with unit tested by developers as it will invite a lot of time investment in defect logging and retesting.
- Biases in the team are only means to create differences among them.
- Maintaining standard documents for all the activities that every team member performs and doing cross training is important to avoid ‘Single point of failure’. Communication between the team members is far more important than it sounds as it can remove gaps, misunderstandings and build a trustworthy environment. So say yes to everyday meetings.
- Maintaining project status and keeping track of progress is not to monitor testers but it’s a means to know that are we on right track and right speed. It is one of the essential parts of testing.
- If something has failed in the past does not mean it will fail again. One of the example was using excel add-in for QC, which failed in the past because of lack of knowledge but later was a success and has proven effective.
- Transparency is the key for team to be presented as one. If everyone has the same knowledge might give insecurity to one but in reality makes a strong team. We used one mail distribution link instead of individual email ID. Especially for other touch point teams like Environment, deployment, development and BA teams.
- Last but not the least – Knowing the product does not make us an expert. It is important to document and built a traceability for each part that is being tested.
