Testers and Test Engineers


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.

When Frameworks fail

Frameworks are like ice cream flavours. In general there is a base set, but it branches out to a lot more. Whether it is automation testing, dynamic or static testing there are different sets of guidelines for others to follow to get the job done.

With that in mind one has to understand that there isn’t a magic framework that will make everyone’s lives easy. Another thing that has to be understood is that it may not last forever. Things change and it is up to the team to recognize it and make changes.

Now I am not saying a complete revamp of whatever is being used. Now that could happen. What I am talking about is being more fluid and adaptive. Think about my first comment, the flavours of ice cream. In the beginning there were only a few frameworks out there that were suggested for organizations to use to improve quality. They others started to add to it or remove. Basically it was an early version of freeware. Everyone had a hand in making improvements.

One of the things that I have seen is when Senior management get’s wind of frameworks or something bad has happened where they want to start over again with process changes. This is a fools path to nowhere. The amount of time to start over and to be productive is more time consuming than to review what was done and make small changes.

Now there could be technology changes within the organization that may full well require a revamp of frameworks. If that is the case remember that a framework should not be built around a tool. That is a recipe for disaster. Tools should fit a process not the other way around.

Things must be kept up to date, and frameworks need to be revisited on a regular basis to ensure that expectations are still being met.

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.

The “Why” for QA

Coming up in May will be the QAI QUEST conference. I have had the great opportunity to share my knowledge and the successes (along with lessons learned) within my organization.

The conference is a great opportunity to share ideas and learn, not just from the speakers.

Over the past few years I have taken up the “Why” movement that was started by Simon Sinek. I was introduced to it while going through my MBA and I really struck a cord with me. Over the years I have have tried to emulate my messages based on The Golden Circle, then I read his book Start with Why. The book is when I started to see that the Why not only falls within messaging or leadership it is an internal component that drives what you do.

With that I read Finding your Why and I found how everything started to fall into place. I looked into my Why statement and started to think about the QA discipline. As per the book the statement is formed as a Tribal Why and it gives the emotional statement of why a group does what it does.

In the end a Why statement is “To _______ so that _______” (Chapter 2 of Finding your Why). Seems fairly simple, right? Well unfortunately it isn’t. It is a long thought process that requires fine tuning over time.

For individuals, there is some soul searching and definition of feelings of what makes you tick. For organizations it is taking what individuals in your organization feel is their Why find the themes then figure out a statement that fits. Something that tells clients and future clients that why they should buy your product or hire your services.

In my QA Corner segment on SPaM Cast on this subject we do go into some details of what if the individual and the organization statement don’t line up? This could occur. Even in the books they go into some detail of that happening as well. It is not the end of the world and people can adapt without changing their Why . Or it may not be a good fit, who knows. My suggestion would be have a discussion with your manager and talk about it.

So back to my initial thought in the beginning of the blog regarding QUEST. I will have the opportunity to do a Tribal Why for the QA discipline. The intent is to not only get a statement of Why people in QA do what they do, it is also to spread the Why movement. I am looking forward to sharing and having good discussions throughout the conference. As well as learn what others are doing, not only help the discipline as a whole, to help individuals grow.

I cannot wait to get the discussion going.

P.S. I will also have a track session on Estimation.


Minimum Viable Product: A great concept. Develop just enough of a feature that can be used by clients and provide value while the teams add more functionality incrementally. Makes sense, doesn’t it?

Unfortunately there are people that see MVP as a big shinny box with a ribbon on it and not smaller boxes over a longer period of time. I feel it has roots from old Waterfall thinking. 

“Let’s go in big bang.”

“I want everything to work as I wanted.”

I would be great to get everything all at once in the time that it is requested. Unfortunately it never really worked out all that well when Waterfall was king. There is plenty of documentation out there that shows empirically that a lot of what was asked tends to go unused when deployed in a big bang fashion.

I won’t get into all the delays and painful meetings over change requests. I am twitching now just the thought of all I went through early in my career.

I am not sure why people want to have the big shinny box when there is actually more value in the small ones. We know what our customers want now, and unfortunately minds change over time. Especially if they have to wait a while for a product. 

Think of it this way. As a former personal trainer one of the things I told clients was to eat more small meals throughout the day and not 3 big meals. The body functions better when there is a constant flow of calories then a big influx. 

Clients are the same way. Give them small amounts of value and gather feedback to improve upon. That way there they get something they want faster and will continue to use it down the road. 

Revisiting User Story Maps

Software Process and Measurement

Story Map

Information Radiators are one of the most powerful concepts championed in agile as communication vehicles.  In many organizations, the use of information radiators has waxed over the past few years as more and more tools have locked data into monitors and tablet screens.  As electronic tools have replaced paper, putting radiators where people can see information, as they work or walk by, has been replaced by instant access (which is code for never looked at).  Product and sprint backlogs locked away into tools have the same problem as burndown charts, cycle time scatterplots or work in process aging charts that are in a tool and never looked at. Instead of locking backlogs away, create and use agile story maps to increase transparency and improve access to information. The goal of a Story Map is to present the big picture of a product or feature for everyone on the…

View original post 384 more words