Yesterday we talked about why we got into testing.
Todayโs a little different.
Whatโs ๐ผ๐ป๐ฒ ๐๐ต๐ถ๐ป๐ด about testing that nobody prepared you for?
Not the stuff in books or courses. The thing you had to figure out completely on your own.
๐๐ผ๐ฟ ๐บ๐ฒ? Nobody told me how much of this job is ๐ฐ๐ผ๐บ๐บ๐๐ป๐ถ๐ฐ๐ฎ๐๐ถ๐ผ๐ป. I spent years thinking I needed to be more technical. Turns out I needed to get better at explaining what I found to people who didnโt want to hear it and also talk more about what Iโm doing to make it more transparent why the product quality is so good.
What was ๐๐ผ๐๐ฟ๐?
Drop it in the comments or write your own post with 28daysoftesting on LinkedIn
While I did present stuff at conferences in academia as well as software development and testing, I was completely unprepared how nerve-wrecking massive the stage-fright was, when I gave my first (and so far only) keynote at a big conference.
Fun fact: I was wearing a fitness tracker while giving the key note and the burnt calories it recorded were well in the range of an intensive endurance training.
Similar to you, I was initially surprised by how many challenges had nothing to do with testing or development. So often things are miscommunicated, or misunderstood, which makes it harder for people to do good work.
Whether that be the intent of a feature, its implementation details, or even why a bug matters. It all comes back to working with people and understanding how to speak each others language.
For me specifically, itโs advocacy that was something I got hit on the head with over and over again.
Just because a bug is bad or a test is a good idea, doesnโt mean itโs self-evident!
I still sometimes have to take a step back and recognize that I need to talk through the why of what I think instead of just stating โthis bug is badโ or โwe need to add a test here.โ
I think for me the variety of things you are expected to know, and this may be more of a consultancy testing experience, but the number of different tools and languages you need to pick up in short spaces of time just to stand still and get on with some testing.
There is often as has been mentioned a need for clear communication to support this but that can be lacking and so I have often found myself spending time documenting a lot of onboarding information, engaging with operations teams to make sure their views are included, pushing for collaboration within the development teams and generally being the glue that holds the project together with more direction and clarity than there might have been before I got involved.