QAI QUEST 2018

In less than a month I will be participating at the QAI QUEST conference in San Antonio. This will be the fourth time I will be speaking and I am just as excited about going this year as I was the first time.

It is a great opportunity to see others within the discipline getting together to share ideas, discuss multiple topics and have healthy debates on topics. It is a very structured event with multiple thought leaders there to help improve how we as a community can grow.

This year will be even more exciting for me as I will be one of the leads that will be participating in the Manager’s workshop helping other QA leaders in a collaborative environment to find solutions for problems they are encountering within their groups. This is an opportunity that I am not taking lightly. I am glad to share my hurdles and my thought process of getting past them.

Some of the topics I would be participating in are:

Communication

Estimation

Best practices

CoE

To name a few.

As well as the Manager’s workshop I am also doing a workshop within the conference on Writing TDD Test Cases to Support Manual and Automation Execution . 

I will be showing some techniques I have learned over the past couple of decades on documenting test cases from Unit test to full functional all the while making things clear for automation scripts to be created along the way.

The intent will be to show different ways of looking at things to see where improvements can be made with tweaks.  Since it is a workshop there will be some hands on activities to get more senses involved in the learning process. This way here things will be better retained.

If you are already signed up for the conference I look forward to seeing you there. If not you should take a look and see if you can go. It is always a great learning experience.

 

Risk management and testing

Risk aversion, that is the name of the game. That is what we do in QA, we help determine risks and work through some mitigation or treatment.

Throughout a project there are different views of risk and the ones that get the biggest notice is for the overall project itself. What is the risk to the organization or customers? What are the financial impacts? The ROI? There are plenty of risks identified and decisions are made.

Now the project has started and things move along until, bam, something happens and a bottleneck or worse a complete stop happens and the project is in danger. Happens a lot. So why? Why is it that with all the risks that are assessed at the beginning of a project that issues during development seem to have been overlooked or improperly assessed?

From my experience most of these issues occur either just before or during the execution of any sort of testing. The environment was not set up right. Test data not there. Partners not ready to test. These are just a few reasons that I have come across where things go bad.

Is it something that someone in QA did not foresee? No, we all have identified risks before in any sort of planning. What I feel the issue is that nobody listened until it was too late. I have had a lot of conversations with senior management on why things are they way they are. Those are not fun conversations because it usually ends up that the risks were identified just not added to the overall risks or that it was too late to do anything. Normally the latter is the case.

So what can we do? Obviously the status quo is not going to work. Senior leadership needs to have a better understanding of the entire picture before decisions are made. Do they need to see all the details? No, they just need to understand that there are some potholes in the path they want to take and they can figure out how to navigate them. In Value of QA I go into detail how knowledge management can improve everything across an organization and how QA has a clear defined role in doing so.

QA: Quality Assurance: Trying to avoid issues from happening. There is no reason why risks to testing initiatives should be identified in a project’s risk assessment. Senior management makes assumptions that testing efforts will be easy once everything is built. Then they start getting anxious when it doesn’t. As a discipline we should be preparing them for those moments.

Now is identifying the risks all that is needed? No, there must be a plan. Well two actually: A mitigation plan and a treatment plan.

Mitigation plans should be relatively easy. What are you going to do to make sure this doesn’t happen? It takes a little forethought and in the end has a good chance of working out.

Where I see things need work is a treatment plan. I have rarely seen a treatment plan outside of what I do. In most of my conversations I have heard that when things go bad it is usually an all hands on deck scenario with meetings all over the place to point blame more then come up with a solution. There is no need for that. There is no reason a treatment plan can be decided upon from the start. What would a treatment plan do? Well first off it would reduce the noise as to who is to blame and should get right to the solution.

Having a plan A and B is great, yet having other scenarios thought of is better. I am not saying that every scenario needs to be thought out. There is not time for that. Going with the more probable situations is the best way then having a high level plan of attack for the improbable scenarios. Just a here are the steps we will follow to get us back on track.

Risk treatment seems to be something that in QA should get more focus. Using that and getting more involvement with stakeholders early will help overall with avoiding the big potholes, or at least having the material with you to keep things moving forward.