Smart QAs : An Approach to Software Testing

We have a smartphone, smart car even a smart house then why can't a testing and a QA can't be smart.

#SmartQAs

Everyone teaches or says that QA should be involved from the beginning of SDLC, this just became a myth. Before touching the point let's take look at the current process which is QA start testing when a story gets deployed on QA environment before that QAs don't even care whats happening in the background to a specific story. Many of you may disagree with me, but this is 80% scenarios of today's testing.

Extinction of manual QA

What is QAing? is it just writing and executing test cases, creating bugs and verifying them, no, it's not. For me, QAing is finding such a scenarios (based on requirements or past experience) to make sure system is performing as expected under it. This thinking of complex scenarios can't be overtaken by #automation or #robots as they say QAs are going to be replaced, again a myth, it's never gonna happen. One thing we need to understand that QAs job role is changing, it's not just writing test cases and executing them anymore. It involves getting requirements, debugging, talking to the client, being a BA for the team and much more. Every QA needs to know coding, means, come on, it's better to know in any case.

We also need to accept the fact that most of the job openings for QAs are expecting automation, though they may put on manual testing coz everything can't be automated.

How to be a Smart QA

I will use Agile to tell the story as agile is spreading through software world. I personally follow this practice, it improved the quality of my work and reduced the time spent on a story.

Step A : Prior to sprint planning day

1. Identify the story for next sprint and starts grooming it. Though being a QA can't go through technical details but from a business point of view, we can make sure everything is answered.
2. Understand the story completely and then prepare a set of questions and post it to your BA.
3. From this point a QA should start thinking about scenarios, one can share some of the scenarios also. At least 20% of scenarios should be done by now.

Personal benefits :

• People from the client-side will know you.
• As you have complete details of the story, your team will notice you

 Step B : Planning day

1. Discuss the story with the team and share all the details.
2. Make sure that team and you understood the requirements
3. At least 50% test scenarios should be done by now. 
4. Ask the developer/team/SM to reserve time for Dev-QA pairing before actual development starts, this is a very crucial part.

Personal benefits :

• Team will start seeing you as a valuable
• Your trust factor will increase and people will listen to you

Step C : The Sprint is started

1. Finish writing all the test scenarios in whatever management tool you use e.g. Jira
2. QA needs to understand his developer, his good point, bad point, this relation is like husband-wife, both need their own space but also has right on each other.
3. Discuss the story, requirements and test scenarios with your developer.
4. Make sure Dev understood everything and you-Dev are on the same page, this is very important.
5. If any doubts arrive at this point, directly talk to client(a person whoever is owning that story)
6. As a QA we need to understand the dev's works is not so easy, we need to release their burden of other work than coding, we should take responsibilities of such work if any
7. At this point 40% testing should be done, I know that even the development is not yet started, that's why I said Dev-QA needs to be on the same page, in this pairing QA should make sure that at least 40% of test scenarios are gonna pass

Personal benefit :

• Your leadership skills will start to show off
• You have opened a new opportunity for yourself as BA
• Your client interaction is getting increased as well as team dependency 

Step D : Development is started: Avoid the introduction of bugs

1. While development is on, sync up with your developer, but make sure you are not annoying
2. Start testing on their local machine during their development and give them your early feedback, this will stop the bugs from occurring.
3. Onc can also start writing automation script at this point, considering one is not working on another story.
4. At this stage, QA should be confident enough that 70% tests are already covered.

Personal benefit :

• Your planning skill will on showcase
• You will portray yourself as dependable resource and also as lead
• One can focus on things apart from testing

Step E : Testing phase

1. After receiving the story on QA env, quickly finish smoke/sanity testing and focus on story testing
2. Start with complex scenarios first, within 1hr you will understand if the story is good or bad
3. This 1st hour will tell you how much testing needs to be done
4. Execute the scenarios is such way that in one test you cover 2/3 scenarios, parallel test case execution etc.
5. one of the nicely written blog for test case writing here

By doing your work smartly one can finish it before given time(no one needs to know) with higher quality(everyone needs to know) and still leave a time to improve ourselves in other areas. Such time can also use to automation or to explore other things which will intern ease your work.

Finally, it's the demo day, prepare yourself for it give an awesome demo and have a nice drink at the end of sprint coz tomorrow is sprint planning and you don't need to come early.

My other blogs.

1. Software Testing from Home

2. My First Trek

3. Stuttering Software Engineer

4. Unsuccessful Sprint End with Bugs

Please leave a comment below.