Skip to main content

Software Testing and Sporting Achievement: What unites them ?

One of the most obvious spheres of human life, where you should be consistent to reach good results is sport. Ordinary people see only awards and usually don’t notice the chain of activities that have been taken to get those awards. Moreover, usually we don’t think about the people that ensure the results. The same as while talking about software product development we don’t often mention the QAs as people that ensure the quality of the software product. What stages unite the worlds of sporting achievement and software development and what is the role of QA in it?

1. Exploring

Actually, there should be “Step 0” – You have an idea of what you want to do and what do you want to get. But we take it by default and going to explore the subject. It is impossible to do your best in something that you didn’t learn up to the smallest details. In sport we should find out what result literally we should aim, what resources we’ll need for it, who is the best in it right now and who could aim to become in parallel, what kind of hidden problems we can find. Isn’t it the same that we should explore before starting to work on software product? To ensure the quality of the product we should know it in details. And while exploring those details we should take a critical look at everything new we discover to prepare the most credible background for planning.

2. Planning and choosing methodology

Which of development methodologies could choose an athlete? Probably, it won’t be Waterfall, because while getting through all long-termed stages one will lose the skills earned at the beginning and the ability to become better using the new skills earned on each new stage. One could choose RUP in case of excessive time. But the most obvious and effective is Agile methodologies. Scrum would let to work on short time sprints, to be sensitive to current situation: achievements and fails and to use new earned skills in the most effective way. Kanban would be the best when it is necessary to control the logical chain of the achievement and for moving forward you need to know what has been already done and how it has been done. It’s quite clear and logical in both cases: Software development and sport.
Planning the whole process and choosing the methodology are indivisible. And it’s also needed to consider the risks. The plan should be properly tested to find all bottlenecks at the very beginning.

3. Interaction of the team

Either on sports pedestal or on the Software product presentation we don’t see the team. We don’t know the role of each in the team, don’t mean the personalities, the skills they had and earned to provide the best result. But we should take it into account when we form the team to make the interaction synergistic, to win the first prize.
The interaction between the developers and the QAs became the talk of the town. And it is very important to understand that both have the same goal – to make a quality product.

4. Reality vs. plans

In progress, the reality almost always differs from what we planned. Especially when we didn’t test the plan properly. When people are too optimistic in defining the terms, when don’t take the risks into count – they get the biggest risk to fall down at the finish line. Like the injury can break the career of an athlete, unexpected problems can break the release terms for software project or to imprint upon the quality of the product. Well-known situation: testers find new issues when it is supposed that it’s done. When those issues are critical – it’s a real “injury” for the product. The best to do in such situation is to be agile to the reality. Don’t look for blame, look for a way to cope with the problem.

5. The criteria for success

  1. The result is not worst then we aimed.
  2. Time and budget are not exceeded.
  3. The team that worked on the current result would be happy to stay together for new achievements.
And it doesn’t matter what we are talking about: software or sports.


Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …