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 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.




Trust in your team without micromanaging

Sort of a follow up from Giving team freedom (within limits)

Trust is something that should not be handed out willy nilly. It is something that is very important and in the workplace is one of the components that improves employee satisfaction. There is plenty of literature out that that will talk about how to be a great leader within a team and most of them will touch on trusting those within the team in some shape or form.

Here is one of the issues that comes with leading teams, if you are new to the team it is difficult to let the team go ahead and continue to work without getting more involved than what you should be. It only makes sense, you will need to know how things work and see where improvements can happen. Now the real trick is, when to stop hovering.

I have yet to encounter someone that likes to be micromanaged. It is not a great feeling and tends to choke off potential innovation within the organization.  People like to be given direction with the allowance of letting them decide how to get there. This leads to the next tricky part, how much freedom do you give them?

One of my mantras is “Trust is a two way street, it is earn not given”. As a leader you have to let the team go and do things while letting them know that you will be paying attention from a far. They also need to understand that decisions made come from multiple sources and that they are not made just to make a decision. Teams should also have trust in what you  as a leader is doing. How do you build that trust? Ask for feedback, and not just at the end, when the decision is made. Go to the team and let them in on what is coming down and what direction you are thinking of going. Now keep in mind I do understand there might be times where, you as a leader cannot do that, I have been in that scenario a few times. In those scenarios I find it best to let the team know what is going on as soon as you are able to do so. Give them the “Why” things happened the way they did, “How” it all came about and “What” you are doing to help the team through it. This is the basic principle of Golden Circle, this is how you will help get that trust while you are also given them trust as well.




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.

Giving team freedom (within limits)

As someone in management I make every attempt for my team work on their own. I will not micromanage, I never like it being done to me and would not want people to feel the way I did when it happened.

Also there are plenty of research out there that shows when leaders take that step back and give them control in their work it will lead to better job satisfaction.

10 factors in job satisfaction

Letting be empowered in what they do and get the work done gives staff the sense of ownership and not driven by specific orders from above.

Now with that said comes the “within limits” part of the title. Read through the link I provided you will see in the control part it discusses that leadership will give direction and not specific orders. That is something I firmly believe in. Barking out orders doesn’t work well in an industry where innovation and “outside the box” thinking helps with ensuring quality products go out to clients. What I use is a basic set of rules, without them it does not end well.

As an example there was one group that I worked for that used an automation tool to complete all the testing for one application. Now it was a good tool at the time and provided what was needed. The unfortunate thing was there were no rules around how the data, scripts and application was to be used by the team. At one point nobody would be able to run a suite of tests and get valid results to validate without doing more investigations and traces within the system to review. In doing so it complete negated the value of the tool that was to do all that for you.

There was a sub project that was created to clean up the data, scripts and provide a clearly define process on how the tool was to be updated. The project took a while, a little longer due to something I did (detailed here Owning up to mistakes) . I can tell you I never repeated a similar mistake like that again.

In the end with the rules and changes we did it proved to be a huge value. Now I know you are saying right now “where is the freedom?” Well the freedom came in the lead up to the stable environment. We created two automation data databases; one with strict control and one that was fair game. This was the perfect set up as people can do what they wanted to test and after go through the process after the project to move the data to the clean database to add to the regression suite.

In the end I understand that most people are happy when they are left to their own devices to get work done. As some of you that know me I am far from being a strict rules follower. While some rules should never be broken there are some that can be bent or should be broken to help with getting work done and also help with innovation.

Testing in difficult situations

Having been doing QA work for close to 25 years now I have come across one or two difficult situations. Whether they are delays in code deployment, resource issues, environment issues or finding one of those Surprise issues late in the game. That is just to name a few difficult situations that a QA team would have to deal with.

The one that seems to cause the most angst is the dreaded “finding a Severity 1 defect late in the game”. This one is the toughest because QA is now potentially the messenger of death for a given project. Finding this issue could delay or even shelve an entire project or program.

The best example I have encountered is two weeks prior to deploying a huge program we discovered that the speed of the system we were about to introduce to replace the existing system was much slower in processing transactions than what is currently being used. This was after almost 2 years of planning, requirements, development and testing. From a non-functional testing standpoint this was really late to be doing such tests, that will be another blog all together, and the team tried to retest as much as we could hoping that it was an issue outside of the system that could be explained.

For a week we stress tested the application with no real change in the results. The next thing to do was let the executives know what was going on. To say they were not happy would be an understatement. A lot of questions came out and the team tried their best to answer them. We had mitigation plans and rescheduled dates to accommodate the work needed to fix the issue. A day later there was an announcement that the program has been shelved indefinitely.  That was the biggest kick in the gut the team could have had. Years worth of work and the last two weeks of trying to find ways to get it to work just done with nothing to show for it for our customers.

Internally there was some benefit as we looked hard at our processes and made changes so something like this could not happen again. That is usually the best thing that can come out of difficult situations; a problem is found and resolution comes out of it for the future.

That was a difficult situation that was based through a team, what happens if it is an individual. We all have something that can happen i our personal lives that could find its way to impact work, or something happened at work that makes things hard to deal with. As a people manager I have to be conscious and considerate of what people are going through and help them as best as I can to get through what they are going through. It is a tightrope act in how to deal with issues that, if personal, people may not want to share with their direct manager. For me, I always tell my team they can approach me about anything and they have my confidence that it would only be between myself and them. If not they should go to an HR representative as they would be able to help out with whatever is needed.

As I write this and remember what was discussed in the QA corner podcast component in SPaMCAST I think I will be writing a continuation of this one to get a little deeper on what I think about this scenario. The one thing I do feel that letting someone know what is going on before it festers is the best thing that can be done. A good manager will not be angry at the messenger, they will focus on rectifying the issue.

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.

Motivating testers

Motivating people is a tough task. Doing so in an discipline that can be difficult and thankless at times it is even harder. How can you keep people’s spirits up when they could be constantly under pressure? As someone in management it is even difficult to keep myself motivated at times.

That is not to say that QA is the only discipline that is hard to stay up beat and ready to go. Look at any job, role or discipline out there, this is a problem everyone has to deal with.  There are books, seminars, websites, audio and videos all over the place on this and I will not get into all that. Here I will focus on what I have done to keep my team members motivated for QA.

I have said it before that QA is a little bit of odd duck compared to the other disciplines within SDLC. Last to get the changes , timelines don’t change and tend to give bad news. So part of the time QA is not seen in a good light. Being the messenger is not a good position to be in in this scenario. From a career perspective why would anyone want to stay and move on? I have had this question brought to me numerous times and here is my response: We have the opportunity to make things better.

Corny, I know. In the end that is the truth. Staying within the discipline, improve communication channels and it will get better. The biggest thing that needs to happen is that the support network needs to be there, first and foremost I am there for everyone under me and I have their best interests at heart. Everything can be improved it is a matter of sticking with it.

I have seen a lot of new people come to the discipline with the intentions of being a change agent. Wait 6 months and that enthusiasm will start to disappear. Then there are the people that have been in the role for a long time and are complacent to how things are and are happy to just go with the flow or looking for a way out.

Keeping that enthusiasm or even re-igniting it is a big task. The main reason is not everyone is the same and it is up to the leader to find the right triggers to get the juices flowing. The other part is there are people just happy doing what they are doing, how do you motivate them?

For the latter, for me, that is easy. “Keep’em happy”.  As long as they are in good spirits and are not experiencing undo stress that is the perfect thing to do. Just remove any roadblocks and look for ways to make their lives easier. You can still have the odd career discussion on what could be available or different paths. Something may peak interests there is just no need to push hard in getting this individual to act on anything.

Now the career minded people there are plenty of motivational factors and it is up to a lead to understand where they stand. The tricky part is getting what the real motivation. Not everyone will be up front on what they really want, part of the reason could be they may not know what it is. I fell into that boat a long time ago. I didn’t have understanding of what I wanted to do, i just wanted to do something. There was a time where I wanted to go to a new group just to move thinking everything will work out. It didn’t, I was miserable and asked to go back to my original group.

The good thing is my manager at that time dug deeper on what I wanted and started to point me in the right direction. How did he get there? He asked a lot of questions where most of them started off with “why”,; why do you want to move? Why do you think you wold be good there? The more he asked the more he found out where I was coming from. It was also opening my eyes to what I wanted. In the end it was a casual conversation that started to drop my anxiety and get comfortable with the discussion. What happened? It was I was not happy with the work that I was given. I felt that I was not challenged. I still wanted to be in the team and I did want a leadership role down the road. I just felt with the level of work I was doing was not going to get me there. We worked together and found a side project that was about to start that kept me in the group and was a stretch assignment. From there it all worked out and got me moving in my career.

In the end it is all about getting to know the employee a little more than when they come in, what they do and when they leave. It is a bit of balancing act because not everyone will open up. With all the literature out there it all comes down to experience and the manager’s attitude when helping motivate someone. With all that it still may not work. The individual may no longer want to work in QA, which is fine. It is still up to the manager to find out what and where they want to do.  Do it with the full intent of helping them get to where they want to be. It will let the employee know that you are helping them get there and will boost spirits with the current role.