I started on a new project a few weeks ago and thought it would be a good idea to share a checklist for what new testers on a project need and some good starting questions when you, as a tester, are new on a project
Yesterday I had an interview with the Test Manager for a potential project and the subject of providing valuable information, as testers, came up.
We had a bit of back and forth regarding what exactly is valuable information – I asked him what the term “valuable information” meant to him. He then proceeded to tell me it’s information that helps stakeholders make informed decisions.
A few months ago I started a testing meet-up in Stockholm. There have only been two meet-ups so far – but I thought it\’d be a good idea to share my experiences because:
- I hope to inspire others to start a testing meet-up in their local area (especially if there isn’t an active one yet)
- If you have been to a testing meet-up, you may be curious as to what it’s like “behind the scenes”
A few things to keep in mind when you read this: Continue reading “Starting a Testing Meet-up – the first few steps”
I recently completed the BBST Bug Advocacy course and am currently waiting to hear whether I passed or failed. I was somewhat freaked out when I got sick (a damn cold) during the exam period and found myself having to reread the questions multiple times before I could figure out what I was supposed to do (thanks to my headache at the time). To add to that, none of the questions I practiced for were in the exam (I reviewed for about a third of them) so the first word that went through my mind when I went through the exam was S***. I ended up splitting up my answers into multiple sections so that I could actually understand what I needed to do (this turned out to be something the reviewers really liked funnily enough). Enough of my wee rant, below are my biggest takeaways from the course.
1. Irreproducible bugs should still be raised
Yesterday morning I took part in Mentor Sverige’s Job Mentoring Programme at Ribbyskolan.
First off, it was a lot scarier than I was anticipating. I initially thought we would stay together as a group and then go around together in each classroom telling the students about what we do (looking back, I don’t know why I thought this as there definitely wouldn’t have been enough time for that). But we were all split up to go into different classrooms for 20min at a time to give our presentations. I gave four 10-12min presentations to students in Grade 9, with about 5min of Q&A and then a few min to get between classrooms.
The Cultural Aspect
Up until yesterday, I had never spoken to anyone in Sweden under 25 (aside from my colleague’s daughter). I also really enjoyed going to a Swedish Grundskola (like a junior high school for 12-15 year olds) as I wouldn’t have been able to get that experience otherwise. Continue reading “Talking to Students about Testing at a Job Mentoring Programme: Mentor Sverige”
Last week I went to a testing meet-up where one of the presenters said that he used documentation to defend himself – which really caught my attention. But it also got me thinking.
While Test Documentation may be used to defend yourself, surely that is not its purpose.
Why do you write Test Documentation?
Chances are, something along the lines of, “to communicate information” comes to mind.
But what does “communication” really mean?
I think phrases like “strong communication skills” etc are thrown around and misused. According to Meriam-Webster, the definition of communication is:
“It is the art or process of using words, sounds, signs or behaviours to express or exchange information….”
Scrolling down the page I saw a further definition: “Information transmitted or conveyed”
I proceeded to click on the hyperlink that gave me the definition of convey “to make (something) to known to someone”
We use Test Documentation to make information of the software known to someone.
BUT providing test documentation and making information known to someone are NOT the same thing.
Which leads me to….
Who is your audience?
When I think I about Test Documentation the most important thing is who will be reading this. My approach towards Test Documentation relies heavily on who will be reading the information.
This usually boils down to three categories:
My future self
This is the easiest audience for me to write test documentation for, because chances are, I don’t need to worry about misinterpretation. I write test documentation for my future self when I am testing a feature which may take more than a day – I need this information so that I can look back at it and see what I have already done and how things went.
Technical people such as developers
This either happens when I’m testing a feature or retesting a bug. To this audience, I make an effort to provide detailed information on the links clicked, usernames, database tables and information you can find with the console open.
Business users such as Project or Product Managers
Providing test documentation for this audience is based on the assumption that they are in charge of deciding whether something is ready to go-live and when that is. Here, I make an effort to say what users of the software can and cannot do at its current state.
Above I state what my focus is for each audience. That’s not to say I wont provide technical information to the Business Users or that I wont tell Technical People what the users currently can and cannot do.
One final note: What you write and what is read may not be the same thing
You may provide results of test cases or a mind-map which shows the current state of the software and in your opinion, it shows things are looking pretty bad. But the reader may think otherwise.
Strictly speaking, this might not be a matter of opinion but a reflection of how well a job you are doing as a tester.
When you write test documentation you should ask yourself, “how can I ensure that the reader understands what I am communicating”.
Software Testing is not for Attention Seekers.
What a bold statement!
Let me explain.
As a broad generalisation, I feel that testing is only noticed when someone (the tester) has messed up. A few months ago I had a pretty open conversation with a workmate on how they felt unappreciated and undervalued. After all, when code goes into production and all goes well – usually one doesn’t applaud the tester for finding all of the bugs and helping improve the software quality by communicating information about it (before going live).
I really could relate to my workmate as I recall many times where my input into a project seemed to be forgotten or ignored. Some code would go live, which I tested vigorously, and then only the developer would be mentioned. This happened in both team-wide forums and tools you could use to give “kudos” to someone.
It’s a bit weird being in a profession where the metric on which you base my success is probably going to be you not realising the role of a tester exists.
Let’s say you’re buying airline tickets online. You first select your Departure City by entering three or more characters, then selecting your city based from the dropdown list that subsequently appears. Afterwards you go to the Arrival City field and do the same thing.
There are two (of many) ways this could possibly pan out.
- The Arrival city field dropdown is only populated with cities to which you can fly from the Departure City. You then continue to select dates and make a purchase. (You probably don’t even think in one step of the process of a tester\’s role in this).
- The Arrival City field dropdown list is populated with every city (including ones you cannot fly to from your Departure City), you select one of the ‘unsupported’ cities and get an error on the next page. Something only these lines crossed your mind: “Who tested this? Why didn’t they think of this?”