Test planning is a set of planning activities before testing should be started. All those planning activities are described and explained in a project Test Plan. All test planning phases are for a Test Plan, but some of them could be perfectly used for bugs verification, story and changes testing, etc.
Today I'd like to talk about first item in our list - testing scope, risks and objectives. You can use this not only for a Test plan abut also in your everyday testing. And think this one is the most important process in testing because almost all your time you will perform testing, will check actual and expected results and in order to do that correctly, effectively and efficiently you have to know the scope of your current testing task, associated risks and objectives of that testing task. Do not think that all this information will be mentioned in a Jira ticket or elsewhere. Often you will see a task with just a short description of what was done so testing of that changes is required, or you could see some story with poor description, without acceptance criteria, etc. Not experienced tester can think that the information provided is enough, he has some application or module he can test so he starts some checks. If you are Ok with this approach, then I'm sorry but I've to tell you that this is terribly wrong! This is more monkey testing, because you don't know what to test, why to test that and what risks that change has. So in order to test your change/story/fix correctly - you have to know that change/story/fix well. You need answers for questions like - exactly what do I need to test/cover in order to say that this was tested?, what risks those changes have (whether there could be regression afterwards)?, why I need to test all those areas? It's very good if you are answering all this questions for yourself before start testing of some work item, if not - you should so you could benefit from it.
Ok, lets explain these three questions. So first - exactly what do I need to test? Answer to this question should give you information and understanding of what areas/modules/features of your application has to be covered during your testing. But before that you have to understand and know your AUT, it's business logic and ideally architecture. So you'd know whether small fix here could somehow affect big functionality there. If you do not know your app internal structure - you can ask it in your team, developer who made that change for example. So after that you would know what parts of your application you have to test. For example, you reported a bug that registration form is broken, developer fixed it and gave it to you for retesting. Here you can just perform positive/negative tests for registration, but you also can how and where those registration data goes? This is required because fix could affect storing registered user's data in a DB. So if you got a message about successful registration - actually it doesn't mean that this user was indeed successfully registered, it only means that this message was triggered and displayed, that's all.
Next, what risks those changes have? Answers from this questions could be related to the previous question, but still this is separate concern. You need no know all risks that changes could create and you have to properly asses them, because depending on fix there could be big regression incidents.
And last, why I need to test all those areas? If simple - because it could regress you app in very different places. So this could be answered only if you know your app very well, because you have to know where regression could be introduced so you need to know about such possibility and be ready to make additional checks in different places.
During my QA career I saw a lot of junior testers who didn't think about such thinks and they didn't ask such questions so their overall testing was very poor and a lot of uncovered bugs were left. So I decided that first thing I have to tell my mentee is that what hi is going to test, why that has to be tested and what risks this has.
So, do not forget to properly plan your testing, not just story testing but even bugs retesting. Good luck.
No comments:
Post a Comment