This post is to let you know you different possible scopes within your project as a QAE. You are doing just the testing? Take a breathe and let yourself know some other possible things you could for for your project.
Following are the different phases within SDLC. We will talk about your role in those phases:
a. YOU MUST TAKE OWNERSHIP OF THE REQUIREMENT. Do necessary communications, take notes in meeting, gather them and email to team.
The more we become involved in the communication during this phase, the more we will be able to capture the requirement. One should try to make a requirement sound like “a tale” to himself which he will often tell his team mates in cases when they need them.
This is not a process that will end in this phase. We got to do this throughout the SDLC.
b. REVIEW/READ THE SPEC CAREFULLY a few times, come up with questions. Does not matter how silly the questions are, always ask them. Questions should be discussed first with team and then managers and them US team.
If this is not the start of the project (it has previous iterations), always look at the requirements of previous iterations to check if any new requirement is violating an older one. Or may the new requirement be repeated which the system even does not need. A QA is the one who should come up with these types of findings. Let’s see an example below from a recent TVC:
A guy comes to a girl’s house for a pre wedding discussion session. There are lots of foods, arrangements and everyone is well dressed. There were a lot of guests. The guy’s mother is praising a lot about the guy. The girl already has that guy’s internet profiles (images, videos etc) and she comes up with the images where you can that guy doing bad deeds. Eventually the marriage is not fixed and the motto of the TVC is: you cannot just fool anyone if you have internet.
A QA’s question here could be: if the girl already has the internet profile of that guy, what’s the necessity to bring those people to home for the meeting? That would cost them a lot of money and time and effort which will go to vain at last. Either we can come up with a new idea, or we can keep this flaw of this idea in mind and carry on with this. Just a small finding.
c. BE PART OF IMPLEMENTATION STRATEGY DEFINITION MEETING. Means, when we are analyzing a requirement and saying we can do it, we must check if we can implement this not hampering the performance/core features of the app. In these types of meeting, a QA can be a good listener and try to pick the loopholes/things that DEVs may miss.
Example (impact of knowing implementation in testing):
System already has two types of users (admin/regular). Now in 5th iteration, client is asking a new type of user who can do certain tasks of admin and some tasks of a regular user. Looking at the requirement, DEVs said, it is possible. We will just need to assign them the tasks they can do.
I came up with a question. There is something called two factor verification in the system which is used while user login and this extra security is only for the regular users and not admin. My question here was: will this new type of user need two factor login? If yes, we will need to change the implementation of this two factor authenticastion which will affect the estimation of the task. This was an iteration 1 task which DEVs forgot to think about.
Having questions on any phase of the SDLC does not mean you will always have to prove somebody else wrong or find the holes in their thoughts. Your questions will somehow help improving the system or the process of developing it.
d. KEEP THE SPEC UPDATED. No matter what, whenever there are changes in requirements, the document should be updated. If the changes are from email communications or internally taken, keep the note with reference. This will help us answering questions like “why do I see ‘love me’ button disabled on home page?” to our managers or US team or to anyone.
a. BECOME FRIENDS WITH DEVELOPERS. Take necessary steps to get friendly with the DEVs. It does not need any detail to let you know why this is necessary. All below steps will need good friendship with DEVs. To do that we can be more involved in personal conversation, seek their suggestions in our personal matters. We can have tea/coffee together with DEVs. As far as my relationship is concerned, I sometimes go and make coffee for DEVs and they do the same for me.
b. TRY TO LEARN MORE DETAILS ABOUT THE FRONTEND AND BACKEND PROCESSES. The more we know the implementation, the more we will be able to contribute in the quality maintenance process. It will help us test as well. Let’s take two examples below:
Example 1 (how will it help you in testing):
There is a button ‘love me’ which gets enabled and disabled in different scenario. There might be two way to implement this. One way is to have a Stored Procedure which will take the decision and the second way is to have the enable/disable flag for this button in some db table. Now, for testing a particular scenario, you need to disable this button. You can simply modify table or the SP to generate the scenario rather than executing 10/20/30 steps to disable this button. That saves tons of your time.
Example 2 (how will it help you suggesting in improvement):
There is a file upload feature which uploads files and you can see them in frontend as a user after a while. If you do not know the implementation, you will just upload these files, wait for them to be loaded into the system and then will check from frontend. Suppose you found a performance issue here which is: when you upload large files, it sometimes take longer than expected time to finish loading to database.
Now, the implementation of this task is: a scheduler picks the uploaded files and loads them to database. At the time scheduler checks for files, there might be more than one file. All found files are taken into a batch and scheduler starts loading these files one after another. Once every file is loaded they are first encrypted and then moved to a secured location for future references. Then it goes to next file. Remember, we assume you do not know the implementation.
So, once you reported the issue, developer went through the logs and found out the large file’s encryption is taking long time and moving the file is taking even more time. They fixed it in some certain way. You retested and closed the bug. But, if you knew what happened there and how system works beneath, you could come up with suggestions like: “let’s move the file as it is (not encrypted) to secured location and encrypt it there” or “let’s encrypt the file, zip it and then move it so that it takes less time” etc.
White box testing is fun. Just try it.
c. TAKE PART IN COMMUNICATION/DEV MEETING. It does not matter if the email was sent to a dev, it does not matter if the meeting is about core implementation which we have no clue about, be part of them. The more we get involved, the more we know. We will cover the communication pattern later in this doc.
d. ASSIST DEVS IN DEVELOPMENT. Try to know who is in which phase of developing which task. Talk to them about requirements in a casual way to judge if they are well aware of it. Make fun talking about the requirement, ask questions about it, correct them if they are wrong, correct yourself if you are wrong. Sit beside them when they are coding, do peer to peer review. Do initial tests in a DEV’s pc. Ask them if they need any kind of help from you. This will help you test the task better. This will also help you come up with suggestions in future if the task’s requirement is changed and needs re-factoring. Let’s see an example below:
Example (how you can assist DEVs):
In a system, as per the implementation there are some notification codes which need to be added in share point library which system requires during generating notifications. These codes are needed in dev, stg and production environments. During each iteration there are newly introduced codes which a dev will have to add in all env. You, being able to do that, can do it on behalf of DEVs. This is a simple thing but will always help a DEV happily concentrate into his coding.
e. PREPARE YOURSELF FOR TESTING. We should always be proactive to see the test scopes for the iteration. It may happen that there is a task in this iteration which will need us to upload different types of files with different sizes. We can always prepare them even before we need them. This helps us when we are in rush with 10 tasks deployment on the same day and delivery is just knocking at the door.
f. TECHNICALLY PUSH THE DEVS FOR TASK RELEASES. If we see that we have a lot to test but nothing in hand or you see that deploying task tomorrow will not give us enough time to test it, we can talk to the dev. We can technically convince him to give at least a partial delivery to us or manage it the way it is best possible.
a. DO BAT AT DEVELOPER PC. This will help us eliminate all the issues you would find in 1st 5 minutes after deployment.
b. READ THE REQUIREMENT ONCE BEFORE YOU START TESTING. This often happens that we miss obvious things from the spec. Make sure that does not happen. If time allows we should always read the spec once before we close the task.
c. TRY TO AUTOMATE TESTS. Automation is an awesome way to get more times to be spent after thought process. The less time we can spend in testing, the more time we can spend on doing other necessary things. Testing is obviously our core job to do; but, automating it will give us more performance, more flexibility with time and more efficiency.
d. MAKE SURE YOURS ACTS ARE FRIENDLY WITH DEV WHEN YOU FIND ISSUES. Remember, our job is to get the job done with quality. Accusing the dev will not help in long run. We can always try to get things done by them with a smiley face. Appreciate them for good works.
I remember myself often saying “আরে বস, কোন ইসুইতো পাইলাম না। ধুর মিয়া, কয়েকটা ইসু দিবেন না? চাকরি থাকবো না তো (Boss, didn’t find a single issue. You guys should leave some bugs so that we have our job intact.)” or “বস, পাকা হাতের কাজ (Boss, that was a master piece)”.
This section was not to teach you how to test. It was more about the co-ordination and attitude you need to have in yourself and team.
Bug Fixing Phase:
a. ALWAYS HELP DEVELOPERS UNDERSTAND THE ISSUES YOU REPORTED. That will always help developer to fix it in more compact way. Does not matter how vividly you reported the issues; always explain it to them when they need it.
a. CREATE AN AWESOME TEST SCRIPT. When we are writing test script, we should think of ourselves as artists who are giving a written speech of their artwork in a written form to consumers. Give every possible detail on the tasks and scenarios. Guide them with all possible information, files, processes etc.
b. COME UP WITH A FINISHED PRODUCT. We will never deliver it half done. Half done might have different definitions. It may happen we released a product without release note. It may happen that we delivered a product without test script. It may happen that we sent such a release note which needs 3 hours of editing by manager before sending to US team. These are always annoying to managers. We should think from the receiver’s perspective and provide our release with all necessary arrangements. We will discuss more about this in communication section.
c. ALWAYS TRY TO GET THE PRODUCT READY HOURS/DAYS BEFORE. This will help us get the pressure off of our shoulder. The extra padding time always helps if us need any last moment change/deployment.