Tips to write effective emails

These are some tips to write more effective emails. Hope these will help you.

a.    ALWAYS REPLY TO THE EMAIL THAT WAS SENT TO YOU. Do not leave any email untreated. If the email said “thank you”, you should at least reply “you are welcome”. If a simple instruction was sent to you like “please keep this in your to-do list”, you should say “noted”. This single word reply will let your manager know that you actually read the email and kept it under your to-do list.

b.    ALWAYS TRY TO BE IN EXISTING EMAIL THREADS. Do not open new email threads unnecessarily. Even for internal tracking, pass your emails in existing thread. Means, client asked for a clarification and you are communicating internally within your organization. Even in that case, communicate within that email thread. Ohh yes, don’t forget to skip client team when emails are internal 😉

c.    OPEN EMAIL THREADS WITH PROPER SUBJECTS.  The standard convention could be “Project Name > Iteration > Topic”.

d.    WRITE NEAT EMAILS. This is very important. The information should be clearly readable, alignments should be perfect. Your documentation skills should be represented in your email. Below is a screenshot from a standard email:
Having a look at it you can tell it is written in a few paragraphs with some tabular data. This is easy to read and track.

Project Communication & Coordination Scopes for a QA in a Project

As said a few times in my last post, project communication and coordination could be one fine way to turn yourself into a very dependable QA from just a software tester for your project. If you are just doing the testing for your project, you have no idea about many other places you can/should contribute into. Following are some tasks you may check out.

1.    FOLLOW ALL PROJECT COMMUNICATIONS REGARDLESS OF THE TECHNICAL DEPTH. If there is a communication going on between BD team and US team regarding different web services for dev, stg and production sites; we feel no necessity to follow it. But, if we did and if we knew that dev and staging has the same web service Url and production is different, we could easily know that if this fails in dev, it will fail in staging too. We will be able to notify the respective dev or the team.

2.    BE PROACTIVE. We should always remember that prevention is better than cure. Let’s say developer is developing task A. In the requirement we see something that has discrepancy (which was not found in requirement analysis phase somehow) and we have taken an internal decision (due to obvious reasons like spelling/grammar changes). We should not stop there correcting it. We should send it in a note to manager/US team to make sure they know whatever we are changing. Means, the implemented deviations from the spec should always be reported to product owners and that’s a QA’s job as an owner of the requirement.

Another good example of being proactive here: Suppose your manager has assigned you a task and the deadline is 3:00 PM; ideally you will deliver it within that time. But, if in case you can’t finish it by 3:00, you should not wait till 3:00 to fail delivering and then let your manager know about it. The worst case would be, your manager comes to you at 3:15 and you say “hey boss, I will need 5 minutes more”. The communication should always be like: you assess your task in a regular interval and try to have a forecast of what’s going to happen. If at 2:00 you already know that you cannot finish it by 3:00, let your manager know immediately. Give him an updated deadline and ask him if the deadline is alright. That will help your manager to plan accordingly.

You can do the same when you are asking for input from any DEV. But don’t hesitate to ask it in the last moment if it is urgent. That’s the place where your friendship with DEV will count. Think from your manager’s or team’s stand and see what they are looking for from you. Try to be/do that even before they ask for it.

4.    DON’T BE LATE SENDING DAILY EMAILS. Always remember our manager will need to review them before sending to US team. We should be reasonable to our managers and try to finish it early around 3:30 or 4:00.

Software QA does not mean just testing the software

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:

Requirement Analysis:

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: