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

Writing a book is hard and other things

As some of you know I have been wanting to write a book on QA, leadership and knowledge sharing. The intent of the book is to give my advice and knowledge to, not only those in the QA discipline, also those outside to understand what they have.

I have been planning this since my MBA, a few years ago, and I have been slacking a bit on it. Part of it is general life got in the way the other part was being a deer in headlights looking at the amount of work needed to get done. The initial intent was to write as many blog posts as  I can and then expand on them to get the book going. I do have a lot of material so far I just haven’t filtered through it all.

The other issue I have is what will go into the book. There are so many good books out there on QA and testing that I wanted to differentiate mine from the others. In trying to get there it is a lot harder than I thought. Don’t get me wrong I have a good plan in my head and I have a rough outline of the chapters I want to write. It is combining those thoughts into something tangible that I am running into problems.

My solution: go Scrum.  I need to break things down and focus on one thing at a time. If not it will take me another few years to get something done. I’m going to build on my outline and export everything  I have written so far and go from there.  

If you have any ideas of what I should write about, feel freen to let me know.

Now it looks like QACorner.blog is having another good year. Last year I had way more visitors and views than previous years the blog has been around I was happy. Now it looks like it is projected to be another record year. As something that I was using to just gather my thoughts, I couldn’t have imagined how well it would be received.

One suggestion that was given to me was to get guest bloggers to post here. I am currently talking to a few people to do some posts in the next year. If you are interested let me know.

I have been reading a lot of books lately, so you will see those references as time passes. Should be fun.

That is it for now. Have a good day.

Hard Deadlines

“It must be done by this date, no exceptions”

Who has heard that before? Ok you can put your hands down.

In over my 25 years in technology I should have put a dollar away for every time I heard it. I would be nowhere near retirement but I could buy myself something nice.

I finished reading Jeff Sutherland’s book “Scrum: The art of doing twice the work in Half the time”. The stories he has in there are amazing. Sometimes people will make a decision without all the information and get caught. Publicly announcing deadlines will definitely paint you into a corner.

It happens though and it should never be seen as a bad thing. Sometimes there are things at play that it has to be done by a specific time. Technology in Healthcare is a great example. There are compliance and codes that need to be in a system by a specific date. So here it isn’t someone in a company painting product, development and QA teams into a corner it is an outside entity and they don’t care about constraints, it has to be done.

So for the two scenarios I listed above I will talk about the second one first, it’s easy. It has to be done. Here the team should have enough time and planning done so that they are prepared to get to the finish line without issue. Unless you are new to the market something like this is very predictable and knowing the team’s velocity and the amount of work needed from past updates it should be a cake walk.

With that said, “s*** happens” and a wrench could be thrown in just to keep things exciting. If and when it does happen, my best advice is to remain calm, assess and plan. We are in an age of Agility so everyone getting together to meet the challenge will make them successful.

Now the big issue, self imposed (company) deadlines. For the most part with proper planning, estimating and understanding of team’s velocity a deadline can be identified without much issue. It is when one or more of those things are not done is when dates are at risk. Regardless of the SDLC methodology Testing  will feel the brunt of the stress to get it done. The trick is what can be done about it.

Work overtime? Yep, that can be done and it will burn out your resources. As well as not guarantee the work will be effectively done since they will be close to, if not already burnt out.

Throw more resources at it? Have you read The Mythical Man Month? Putting more resources on a project does not mean it will be done faster. The best example is a pregnancy. Adding more pregnant women will not produce a child faster.  That is not to say it will work, adding resources to the testing effort not the pregnancy, it is actually going to add up to more work involved in coordination and ensuring there is no duplication of effort.

Re plan and scope change? This could work. Having a clear understanding what is needed and in an iterative environment look at all the work that is left and clearly define what needs to be done to meet expectations and what is a nice to have (or next release). This is one of the basic advantages of Agile and use of Scrum. It can be used in other methodologies, it is going to be a little more painful in going through all the work that has been done and not done as well as any interdependence between half done code.

Risk based testing? Yay I finally said it. I know you were all waiting for it. Yes, Risk Based testing has been around for a while and it is a very simple concept. Identify what areas have a high probability and high impact of failure or calls to support if it were to fail, then test that. From there you start to limit the amount of testing that is needed to be done.

There are a couple of other things that it will give you.

1 – A ranked set of test cases based on importance.

An example would be test cases involving financial transactions should take higher priority to how a GUI button looks like.

2 – It gives the stakeholders transparency of what is going to be worked on for validation and what will not.

Here collaboration is key. Everyone needs to know what is going to be done so they can be prepared for potential customer calls on stuff that was not tested.

Then comes the worst case scenario: telling senior management it just cannot be done. I have had those conversations. They seem scary at first, yet in the end all you are doing is stating the facts that with all that has gone on and with the time that is left it is physically impossible to make it. To me as long as you provide the right data with the message it should be understood that the efforts are there, it just cannot be done.

Yeah the leadership will be upset, same with any other stakeholder. In the end it will pass. New dates will be given, because the team worked collaboratively and figured out the most efficient way to get the work done and are more confident in any new dates they provide.

The best thing that can be done in these situations is have things in place to track and measure. I’m not saying a Gantt chart, as stated in the above mentioned book, they don’t work. Tracking velocity, amount of work left, burn down, stuff like that can give you a good idea of where you are going to end up. With this information you should be able to see potential train wrecks well in advance and the team can work together to avoid it. If the wreck is going to happen, no matter what is done, don’t hide the issue. Better to let people know as soon as you know so they can be prepared and work on making informed decisions.