A couple of things:
ANYWAY, I will be there and I am doing a thing on Saturday! As well as a session, that Richard Bradshaw kindly invited me to do I really want to do something podcasty, either a recording session, or a lean coffee style thing for podcasting/youtubing/blogging? I’ll build the idea more over the months, but get in touch if you want in!
Do you want to talk to me? Do you want to be on the ‘cast but only have a short message, or are in another part of the world? I now have a skype! I also have voice messaging switched on so you can leave me a message even if I’m not online, and I can put that into an episode. The username is letstalkabouttests, because brand synergy is important, so yeah. Let’s actually talk about tests!
I’ve been doubting myself a lot recently – both professionally and personally. Nothing like being told someone thinks you’re good enough to do a thing to make you insist you’re the opposite.
So let’s talk about doubt. Doubt can have many forms and many causes:
• Imposter syndrome
• Being a newbie/feeling like your skills aren’t extensive
• Not having contextual knowledge
Doubt is risky, no matter what the cause. Causes can be split into two broad categories:
‘Reasonable’ doubt in that you know you don’t have the resources you need to do your work to your best ability, be that time, tools, knowledge, etc.
This doubt is sortable – the testing community is huge and chock full of information, blog posts, podcasts, slack channels, meetups, conferences, everything. You may not know where to start, but chances are you’ll either find a post somewhere that does it, or find someone who’s willing to point you in the right direction.
The doubt can also apply situationally. If you inherit a site with a complex piece of functionality, you need to feel, as a team, that you understand it all. Sometimes that means you start testing without any test data or plan, just to see what you find.
This is where you need to manage your testing in a session, with a set time. You may not have a goal other than ‘find out more’ which is nebulous but also pretty easy to hit as goals go. You can even structure the session up to help mind map it out (incidentally, mindmaps, I cannot use them, I just find them really hard to do, compared to writing a list? I am clearly a weirdo, but if anyone can point me in the direction of other note taking/brainstorming style formations, that would be useful).
But sometimes you still can’t find all the information you need – you feel like you don’t know enough, which for me usually means I don’t know why this functionality was built, who uses it, and why. You may be able to get this from documentation, or the client/stakeholders. I guess if all this fails you could pick up bits and pieces from what the stakeholder report as issues or request as new features, and build up a picture of what they need from there.
Another kind of doubt is doubt in you, and of your work. People who are knew to exploratory testing, or who want test cases and test plans may not feel that you can ‘prove’ your testing when using exploratory, or session based testing. That requires education, and maybe presenting your testing notes to people, so you can show your testing (all of ours are saved on the session, which is associated with the ticket).
This type of doubt is sortable though, even if it is hard. Next week I want to talk about unreasonable doubt.