Helping others in the discipline

This week I had the opportunity to talk with someone within the QA discipline and provide some career advice. We talked from helpful hints on how to get a foot in the door with the resume to a good discussion of QA as a whole.

This was the first instance where someone took up on my offer to have these types of discussions. It was a great conversation and fun to have this type of discussion with someone outside of someone who directly reports to me.

This individual had some great questions from what changes could be done with the resume, how to approach an interview and what could be done to improve knowledge within the industry. The conversation went well over an hour, and that time flew by.

I think these types of conversations are needed to help the community stick together and improve the value that everyone can bring. As I say in every one of my appearances in SPaM Cast “feel free to reach out to me to further the discussion or start a new one”.

Keeping it short this week. If there are any topics you would like to hear, read or discuss about let me know.

Being self reliant without depending on 3rd parties

Keeping with the recent theme about freedoms I want do discuss testing with 3rd parties,  we can even add different departments within an organization as well. In the past 20 years more and more applications and back end systems have required to be more integrated than ever. Most of this is due to basic business logic of identifying value and whether it is better to buy (or subscribe to service) or to build.

Prior to Y2K (I just twitched as I wrote that) most organizations built what they needed to succeed. Now time to market was fairly long and Agile was not as widespread as it is today so it made sense to build. Also different departments were rarely integrated. Then the internet came into play and things changed. People were getting access to stuff they never thought possible and wanted more. Exponentially the demand for information grew. Along with that the demand to do transactions online as well instead of going to a store. It snowballed to something quite amazing because it forced organizations to adjust to meet those demands and also become innovated to catch a bigger piece of the market and improve client satisfaction.

So here is where things started to get tricky, to build what was needed would take a lot of work and speed to market is everything. What started to happen was companies started to form to only focus on key components to sell to larger organizations. What this did was  make the “Buy vs Build” decision making a key process to help improve value. Why spend time building something when somebody else already did and we can get it at a fraction of the costs? Also we don’t have to support it. Sometimes it makes sense to do that.

This also happens within an organization as well. The best example I can come up with is the banking industry and the use of the internet. Online banking has become such a big part of most peoples lives they take it for granted the amount of work that went into a site that shows your account balance and do almost all transactions you can do at an actual branch and you can do it sitting at the dinning room table with a nice cup of coffee in hand. There are so many departments and divisions that need to work together it is amazing.

Wow that took a little longer than what I wanted, none the less if you were not part of the growing pains myself and a lot of the experienced (that sounds better than old) individuals were we can now move on to the topic at hand.

I have worked and seen other groups focus so much effort on working with other groups or organizations that they become obsessed with testing with them to get work done. Now I do agree that there is a need to ensure that integration between systems are tested it is a must. The question that really needs to be asked is; do we really need to wait for someone to exercise our code? My answer is no, and I am sure that most of you that do any sort of SOA or transaction testing would agree.

For me as long as the Format, Content, and Layout have been defined (doesn’t have to be fully defined at first it can be done in Agile or Iterative fashion) teams can test their code before integration starts. Why not? Does the code know where the information is coming from? No, it is not like asking someone to hand you something from the other end of a table. Code expects to see something in a specific location and in something that it is coded to understand and process. Here is an example:

System flow A

Here is a very high level view of sending information between systems. Now I know most people I talk with understand the simulation of data and sending transactions through, yet this concept is still foreign to others even with a lot of literature out there about it. In the end it is a very simple process to exercise all the code you can without the wait.

System flow B

Now teams are in more control of the data that comes and goes. It is hard to do and not very fun to get started. Once you do the quality of what comes out should improve. Development can start doing some quick integration tests to make sure nothing goes awry. If you look at it from a certification perspective where sometimes you have to pull use specific data to run through the system, now you can.

Taking control of what you do as a team to get code out is important, relying on others outside of your control could cause delays or even frustration if issues arise and now it turns into a blaming session as to who’s fault it is. Stuff like that will put the progress of the product to a complete stop.

I am sure that this blog entry is what some of you and your teams are doing. My hope is that for those that don’t can use this to foster conversations here or other areas to help them get to where they need to go.

Listen to my segments and others on SPaMCast

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.