Blog

Focus

Dwayne “The Rock” Johnson has a great video on YouTube where he just says “focus”

It is odd to put this here in a blog on QA and Leadership, I know. I thought I would lighten the mood and put a smile on people’s face.

As you all know I tie my blog entries with my recordings on SPaMcast and the latest entry is on QA Focus. (Here is the recording and the page for a lot of other wonderful interviews http://spamcast.libsyn.com/spamcast-558-story-points-leave-them-qa-focus-discussions-and-essays )

As in the discussion we talked about focusing efforts with conducting testing and how far is too far.

For me that is a pretty vague question because it is open for interpretation. Overall it is generally based on the acceptable risk of the organization. Even that can get a little fuzzy.

It is all about the culture the organization has in how it treats it’s products and clients. There was a great analogy used in Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing by Elisabeth Hendrickson  . To paraphrase, testing is like a fish net, depending on how little the mesh is will determine how much you catch.

To focus to hard on an application or component to the point where the mesh is extremely small will take a lot of effort to just get through one cycle. While on the other hand you can have a big mesh and only get the big ones. Now depending on the application being testing you may have no choice to use the tight mesh. There could be potentially lives at risk if something were to sneak through.

This is where the culture comes in as well as good leadership in providing ways to move that net faster while still getting the same results. Through the use of purchasing tools to use, providing a collaborative environment where team members across all disciplines can work together to solve problems and in general be supportive.

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.

Making bad decisions

It happens, you go into a situation and needed to make a call on something. You only have a couple of avenues to go and you decide. Then it happens, the decision you made is the wrong one and things didn’t work out well. It happens, everybody has done it in one form or another. What happens next is key.

In my last blog I talked about accountability now I want to talk about accepting that accountability and owning it.

When things go well at work some people will gladly raise their hand and say “That was all on me”.  Personally I think that is a bit selfish, most work done now involves multiple individuals, indirectly or directly, to get it done. It should always be team first, in my opinion. What I find interesting is when things go wrong for the individuals who pat themselves on the back and how they react. In my experience those individuals will lay blame on others, even when it was them that made the decision.

“It didn’t work because the others didn’t understand what I wanted done.”

“<insert name here> messed up.”

“There was nothing I could do”

It is so easy to blame others and make them look bad. I get it, I used to do the same thing early in my career.  What changed for me is a comment I got from one of my leadership mentors: “own it”. At first I thought of it as something that would help me become a good leader, and it did. Over time though I find it has a much broader scope. I started telling all my directs and teams to “own it” as well. I didn’t care if they made a bad decision what I cared was that they saw the mistake, took control of it and learned from it. We are not machines with a decision matrix, we are human that have way too many variables that are involved with most decisions at work that we make our best guess most of the time.

Sometimes the decisions are made and there are outside forces that make it go south. I would still take ownership of what I did, state what I didn’t foresee and ensure that I would keep what happened in mind the next time I was in the same situation.

Being accountable for the decision should be less stressful then playing the blame game.

Now I know that after you read that either your eyes rolled or at “pffft” sound was made. Hear me out on this and you will see what I mean.

Say “oh s***” only once (maybe twice)

Going back to my main stress relief, Jiu Jitsu there is something I always bring up when I teach a technique. I call it the “oh S***” moment. It is the point when your has made a mistake and you begin to capitalize. Some of my students when they compete, same with me, will have that moment where we say it to ourselves and get beat. What myself, our main instructor and the other instructors instill is learn from what happened and not dwell on the loss. On the mat there are so many variables that are in play, the opponent, the referee, the noise in the gym, the wait to get the match going etc… In the end though it is you stepping on the mat and your decisions on how to approach the match that matter.

Same in the work environment it is up to you. Now there are group decisions or consensus done to make choices, yet although it is a group setting each individual should still take the accountability for what was done. What is important that if things go bad everyone has learned from it and will have a different thinking process next time.

Taking the higher ground and have a plan

With ownership also comes taking the higher ground, and having a plan to get past the situation. Even if you have a boss (see how I said boss and not leader? I will get into that later) that is angry with what was done and doesn’t really help the situation, you can hold your head up knowing you have a way to get past the new obstacles. Always have a plan B ready, you don’t have to have one done when you make the first decision just be prepared. I have gone into situations where I had to come up with alternate plans, sometimes it takes me a few minutes or it takes a couple of days it is all matter of what is going on.

Leader

It is all about support. To me a boss will just get angry, muscle their way past the situation and play the blame game. A leader will support the decision and appreciate that you have a course of action, and if they don’t agree with it they will work with you on a path that you both can agree on.

There is a story out there about a VP that made a decision to sponsor a project that cost millions of dollars. It was a long project, it was way over budget and in the end it was trashed. The VP was called into the CEO office where he thought the worse. The CEO talked about the project then gave him a new direction to follow. The VP said thanks and mentioned that he was prepared to clean out his office. The response he got was not that surprising coming from a good leader.

CEO “did you learn from what happened?”

VP “Yes,”

CEO”Good, then why would I let you go after spending millions of dollars on your education”

You never lose, you learn. Making bad decisions happen, it is how you and your leader react that will make set the tone for success.

Why is Agile so hard to get done right?

Agile has been around for over 20 years. It has shown a lot of benefits to software development and improved quality to what clients/users want. Yet in discussions with peers and reading a lot of literature it seems like it is something that is just too difficult to grasp. Why is that? What is it about this way of getting work done is so hard for organizations to understand?

Looking at Jeff Sutherland‘s book: Scrum – The Art of doing Twice the Work in Half the Time it is fairly straightforward. Especially as one of the authors of The Agile Manifesto you would think it would be simple. Let’s revisit the values for a second (from the wikipage):

  • Individuals and Interactions over processes and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan

Seems pretty easy, right? Wrong.

Some people I have talked to about this take the values as stated laws and not guidelines. I will be honest here, when I first started to understand Agile I did not like it. It seemed too much cowboyish than structured. It didn’t feel right. Then I started to look into it more and more. My feelings towards it started to change and at the same time that was happening I noticed that I actually was following the methodology in the late 90’s without noticing it.

For me it all started on a program I was leading the testing effort. It was a pure waterfall project and it was not going well. Based on the project schedule it was three weeks behind before it even got to the testing phase. So the pressure was on. There were a lot of factors at play and the deadline was not changing. So I decided that it was time to do something different. I started daily scrums following the same principles as in Jeff’s book. Asking the three main questions:

1 – What did you accomplish yesterday?

2 – What are you doing today?

3 – What is blocking you from getting it done?

From there I went on to get things done, and we did. We met the deadline without 1 hour of overtime needed. It was great, everyone felt that they accomplished something. I was able to apply Agile principles in a Waterfall project.  Pretty impressive and I am kicking myself for not looking into it more back then to understand what I actually did. Well the reason I didn’t do that was because I didn’t know. To me it just seemed like the right thing to do.

Looking at the Manifesto I will go through what I did all those years ago:

  • Individuals and Interactions over processes and tools
    • We interacted daily
    • Worked as team to meet the goal
    • Helped each other
    • We still followed process
    • We still used tools
      • The last two we were more focused on the first three points than the last two.
      • We used found efficiencies to get the work done as we went along.
  • Working Software over comprehensive documentation
    • Get the work done
    • Ensure scope is completed
    • Ensure test results were documented
      • This was done in a bank so test results are an audit-able document. So we needed it.
      • What we did was understand what is needed for an audit and ensure we were compliant. They were focused on one set of results. So we ensured that the last run of cases were documented and ensured less duplication.
      • The other benefit we found here was saving a lot of storage space.
  • Customer Collaboration over contract negotiation
    • We worked with the Business Analyst to ensure what we were testing was what they wanted to see.
    • Shared results
    • There were really no contracts of negotiations done
  • Responding to Change over following a plan
    • As with any project in Waterfall there are change requests. The team adjusted and still met dates
    • Although there was a Test Plan documented (it was Waterfall after all) we never revisited it. We knew it would take too much time go over it and figure stuff out then get the approvals. We just planned on the spot and go from there.

So back to the purpose of this post: Why is it so hard to go Agile? If I was able to do it without any training why can’t some teams get it straight when there is so much documentation out there to help?

I see it as a couple of things: Taking things too literal and fear of loss of control.

Taking things too literal is an easy one to talk about. Basically people take a look at the Manifesto and basically treat it as gospel. This is where the cowboy comment from earlier came from. I have seen teams that treat Agile as a free for all and that they can do whatever they want. When in actuality Agile needs discipline.

Yes teams will have to act fast on stuff that may come in from Business, Clients or senior executives. It is going to happen. It is how the team reacts that is key. Not every moment is a “drop everything that you are doing and work on this”. When stuff happens it is up to the team to analyze, collaborate and ensure there is complete understanding of what impacts there are to adjust. Taking work out of a sprint so not to impact capacity, move it to the next sprint as it is not as critical as initially thought or prioritize for future releases.

Or the teams will just throw in a lot of work in the sprint without properly ensuring they are effectively pointed or they don’t really understand their velocity. What happens with that is usually the Burndown chart looks more like a city skyline then a slope with a huge drop at the end because incomplete tickets are moved to the next sprint. From there it just snowballs out of control. This then impacts everyone in the team. The sad thing is it becomes the norm and people become complacent.

It is not a matter of throwing work in and seeing what comes out. Speed is great and eventually a good running team will be able to accomplish great things on a faster schedule. It is about setting a good foundation of to get there. Getting speed for the sake of it will lead down a road that will not end well for anybody involved.

Fear

The fear of change is powerful. Normally humans don’t like to do something different. As long as they are comfortable they are good. “It has worked before, why do something new?”. Jeff said it best in his book “Change or die”. Going on a deeper level it is evolution. We all know we can’t stop that from happening in the world so why be so closed minded to evolve how work is done?

I had similar fears and I overcame them. There are some of my former coworkers that would be pretty impressed that I have become an Agilist.  How did I overcome it? Well one, as stated earlier I actually did it, and two education. Reading, courses, and talking to others have given me the insight to see the benefits and how to apply good change management to get others down the path.

This post didn’t really go into a lot of QA or testing, hopefully you can see the implicit message of how QA is involved.

 

 

Third party testing

Third party testing is something that can cause some heated debates on whether to use them or not. The effect they have on an organization and quality of the output.  Here I will put in my two cents and will carry the conversation more if anyone wants.

For me I have no issue with it. Now with that said there are some conditions I have, that I will go through (if not this will be a very short post), and I will also go through the arguments that I have heard on the subject (with my take, of course)

Here are my conditions though I have:

They are used for staff augmentation and not just cheaper labour.

Want a good way to get a bad reputation is replace full time staff (letting them go) to be replaced by a third party resource. Here is a good example of some bad press when that particular model is done.

Staff augmentation is meant to cover off the additional workload so that teams can produce more, when needed. When using a Third party vendor they have the ability to bring on resources with the skill sets needed at a faster pace than hiring processes in North America. Usually within a week or two you can have a resource in the system starting to get some work done. Compared to a usual hiring process it could take a month.

They are resource to scale. Most of the third party vendors that I have worked with can get 1 to 10 people in a short period of time. That is there business model and it is done well on most days. You may get the odd hiccup or delay, yet based on needs it is still quicker.

Most Third Party resource vendors also allow for quick turnaround. What I mean is if a resource is not working out as planned or they decide to leave that organization they can bring someone in fairly quick. Or if things start to slow down for your organization or there are budget cuts needed they can be let go first and allow for a core team of full time employees to stay unaffected to continue work. When I say unaffected I mean: not let go.

There are other advantages, as well as disadvantages to using a third party model. For that I will go into a little more detail during the arguments that I here regarding the model’s use.

Argument #1 – You are going to replace our jobs to them.

When I first heard this argument I would scoff at the idea. That was until stories, like the one above, happened a few years ago. I always thought it was about augmenting the staff to meet the needs of the workload. I still believe that and still lead by it. There is still a part of me that is cautious and willing to defend when needed.

What I believe is that when using a third party it is actually going to bring in more work and that work will be more fulfilling as the easy, menial tasks can be handed off to the additional resources. It makes total sense and it is generally how the model works. I will get into why with the second argument point.

Argument #2 – They don’t know the system.

Yep, you’re right. Here is the catch: so would any new employee who walks into the door onsite. There is going to be a learning curve and the work they will be doing at first will not be difficult or intricate. An organization would not take a junior analyst who just came in to work on day one and assign them a multi point of failure set of test cases then walk away. That is a recipe for disaster. So why would we expect the same for someone that is on the other side of the world that is starting to work with you?  They are there to help and will need to have a good training system in place to provide that.

Argument #3 – The time delay is unmanageable.

If that was the case nobody in North America would follow this model. Yet there are a lot of very successful organizations that use this model very well.

There are so many communication and workflow tools out there that the time zone difference is more of an annoyance then anything. As well my experience has shown that they are willing to work around our schedules and ensure there is proper communication between the two locations.

There are other arguments out there and, to me, they are based out of the fear of the unknown. If a company is just starting to use this model and nobody has been through it before, it can be scary.  Once they open up and accept it for what it is, Staff augmentation, it can be beneficial to everyone. The opportunities of innovation can start to arise as the trivial work can go to the additional resources while the teams onsite can focus on more “fun stuff” while looking at ways to do things better.

I think the one key thing that I need to stress, I have said it throughout this post, it is all about staff augmentation. This has to be realized from top management down and it must remain consistent. Any deviation from that and it will erode trust throughout, which in turn will erode productivity and finally quality.

 

 

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.

Advertisements

New beginnings

For about a year or so I have been thinking of going into the consulting world. For years now a lot of my colleagues have asked me why I wasn’t going down that path. They felt that I had enough experience and knowledge that I can be successful and make lasting improvements to a lot of organizations.

Over the past few weeks I have had a lot to think and prepare for. With the changes in my professional life, I was at a fork in the road and made the call.

See I am very happy when I get to help people solve problems and get them to be successful with what they are doing. I have had a lot of success with previous employers getting to the root of issues and working with a team to resolve it with a long standing solution that ensures the likely hood of it happening again was minimal. Previous CTO and SVP s have called me “Mr. Fix it” for how I have come into a situation, assessed it,and come up with a solution in a short period of time. I was no longer just the “QA Guy” I was leading changes in Development, Product Management, Project Management, SDLC and IT.

So in the past little while Berriault and Associates Consulting Group was formed. It has been a busy week reading, setting things up and getting prepared for what is about to come.

Aside from the new beginning some things will remain the same. I will continue with this blog and participate with my columns on SPaMCast.

Have a good week everyone.

Eye opening

Coming up on my contribution to SPaMcast we talk about my preparation for the World Masters Jiu Jitsu tournament and go into a discussion of how it relates to professional careers.

Last week was the tournament and I did compete. Unfortunately I did not have the outcome I wanted. Like 50% of the people who register for the tournament I lost in the first round. This year though was way different that previous as although I was in a good training camp and was prepared physically, my mental game was worked out more than any other year.

A few things have happened over the past few months and it all culminated the Thursday before I left for the tournament. I was impacted by a company takeover. Not the best news you would want to have on your mind while you are about to embark on the biggest competitive event of the year.

In previous years at this tournament my heart rate for the day I competed would be over 100 beats a minute for the entire day. Amazingly enough this year my heart rate was normal, around 75-85 beats per minute and I didn’t feel anxious. I was relatively in control of my mind and was in a good state.

Then came my fight. I would be a mess on the inside as I am about to step on the mat. The reason for that was in the past I was playing the “What If” game in my head, which you usually do, unfortunately for me I was trying to be a super computer and run through every conceivable scenario I could. This year I had my initial game plan and was confident I could readjust when needed. I was in a good state.

As the referee called us on to the mat I was focused, nothing was going to change the task at hand. As the match went it was all good. I never panicked, even when in danger I was able to get through and do what I wanted. Unfortunately at the level of competition I am at if there is one small mistake made the opposition will take advantage of it, and that is what happened. I was a bit off balance and the end was near. In the last 30 seconds of the fight, where I was winning on points, I was submitted. My day at the tournament was done.

Now in previous years I would be very upset, especially with all the work that I did to get there and with the added stress from being impacted. I wasn’t, I felt good. I could have gone off on people that said they would be there to help me and didn’t show up. I could have been miserable for the next few days there and just add to my stress. I didn’t my next focus was on two other teammates there that were competing later in the tournament.

I focused my energy on helping. One teammate was extremely nervous about competing on this stage. I kept my talks with her consistent and focused on what she needs to do. On the day of her competing I kept things simple and helped her focus at the task at hand. I coached her through her bracket she is now a World Champion. It was a great feeling for me to help her get that achievement. As time went on that day things started to change in how I saw myself and how I dealt this things in the world.

My next coaching duties was Tyler. There was a teen tournament going on at the same time and I had the opportunity to coach him as well. Unfortunately he did not have the outcome we desired. He met a very tough opponent and lost his first match. As a coach it is easy to talk to athletes that win, the challenge is when they don’t.I took him aside and let him know it is not a lost that it is a learning experience. We went through the match and found areas of improvement. He was hard on himself for the loss, I get it. With my clearer view of things I told him that it is only a loss, I have been to the World Championships 5 times, spend a lot of money, sacrificed a lot each year to get there and lost each time. It didn’t matter, we step on the mat and go to battle. It is a 50-50 shot you are going to win, this time he didn’t. There would be other tournaments.

After all the competition was done it was time to enjoy the Vegas night life. Before that I had conversations with other colleagues and it opened my eyes to how much I was setting up barriers for myself, not only in Jiu Jitsu, in life in general. I started to see that the obstacles that were in my way were of my own doing.

Over this year I have been reading a lot of books and two that really stuck out for me were:

The subtle are of not giving a f*ck and You Can’t Hurt Me.

After ready these two books I feel it started to shake the foundation of my obstacles. They were still there but now they were weakened. Last week destroyed most of them, I know there are others there, just hidden, and I know I will be blowing past them as well.

It is amazing how one week can completely turn around one’s outlook.

I am blessed with all that has happened and the support I have from family and friends.

I got this.

Testers and Test Engineers

https://spamcast.libsyn.com/spamcast-550-conways-law-and-process-improvement-test-engineers-and-testers-essays-and-discussions

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.