Learnings from 15 months…
Project: re-writing a legacy application; and building Outlook Add-in and web application (in Silverlight). Completed 15 months in a project and today rolling off for another new beginning in a different project. I was involved in close to 50 stories as a QA owner and have written over more than 100 test cases and logged over more than 350 defects.
I joined in a 7 member QA team and day –1 was like sitting in a room “Nalanda” and doing regression while going through the test scenarios. There were quite some number of test scenarios at that time itself and the application was buggy. Initially I thought I will start reading the narratives to get a hold of the application. But ask me it’s tough in a project which is older than 6 months. You can’t do it and you will have to find a better way.
So what next, I started doing Exploratory testing and that increased my confidence. While you get to know the feature implemented and how actually system is behaving rather than how it should behave(this part will probably come from BA when they wouldn’t have tested the application but could just recall the acceptance criteria in the Story).
Another way of learning which I found really effective is “Pairing” with a fellow QA. Your pace of learning increases. You learn fast. You get to know “System limitations”. You get to know that “this part is not implemented”. You get to know that this feature is “buggy”. Even though something is not working the way you anticipate, you will get to know/listen “this is how client wanted”. Sometimes as a part of pairing, even the “frustrations” will get passed on. :)
Now this whole process will take around 2-3 months. This will set the ground for you to start understanding the requirement discussion. You start feeling the pressure of “Sign-Offs”, “QA Velocity”, “Hang over”.
The next phase; it’s all about improvising/enforcing process. Since you have been in the system for quite sometime, you know what works, you will know how to speed up the Story Testing, you will know why “Dev Box Testing” is important. You will know how to plan up regression and around which area. You will also get to see the compromise between bugs and Story Points(committed). You will also get to know that Test Inventory Management is the team work and not individualistic task.
Another quite important learning is something which failed once may fail again. Defects which you found in QA Environment and unable to reproduce will come again in UAT. “Cannot Reproduce” is a silly reason to close the defect. Defect is the outcome of several parameters like “Environment”, “Data”, “User Actions”. So each and every defect is a valid defect.
Rest will share in another blog if time permits…
I joined in a 7 member QA team and day –1 was like sitting in a room “Nalanda” and doing regression while going through the test scenarios. There were quite some number of test scenarios at that time itself and the application was buggy. Initially I thought I will start reading the narratives to get a hold of the application. But ask me it’s tough in a project which is older than 6 months. You can’t do it and you will have to find a better way.
So what next, I started doing Exploratory testing and that increased my confidence. While you get to know the feature implemented and how actually system is behaving rather than how it should behave(this part will probably come from BA when they wouldn’t have tested the application but could just recall the acceptance criteria in the Story).
Another way of learning which I found really effective is “Pairing” with a fellow QA. Your pace of learning increases. You learn fast. You get to know “System limitations”. You get to know that “this part is not implemented”. You get to know that this feature is “buggy”. Even though something is not working the way you anticipate, you will get to know/listen “this is how client wanted”. Sometimes as a part of pairing, even the “frustrations” will get passed on. :)
Now this whole process will take around 2-3 months. This will set the ground for you to start understanding the requirement discussion. You start feeling the pressure of “Sign-Offs”, “QA Velocity”, “Hang over”.
The next phase; it’s all about improvising/enforcing process. Since you have been in the system for quite sometime, you know what works, you will know how to speed up the Story Testing, you will know why “Dev Box Testing” is important. You will know how to plan up regression and around which area. You will also get to see the compromise between bugs and Story Points(committed). You will also get to know that Test Inventory Management is the team work and not individualistic task.
Another quite important learning is something which failed once may fail again. Defects which you found in QA Environment and unable to reproduce will come again in UAT. “Cannot Reproduce” is a silly reason to close the defect. Defect is the outcome of several parameters like “Environment”, “Data”, “User Actions”. So each and every defect is a valid defect.
Rest will share in another blog if time permits…
Comments
Post a Comment
Your comments will be reviewed and then published !