In my humble QA beginnings starting my career at a large telecommunications company and did not know the awesome benefits of a checklist that could help me in my QA career. I sat in a gray cubical with a co-tester along with two other testers in the adjacent cubical. This was in the days before the open concept was popular and we had no clue who were the developers or where they were located. The only avenue to interact with them was via email.
Day in and day out we would run regression tests when changes were made to validate that no new defects were introduced. Regression tests would take up passed 2 days with all of us testers simultaneously running the close to 400 test cases. It was my first QA job, and I was hungry to learn and to get experience. I would be running 40+ tests in a single day and leaving the office knowing I didn’t take any of my potential efforts with me home.
The Big News
I remember coming in the next day after an intense regression testing day and my lead told me: “We have to start the regression from scratch.”
“Why so?” I asked.
He answered “Yesterday we were testing a cached version of the software. Therefore, our testing is all invalid”.
This was a shock to me, and I didn’t understand. “How was that possible? All that effort yesterday was all for nothing?” How could that happen?” I also didn’t know if the developers were even aware of how much effort we put in the day before.
Not too long after I joined a different company and noticed that this happens in other companies as well. This time I started asking questions and soon zeroed in on the preparation steps that need to happen before QA can with certainty know that the build is ready for testing.
Here are some of the prep steps that I learned that needed to happen before testing:
2. Clearing of cache. There is the CMS cache on the website and there is also the server cache if the environment has a cache server.
3. All the correct CMS content instance is pull into the test environment that is necessary for the testing.
4. Unit testing has passed.
5.Automation tests have passed.
Check List
This is where good old checklists come into play. In this same company, I wrote up a checklist and gave it to the whole development team to pick at to see if anything can be added or subtracted. Both testers and developers, we spent about a week on it, and everyone pitched in their ideas. At the end we had our companies very own release checklist. Every build that needed to be regressed before a release would have the developer creating the build sign off on every step of the way.
With something so simple we never again had an issue where a build was not valid for testing. Every hurdle would be addressed ahead of time allow the manual test team to have more time modifying regression tests, working on feature testing, updating documentation and cross training. Today I am always on a look out for any repetitive action that cannot be automated to include a checklist and know the power and the benefits of a checklist in QA.
