Regression Testing --Assumptions are worst enemies

How many of you are like me thinking regression testing is the easiest part of testing? Ha ! I dare not anymore! I was thinking on those lines until I encountered a major issue in the system that I tested  minutes before it was about to be moved to production. This happened years ago, when I was in the initial 'fresher phase' (<2 years)of my career. Things do not seem to be as good as they ought to be.  I was testing an application in one of my earlier companies. We did not have any formal team,and each of us were assigned a module to test. I was more than happy with the module that I had to test as it was full of bugs :) what more can a tester ask for ? everywhere you click you see an error, and nothing worked! I logged bugs in 100's and was pretty confident on my work. Then came the fixes, with a scintillating Ux. Logging 100 bugs is easy, but trust me, verifying 100's isn't that easy. I verified all bugs and completed few more rounds of testing, the bug count reduced gradually and everything seemed to be good and neat. With just a couple of hours before production,came the final build for regression. When there were literally no bugs in previous version, little did I realize that I would encounter any major issue.I assumed that what worked earlier, would work fine in that build as well.I could hardly think of any issues after working so hard the whole month, everything was looking good to me. Stuck in front of system and a piece of module for a long time, did take a toll on my thinking ability. I could not think of anything else, and literally signed off the testing for my module. The go-live process started and each of us were so confident about the modules that we tested. With just minutes to go, to get the help file, I logged into the system in QA environment. I wanted to check my module one last time. Ha! the submit doesn't work!!! what a crap, how can it be, immediately cleared all cache, changed browsers, did all things that I could do, the submit just doesn't happen! Group chat on, submit not working!!! Wow, the first thing that any user would do is try to submit something and it doesn't work! Go-live plan put on hold, investigation on,.. The last time I remember testing submit was one build back, ok, then bring back that build , test it on QA, it worked! The last build has this issue, so what was the reason, a simple suggestion for alignment changed the button position and the functionality stopped working! Would you believe it, yes, that was the issue, reverted back, and it worked again! All were happy, they all termed it as "Minor glitches" in production. But I just could not excuse myself for taking it so easy. My assumption of things would work the way it is supposed to, proved me wrong big time A lesson learnt .. Regression - Toughest part of any testing activity.

It is ok to log an invalid bug

Almost all testers would agree with me on one thing. It hurts when our bugs are marked as invalid or not reproducible or even a duplicate bug. Given the unpredictable nature of software it is quite natural that system behaves differently at times. What we see as an issue at one point of time, may not be seen at a later stage of product development cycle. That however shouldn't prevent a QA from logging that issue. You never know when that would resurface!! Having said that, there is difference between "Not a bug" and an "Invalid bug". " Not a bug " obviously means that it is not a bug at all and a feature of the software, Invalid bugs can either be not reproducible issues or when a functionality changes, the bug cease to exist or it could be anything else. Even the development team acknowledges it as a bug. A vast majority of the invalid bugs could be due to some simple missed things..

Few things that would help any tester avoid the ambiguous bugs are

• Check for the latest version of all files before you begin your testing.
• Check for DB, Server down time , that could lead to lot of not reproducible bugs.
• Check if the credentials that you use are valid.
• Check for all configurations.
• Check for browser, hardware compatibility of the software that you use.
• Check if you have all the prerequisites needed for the application that you intend to test.

When there is an issue, the first thing that any experienced QA would do is take a screenshot of it and then try to reproduce the issue. More important than finding a bug is actually describing it. Video screenshots would help a lot, given that it makes it easy for even the developers to just run the video and find out the issue. If that is not feasible, QA must make sure to describe each and every step that they actually followed. The development team should be able to reproduce the bug based on the steps given in the description. A good bug report can make the life easy for a QA and the developer. Even after all this if the bug is marked as invalid, then take it easy. Try to reproduce it and show them with proper steps. It is not a sin to log an invalid bug, and one does not have to feel sorry for it. Logging an invalid bug is also part of testing:)

Get set go..test!

When I started as a fresher, I honestly didn't know how to start on testing something!Luckily for me the first QA task was more checklist based. All I had to do was follow the checklist, and select the options Yes, No and then complete it. But when it came to regular software testing project, I was totally in a state of confusion. How do I begin my testing,where do I start and more importantly when do I start? Working with a development team as a lone tester, I had no choice but to figure out my own strategy.

This is how I began:

• Prepare a test strategy - Main purpose of testing was to log as much bugs as possible and not just to pass easy tests. Keeping this in mind, based on the requirements, prepared macro level test cases covering all functional scenarios and then prepared test cases at the micro level for individual functionality. In this way, I was able to cover the entire application. 
• Prepare a test plan - The main idea was to figure out the responsibilities, who does what? Since I was the lone tester, I took help of the development team for certain activities. This plan helped us estimate the time, the tasks for each person, the dependencies for each task etc. 
• Test cases- As mentioned in the Test strategy, as soon as the first set of requirements were available, I prepared the macro level test cases. Then based on the software progress, micro level test cases were also written. 
• Test Data- The test data was prepared along with the test cases. 
• Test Environment Set up - A separate QA server similar to the production environment was provided. 

What started as a plan for single QA member continued even when the team grew in size. This simple plan worked for me and my team big time!