All good things come to an end

Hello everyone,

I have been blogging on this site for close to 5 years. I am very appreciative of all your support in following my postings. With that, I will be closing this site down as of January 2020.

Over the past few months, I have been focused on my new career path. Due to that, I have been managing two websites. Wich is a bit daunting.

The good news is that I will continue to have my contributions to SPaMcast and will continue to blog on my new site Berriaultandassociates.com. I will actually have to blogs going there: QA Corner and Finding Value.

I am currently moving over the content from this site over to the new one. I expect to have that complete in the next couple of weeks.

On to new beginnings

 

Consistency and determination

As most of you know I am heavily involved in Brazilian Jiu Jitsu. For the past 11 plus years I have been training and competing in the art. In one of my most recent posts I talked about how one week at a tournament opened my eyes to how I am personally and professionally.

This past weekend was the start of my next chapter in this art and it made me think more about previous conversations I had on SPaMCast about careers and how individuals should approach their careers. This weekend I got my Black Belt, which is my second one. I have a 3rd degree Black Belt in Tae Kwon Do. The difference between the 2 is the TKD first degree took me under two years to get, which is about average for that art. The time and dedication for Jiu Jitsu made this weekend’s promotion so sweet.

Just like progressing in your career when you get the goal you have been aspiring to is such a great feeling. The time to learn something new, the learning from decisions along the way and some sacrifices you made to get to were you want to be makes it so rewarding.

When it happened a flood of emotions took over. I felt on top of the word. After the belt was put around my waist I addressed the other students and said they are lucky to be doing what they are doing. They are on a journey that has great rewards along the way, and that those rewards are what they make of them. Nobody else.

Much like a career, nobody but you have the say in what can or cannot be achieved. Keep pushing and striving to be the best at what you do. Do not compare yourself to others as that will get you no where.

Great things can happen when you work hard and remain consistent.

Testers and Test Engineers

https://spamcast.libsyn.com/spamcast-550-conways-law-and-process-improvement-test-engineers-and-testers-essays-and-discussions

In my recent post with SPaMCAST we talked about Testers and Test Engineers.

Most view the two very differently to the point where Testers are called “Manual Testers”. To me that is a load of crock. Whether you are dynamically testing through the use of a keyboard or through the use of a script it is testing none the less. They are two completely different skill sets that need to flourish for an organization to be successful.

For the non Test Engineers, they play a very pivotal role as they are normally the first ones on the scene to see what is being done. Yes, the Test engineers see it quickly as well (if the development shop is set up correctly), yet it is the testers who use a lot of that initial brain power to understand what is going on. They also normally have key insight on the application and could see issues a lot sooner then others.

That is not to say the Test Engineers could do the same thing. On the contrary they have a little say as well on how things could go. As they are, sometimes, more technical they would see things from a different perspective. Maybe from and architecture perspective. There could be a new workflow that is about to be introduced that will cause performance issues. Maybe there is something already in place that will cover what is needed and they know the path to get there.

From a title perspective I get it, it is needed for recruitment. People need titles to figure out where they are. A few years ago I got into a heated discussion about titles and Agile. He was a generalist, and he saw that everyone can switch roles within a team if need be. To me, at the time, was insane. See I was coming from mostly waterfall shops. Yes they did start going agile, and I had my understandings of it just not to that level.

Now I feel there should be a merge. Why limit individuals on what they can and cannot due? I have seen Test Engineers from different backgrounds, one even from a finance workstream. Things can be taught and learned. It is time for other organizations to recognize that and get on board. There is a lot of value in it.

Half way through the year and so much more to do

This year seems to be flying by and I haven’t gotten back on track with my book. Like a previous post it is hard to get that initiative going.

Work was probably the biggest blocker over the past six months. In technology change is inevitable and if you are unable to handle it things can go sideways fast.

One of the good things that happened was I revamped an SDLC and provided additional help for Product Development. I did a lot of research by articles, books and YouTube. Speaking of YouTube I would like to get back to normal use and see dogs do silly things.

Some of the great reads I had were:

Sprint: Solve big problems and test new ideas in just 5 days by Jake Knapp

User Stories Applied by Mike Cohn

Agile at work by Douglas rose

Still going through more books to help gain even more knowledge to help organizations succeed.

There were countless YouTube videos that were hit or miss. The joys of the internet. There was one video that hit me hard with moving in a direction to create a more innovative environment:

This talk turned on a light bulb and brought things that I was working on into a new light. Things started to click and fall into place.

Next week I will be finally taking some well deserved time off and will spend time on my book. So I will be dusting off my outline, what was written before and more than likely making changes with what I know now.. Looking forward to it.

Reflecting on QUEST 2019

Well it has been a couple weeks now and I had a lot of time to reflect on the goings on at QUEST 2019.

As always I enjoy attending and speaking at this conference. Meeting new and old friends is always a plus. The offline discussions outside of the planned tracks are always insightful and a learning experience for everyone.

I had the great opportunity of speaking on two occasions and participating as a panelist for the Managers workshop.

I’ll start with the full day class, Finding the Why for QA. This was fun and interesting. It definitely made me think through the presentation and working with the attendants.

See I took the idea in the book Finding your Why and wanted to get a good Why Statement for the QA discipline as a whole. The other tough part of the course was that it is meant for people that all work for the same organization and have some familiarity with each other. Here I was taking people who did not know each other until they sat down in the room.

The other tough part was the presentation was meant for a bigger class size than what I had, 5 attendees. What happened was that I was burning through the deck at a faster pace then what I anticipated. Which meant I had to adapt and pull more information out of those that attended. Int eh end it worked out as there was a lot of good conversations and we came up with a good start for a Why statement for QA.

To observe and share holistically so that Teams are empowered to innovate and create harmony”

I did get some feedback that it seemed I was dragging things out, and I fully admit it. Doing speaking engagements for the past 7 years I have prided myself now that I can have it all paced for the time slot I’m given. As always theory and practice don’t work out some times, and this was not one of them.

So for those that attended that class I will apologize now that I seemed a bit stuck with where to go and how to fill the time slot. I do think that in the end it all worked out as we did come up with a kick ass statement.

Next was the Manager’s workshop. This was the second time I participated as a panelist and it was great. One of the main topics I was there for was metrics. As most of you know I love metrics and talking about metrics. This was not different. I got to share some stories of my pitfalls and successes. As well as give guidance of what they could do to improve everything around them.

My last talk during the conference was about estimating. The pain of what everyone goes through. This was probably the most attended session I have done in a very long time. We talked about different methodologies and how estimating should be done continuously and revisited to get better over time.

Overall I enjoyed my time, as always, and I look forward to next year.

In the next little while I will write other posts to go into more detail of what I spoke about at QUEST. Since we all know I love knowledge sharing.

Third party testing

Third party testing is something that can cause some heated debates on whether to use them or not. The effect they have on an organization and quality of the output.  Here I will put in my two cents and will carry the conversation more if anyone wants.

For me I have no issue with it. Now with that said there are some conditions I have, that I will go through (if not this will be a very short post), and I will also go through the arguments that I have heard on the subject (with my take, of course)

Here are my conditions though I have:

They are used for staff augmentation and not just cheaper labour.

Want a good way to get a bad reputation is replace full time staff (letting them go) to be replaced by a third party resource. Here is a good example of some bad press when that particular model is done.

Staff augmentation is meant to cover off the additional workload so that teams can produce more, when needed. When using a Third party vendor they have the ability to bring on resources with the skill sets needed at a faster pace than hiring processes in North America. Usually within a week or two you can have a resource in the system starting to get some work done. Compared to a usual hiring process it could take a month.

They are resource to scale. Most of the third party vendors that I have worked with can get 1 to 10 people in a short period of time. That is there business model and it is done well on most days. You may get the odd hiccup or delay, yet based on needs it is still quicker.

Most Third Party resource vendors also allow for quick turnaround. What I mean is if a resource is not working out as planned or they decide to leave that organization they can bring someone in fairly quick. Or if things start to slow down for your organization or there are budget cuts needed they can be let go first and allow for a core team of full time employees to stay unaffected to continue work. When I say unaffected I mean: not let go.

There are other advantages, as well as disadvantages to using a third party model. For that I will go into a little more detail during the arguments that I here regarding the model’s use.

Argument #1 – You are going to replace our jobs to them.

When I first heard this argument I would scoff at the idea. That was until stories, like the one above, happened a few years ago. I always thought it was about augmenting the staff to meet the needs of the workload. I still believe that and still lead by it. There is still a part of me that is cautious and willing to defend when needed.

What I believe is that when using a third party it is actually going to bring in more work and that work will be more fulfilling as the easy, menial tasks can be handed off to the additional resources. It makes total sense and it is generally how the model works. I will get into why with the second argument point.

Argument #2 – They don’t know the system.

Yep, you’re right. Here is the catch: so would any new employee who walks into the door onsite. There is going to be a learning curve and the work they will be doing at first will not be difficult or intricate. An organization would not take a junior analyst who just came in to work on day one and assign them a multi point of failure set of test cases then walk away. That is a recipe for disaster. So why would we expect the same for someone that is on the other side of the world that is starting to work with you?  They are there to help and will need to have a good training system in place to provide that.

Argument #3 – The time delay is unmanageable.

If that was the case nobody in North America would follow this model. Yet there are a lot of very successful organizations that use this model very well.

There are so many communication and workflow tools out there that the time zone difference is more of an annoyance then anything. As well my experience has shown that they are willing to work around our schedules and ensure there is proper communication between the two locations.

There are other arguments out there and, to me, they are based out of the fear of the unknown. If a company is just starting to use this model and nobody has been through it before, it can be scary.  Once they open up and accept it for what it is, Staff augmentation, it can be beneficial to everyone. The opportunities of innovation can start to arise as the trivial work can go to the additional resources while the teams onsite can focus on more “fun stuff” while looking at ways to do things better.

I think the one key thing that I need to stress, I have said it throughout this post, it is all about staff augmentation. This has to be realized from top management down and it must remain consistent. Any deviation from that and it will erode trust throughout, which in turn will erode productivity and finally quality.

 

 

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.