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.

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.

Building testing skills

In the over 25 years I have been in the QA discipline I have come across two types of discussions about testing skills.

1 – It is an art and it is inherently it is a trait within an individual that cannot be truly taught.

2 – It is a mindset that can be taught and flourished to get the right outcomes and succeed.

I stand with option 2. Anyone can be taught anything and have them understand what it is they need to do to have the right mindset. Much like developing code or writing requirements it is all about how much you enjoy doing it and the ease it is to understand what is being done.

I have come across individuals that just couldn’t get how to test software. They understood the processes and what was needed they couldn’t understand how to get the tasks done effectively. Does that mean they were bad testers? No, from my view was that it was not framed in a way for them to get it completely.

One of the things that I have a hard time with with the multitude of courses out there regarding QA and testing. Some of them are really good and provide the understanding of true QA and how testing is a small component of a very big thing. There are others that just focus on testing and work on just the execution, not really providing the reason as to why they are doing what they are doing.

I have even come across some colleges that provide courses in QA. The descriptions I have read on a couple don’t give the real indications of what QA actually means and solely focuses on testing. When I researched these course it was a few years ago. A couple of them now have been discontinued with those schools. I can see why, partly because they never really gave the value this discipline has.

I have stated before I would love to see an entire program on QA within a college. Why not? They have them for engineering and development. It only makes sense.

In the meantime, here is what I do to build the skills of anyone that wants to do QA and testing.

1 – Get them to ask questions? They don’t have to get into the full details of what is going on, yet they should ensure they are getting enough details to get the job done effectively. Understand how the code works. When I first started QA and Testing I went overboard on writing cases and doing work. Since I didn’t understand the flow it got out of hand and a lot of duplication of work.

2 – Think efficient. To many times I have seen inefficient was of testing work that took too long to get done. Line up the cases in a flow, be smart about recording results, don’t write cases that are big.

3 – Review, review, review. This is one of the most important things I stress. Everyone within the delivery team should all agree to what the expected outcome a test is or that there is enough detail in requirements/stories to get moving on development.

The interesting thing here is what I just talked about is nothing new. There is plenty of literature out there that says basically the same thing. So if that is the case why is it difficult to build the skill set? Who knows, maybe management lack of understanding, conflicting views of what it means within the discipline, or no time to get that knowledge.

I fell if, at the very least, the three base methods I provided will give guidance to search out that knowledge. Get what is needed to improve professionally and the organization as well.

For me personally I am trying to draw out plans for a proper college program for QA, and I mean true QA. Obviously there will be some components of how to test, where I want to really focus is on Quality Assurance with Software. I want to build the community and help show the value.

Coverage – Pros and Cons

Code coverage, the goal of companies try to attain in software development. To understand how much of the code is exercised and better understand how and what needs to be tested when a change occurs. This is a great thing to have in any software development that will help teams become as efficient as possible to get to a quality product for customers.

As this is something has extremely high value to an organization how could I put “Pros and Cons” in my blog title? You’re right the concept of coverage are highly valuable, when I talk about “Pros and Cons” it is more to do with what is needed to get done to get that understanding of coverage.

The reason I am bringing this up stems from a vendor cold call I got for third party testing services. In my position I get a lot of those calls, and for the most part I do not have an issue to start a conversation to see what they provide. As long as they are able to differentiate from all other third party vendors. In this one call there was one statement that came out that peaked my interests and I pushed back to get more details. That comment was “We can have 100% code coverage through automation.” Sounds too good to be true, right? Well in my experience it is. I have never seen any software shop that had 100% code coverage through automation. There are too many variables out there where to do the work for that statement to be true it would take a lot of work.

Before I continue on with the above comments lets go through what I see as the pros and cons.

Pro

• Automation coverage can target specific components
• No need for full regression testing with a change
• Better estimation to changes, more accurate
• Shortened test timeframes

There are more and there is plenty of literature out there that will go into details. Here I just wanted to list a few and foster some conversation, as always.

Cons

• A lot of effort needed
• Tedious
• May not be completely accurate
• May not have full understanding of code

Again the list of the cons can be a lot longer. The good news is the cons are issues that can be worked on and resolved within the company to get to what is needed. There is no technical reason or roadblock. It is about getting the work culture changed to tackle these cons.

There are software packages out there that will give you the code coverage an organization desires, Like all tools it is all about how the tool is used to get the most out of it.

Do I think an organization can have 100% coverage? Yes. In automation? Maybe. Technology is getting better and better over time that it is something that could be achieved. There are a lot of other variables that need to fall into place that will allow it to happen. Consistent coding practices, full knowledge sharing within the teams, and full cooperation between everyone within the organization to name a few.

 

Better late than never

In my End of the year blog – 2017 , I mentioned I was going to do some changes to this site. Life and the holidays definitely got in the way. Regardless I have started to make the changes I want to improve my message going out and to make it a more enjoyable site for you.

Now I will say the changes will be iterative as I get back into the web development mode and blaze a new trail, actually get rid of the brush that covered the trail I went down all those years ago.

One of the changes you will see is the web address. Gone is the generic Word Press name and now it is QAcorner.blog. I am really excited about this as I hope to get more people to come in and join the conversation. As I write this, I have been told the link might be wonky for the next three days as it is getting set up. As a QA person I did do a quick check and it works, there might be intermittent outages.

The other cool thing that is happening now is I have actually put pen to paper, well fingers to keyboard, on my book. This is something I have been planning to do for the past three years, and now I am taking the leap to make it a reality. I intend on using conversations I have during my sections in the SPaMcast podcast, my blogs, my talks at conferences and reading others views. I have not given myself a deadline, yet, on when I will be done. My hope is that by the spring I will have a good amount of work done that I can have discussions with a publisher to get that ball rolling.

I cannot that you for your support as you read my views on issues, concerns and views of the QA. All I can ask is to pass the word and share your views with what I discuss. By all means disagree with me and show another side to what I wrote. I will never call myself and expert or a know it all. My main goal is to foster conversation so that we all improve this great and needed discipline.

Thanks,

Jeremy

End of the year blog – 2017

Well this has definitely been a great year for my QA corner blog. I have had more visitors and more posts read this year than all other years combined. For that I say thank you to all of you that have come in and read my thoughts on QA.

This year has been a big year for me, first full year with a new company, getting more exposure and visibility within the QA discipline and putting my thoughts to actions. It was not all sunshine and lollipops, there were some very stressful times during the year where bad news had to be said or where my actions didn’t get the desired outcome. Although those situations happened I still stood in front of everyone and took accountability with what happened.  Some of it I could have easily put it on someone else, yet I did not. Why create strife within a team when it is easier to move on and get a solution?

I got to speak at QAI QUEST again and got invited back for next year. This is something I thoroughly enjoy doing with discussing ideas, good and bad, is something that is needed more within our discipline.

2017 also marks the 24th year I have been involved in QA in some form. My early view was very simplistic: Go and try to break the software. From there it got me to delve deeper into what is needed for QA. Now that I am being viewed as a thought leader is something that my younger self never would have thought would happen.

I think the best part of the year was being able to put what I talk about into action. My team has done amazing things over the year, where there have been noticeable improvements from the beginning to the point now where everyone in the organization looks back and is impressed with what we can deliver.

I find it interesting that I continuously get compliments for what has happened and I don’t really accept it. My response is always that the team are the ones that did it, I just gave them the vision and direction. I guess that is the modest part of me. It would make sense if I was the only one that did all the work and made all the improvements myself to take the credit. Here though is not the case, I am a leader and provided the leadership needed to get to where we needed to go. I did roll up my sleeves and helped out with some of the work, that is what leaders do. It also allowed me to see my direction first hand to ensure it made sense with where I wanted us to go.

2018 will be my 25th year in QA, a quarter of a century of my life in something that most people do not stick around in. I am a big proponent of a good, successful career in QA and that there is more to it than just executing test cases. There is so much more that can be done and I want to be part of the other thought leaders making the QA discipline given the rightful value it deserves.

One of the other changes that will happen next year is the expansion of this blog. The amount of viewers I have seen over the year tells me it is time to do more. Along with the SPaM podcasts contributions that I do and tie my posts to them, I will also be doing video blogs. These blogs will be me just chatting away or small tutorials on subjects, who knows where I will go with it. If you have suggestions contact me.

So as 2017 starts to fade 2018 looks to be an even bigger year for the QA Corner and myself as well. I hope you all have had the best 2017 possible and I wish you all the best for 2018.

Involvement During Requirements

Shift left, how I despise this term.

“Jeremy, what do you have against the term? It is the new thing going around that is going to make software development easier.”

I have nothing against the concept, it is a method that has shown benefits when studied. What I despise is the term itself and the glorification of what is essentially an old methodology, just repackaged.

Regardless of my thoughts of the term shift left the concept is important. A lot of studies out there show the earlier the team gets involved in something the better it is for execution. Whether you are building a house or the next big software it only makes sense.

What about the methodology? Waterfall, iterative, agile, DevOps….. It is all the same, QA should get involved early. They should not have a say in what is actually needed (that will be another blog), yet they can ask for some more details in preparation of what needs to be tested. Asking for these details not only helps get the testing effort prepped, it also helps development to have clear direction and that everyone is on the same page.

The key thing to remember is that early involvement is not the silver bullet. It is just one of many tools out there to make delivery of products faster and with high quality. It has to be integrated with so many other things, automation, stakeholder management and governance just to name a few.

Maybe my next blog I will go in deeper on my thoughts of repackaging methods instead of keeping what we are using and focus on that.

Speaking of blog I would like to say how blown away I am about the number of visitors I had so far this year. I started this a few years ago and tried to be consistent. It was tough, that is until I started to be a regular guest on SPaMcast podcasts. It has been a great year as I gather content for the book I am compiling.

If there is a topic you would like to hear my thoughts on let me know.

Surprise: Part 2

As some of you know I like to compete in Jiu Jitsu. I love the art, the community and how it is just as much a mental game (sometimes more) than it is physical.

A few weeks ago I competed at the World Masters Championships for the third time in four years. The tournament itself is exciting and the competition is fierce. Each time I went I spent close to 8 solid months getting myself prepared.

The first year I went was more about just being there, than competing. It was my first big international tournament of this magnitude. I went in with the best intentions of winning and that did not happen. When it was all said and done I was not upset. It did suck that I lost when I spent so much time, effort and money to get there. What didn’t suck was meeting a lot of cool people and legends of the sport. It still puts a smile on my face thinking back on meeting Wellington “Megaton” Dias.

The second year was all about my health and weight. To the point I focused a little too much on it and it impacted my game plan in the end. Now fighting the overall number 1 guy in my first match did not help. This time I took that I can achieve anything I want as long as I am determined.  I was upset that I lost, that year I sacrificed a lot to get to where I was and I felt that I let a lot of people down, including myself. In the end I did dust myself off shortly after I came back and started planning for my next trip back.

The third time around I had everything set. Health and preparation was all there. I had my game plan lined up and I worked my butt off to get myself through most situations. I drilled hard leading up to my fight day and felt confident. The plan was set. Then it was fight day. Nerves did set in, my poor fitness watch was going a little bonkers with my heart rate as I waited for my turn to step on the mat.

I got through to the second round and I was still nervous. That didn’t affect how I was going to execute my plan. I get called on the mat and I start. In my head I had the plan working, things were falling into place and I decided to go with my big throw. At that time the biggest surprise happened. Just as I was executing the throw my opponent happened to take a step in the right direction causing me to fall hard onto my back. It was so fast and hard it took me a few seconds to realize what happened. I was in shock at the turn of events. Unfortunately the position I was in gave my opponent the perfect opportunity to finish the fight, and he did.

As we got up and the referee raised his hand I was still trying to figure out what happened. My opponent was cool afterwards as he was concerned about me being injured as I did fall pretty hard. Again I love the community. As I walked off the mat and behind the stands emotions took over. I was upset that all this prep was for nothing. I got caught by surprise through a chance situation that had a low probability of happening. It took me a few days just to watch the video of my fight. Mind you eating a lot of food did help.

Last week I was relaxing and thinking back on the year and I remember my previous post Surprise and I started to tie what I said there to what happened at the tournaments. The two scenarios are no different from each other. The best laid plans can get thrown out the window when that one unexpected thing comes into play and causes havoc. Looking back now I no longer get upset, I now look at ways to mitigate that situation so that if I get caught again there I can get out. No different than when something happens in a project that was unexpected, you deal with it at the time and plan to mitigate it before it even happens.

Testing packages

The question came up recently; what is the difference between testing a package to in house software? The very quick answer is none. Now before things get heated there is a longer explanation behind the quick response.

What is the general principle for testing? Making sure the change coming in works as it should and to mitigate risks of failure seeing how applications react in exception situations. Whether the change is in an application itself or there are peripheral systems that have changed or be impacted by others. Things still need to be understood, planned, executed against and validated.

Where the difference lies is the Service Level Agreement or contract the organization has with the vendor of choice. Most organizations will have sections in contracts that state the level of quality and test expectations they have with the vendor of choice. Normally they are very high standards. After the delivery of the change there is some form of testing that goes on afterwards.

Look at OS changes and updates. For the most part they are pushed to systems without a second thought. Personal computers get them all the time. Does that mean that Jane Smith will specifically go out and test all the changes that come in to her computer? Not explicitly. For organizations who use a third party software that is embedded in their product that is where things get a little less implicit.

Embedded software is becoming the thing to do as it is easier to partner with someone that already has functionality built and get it integrated than to build in house and potentially lose out on clients to the competition.   Normally this is a very detailed process when an organization that makes that type of decision, for the sake of the blog I am making the assumption that the organization is working with a Third party partner.

When they make updates, changes or have regular releases. The main expectation is that the partner did all the testing they needed to do to ensure the product is viable. Depending on the use and integration there could be a few parameter or configuration changes that need to happen and will need to be tested.

In the end it becomes very “Black box” testing, similar to a User Acceptance Test (which is basically what package testing is in the end) where it is being looked at prior to giving it to clients to use with any additional changes to other software or just pushing through basic upgrades.

Plan, Do, Check, Act it is all the same general process for testing changes it is only in some of the details and granularity that a Test group will go through between packaged software or in-house software builds.