Surprise: Part 2

As some of you know I like to compete in Jiu Jitsu. I love the art, the community and how it is just as much a mental game (sometimes more) than it is physical.

A few weeks ago I competed at the World Masters Championships for the third time in four years. The tournament itself is exciting and the competition is fierce. Each time I went I spent close to 8 solid months getting myself prepared.

The first year I went was more about just being there, than competing. It was my first big international tournament of this magnitude. I went in with the best intentions of winning and that did not happen. When it was all said and done I was not upset. It did suck that I lost when I spent so much time, effort and money to get there. What didn’t suck was meeting a lot of cool people and legends of the sport. It still puts a smile on my face thinking back on meeting Wellington “Megaton” Dias.

The second year was all about my health and weight. To the point I focused a little too much on it and it impacted my game plan in the end. Now fighting the overall number 1 guy in my first match did not help. This time I took that I can achieve anything I want as long as I am determined.  I was upset that I lost, that year I sacrificed a lot to get to where I was and I felt that I let a lot of people down, including myself. In the end I did dust myself off shortly after I came back and started planning for my next trip back.

The third time around I had everything set. Health and preparation was all there. I had my game plan lined up and I worked my butt off to get myself through most situations. I drilled hard leading up to my fight day and felt confident. The plan was set. Then it was fight day. Nerves did set in, my poor fitness watch was going a little bonkers with my heart rate as I waited for my turn to step on the mat.

I got through to the second round and I was still nervous. That didn’t affect how I was going to execute my plan. I get called on the mat and I start. In my head I had the plan working, things were falling into place and I decided to go with my big throw. At that time the biggest surprise happened. Just as I was executing the throw my opponent happened to take a step in the right direction causing me to fall hard onto my back. It was so fast and hard it took me a few seconds to realize what happened. I was in shock at the turn of events. Unfortunately the position I was in gave my opponent the perfect opportunity to finish the fight, and he did.

As we got up and the referee raised his hand I was still trying to figure out what happened. My opponent was cool afterwards as he was concerned about me being injured as I did fall pretty hard. Again I love the community. As I walked off the mat and behind the stands emotions took over. I was upset that all this prep was for nothing. I got caught by surprise through a chance situation that had a low probability of happening. It took me a few days just to watch the video of my fight. Mind you eating a lot of food did help.

Last week I was relaxing and thinking back on the year and I remember my previous post Surprise and I started to tie what I said there to what happened at the tournaments. The two scenarios are no different from each other. The best laid plans can get thrown out the window when that one unexpected thing comes into play and causes havoc. Looking back now I no longer get upset, I now look at ways to mitigate that situation so that if I get caught again there I can get out. No different than when something happens in a project that was unexpected, you deal with it at the time and plan to mitigate it before it even happens.


Testing packages

The question came up recently; what is the difference between testing a package to in house software? The very quick answer is none. Now before things get heated there is a longer explanation behind the quick response.

What is the general principle for testing? Making sure the change coming in works as it should and to mitigate risks of failure seeing how applications react in exception situations. Whether the change is in an application itself or there are peripheral systems that have changed or be impacted by others. Things still need to be understood, planned, executed against and validated.

Where the difference lies is the Service Level Agreement or contract the organization has with the vendor of choice. Most organizations will have sections in contracts that state the level of quality and test expectations they have with the vendor of choice. Normally they are very high standards. After the delivery of the change there is some form of testing that goes on afterwards.

Look at OS changes and updates. For the most part they are pushed to systems without a second thought. Personal computers get them all the time. Does that mean that Jane Smith will specifically go out and test all the changes that come in to her computer? Not explicitly. For organizations who use a third party software that is embedded in their product that is where things get a little less implicit.

Embedded software is becoming the thing to do as it is easier to partner with someone that already has functionality built and get it integrated than to build in house and potentially lose out on clients to the competition.   Normally this is a very detailed process when an organization that makes that type of decision, for the sake of the blog I am making the assumption that the organization is working with a Third party partner.

When they make updates, changes or have regular releases. The main expectation is that the partner did all the testing they needed to do to ensure the product is viable. Depending on the use and integration there could be a few parameter or configuration changes that need to happen and will need to be tested.

In the end it becomes very “Black box” testing, similar to a User Acceptance Test (which is basically what package testing is in the end) where it is being looked at prior to giving it to clients to use with any additional changes to other software or just pushing through basic upgrades.

Plan, Do, Check, Act it is all the same general process for testing changes it is only in some of the details and granularity that a Test group will go through between packaged software or in-house software builds.