“I know it’s late but please help me out guys!” – this is how it all starts:
Today I’ve attended for the first time an Europe WeekendTesting session. For EWT #17 we had to test a software compressor plugin that our “manager” asked us to throw an eye at for 1 hour and see if he and his band can use it in tonight’s concert.
If you’re wondering why did he waited for the last minute? Beats me, he only told us that his hardware compressor was broken and that he was in an urgent need of such a tool for his concert and this software compressor appeared to be a good choice given the circumstances.
To get things started:
I’ve installed the software given to us by our manager, loaded an *.wav file and pressed the play button. Right after the song started playing I realized that I have no clue on how this software works and what does it suppose to do.
So I begin to search the Internet about the rocket and minihost software in order to learn more about them and noted down their websites. Then I wanted to learn more on software compressors and ended up on Wikipedia where I’ve found something about audio compressors, what they are and how they work. All this had taken me 15-20 min.
After seeing how little time I had left I realized that even with the all the documentation in front of me I will not be able to understand exactly how does a software compressor works and also make a good assessment on how well does the rocket plugin performs in regards to my findings.
So I’ve went and re-read the mission statement and after that decided to focus more on testing the stability and the usability of the plugin itself making the assumption (and here is one of my mistakes – making assumptions without questioning them) that the quality of the rocket plugin was already tested by the manager is his initial research.
My Findings:
No crashes, just some usability issues related to keyboard navigation and how easy it was to use the application.
My conclusions:
I can say that the mission was quite an interesting one given the “traps” (that the software we’re testing is a plugin – 1st one – and that there is the possibility that our manager will use it in another environment – 2nd one) that existed and in which I’ve felt in without even noticing till the end of the session when I realized that instead of looking more at how stable and usable is the software compressor we’re talking about, I was looking and trying to figure out how well does it performs. Instead of putting my experience with software in a good use I’ve wasted a lot of time trying to understand what a software compressor is and how does it works.
My opinion (after going thru the mission statement again) is that it would have brought a lot more value to the manager if we all concentrated on testing how stable and usable is the actual plugin and less on what exactly does it do and how well does it performs. The last two I think that were already covered by the manager when he did the initial research for a replacement for his hardware compressor.
My learnings:
- Re-read your mission statement at least 3 times before starting to work on it.
- Always take in consideration the differences that may appear due to changes to the working environments.
- If you’re making any assumptions make sure that the persons who need to know about them are well informed.
- Ask the person exactly what their needs are.
I see a flaw in the first point of your learnings. The problem is that we rarely get clear mission statements. So, we have to formulate them on our own and check back with our stakeholders whether they were correct or not. This has to be done regularly, and over time as projects unfold, these initial missions may also change due to problems being differently perceived, or initial problems being dealt with.
Maybe something to continue thinking about
Happy Testing.
Hi Markus,
Thanks for your comment and for following up on my learning’s. Really appreciated!
Yes, indeed you are perfectly right about the missions and that we must always check back with our stakeholders to see if we got it right or if something has changed in the mean time.
I really hope that we will have the chance to work together again. Thanks one more time for taking the time to comment on this.
Hi,
I reallly like the thinking that the manager must have looked at the functionality before assigning it to the team. But has he? Looking at the wording he might just heard the name mentioned by someone saying “”That’s a cool compressor, you should use it.”
So the idea is good, if that is then followed up with a quick question about if he actually tested the functionality you’d know that a very large part of the test effort might then be out of scope.
Very good summary, I like the thinking behind it and that you wrote it down.
Hope to see you again soon,
Thomas
Thanks for your comment Thomas, it was a really good assignment with lots of learnings (congrats).
Hope to see you soon, too.