The wonderful @lisihocke spoke about a topic that resonates with many of us in the testing community.
Yeah, but I’m not technical enough!
Well, after this Masterclass you should be able to do the following:
Determine your technical confidence
Annotate code with its core structure and function
Examine pull requests for risks
Execute basic command line commands
Masterclasses are Ministry of Testing’s monthly software testing webinars presented by testing specialists on highly relevant topics. All our Masterclasses are 45 minutes long, with 15 minutes set aside for Q&A, allowing attendees to master new skills rapidly.
The live Masterclass webinars are open to all, whilst the Masterclass recordings are exclusively available to Ministry of Testing Pro Members to enjoy and learn from permanently.
Here’s a question which goes in opposition to this: I am too technical.
I test deeply, use many tools, script and program, peer review, inspect, release. This has become a burden as it’s not appreciated. I had the same salary as a non tech junior person. It’s hard to find a job as I’m overqualified. I was asked by my managers to help with lots of technical things which other testers said they can’t do. How do I make it work for me instead of against me?
Maybe moving in the direction of becoming a technical lead? That would mean better pay, and your technical knowledge would be very helpful, but you won’t be doing the leg work alone.
I can only speak from my experience and context: your skills would absolutely be appreciated there! Especially if you can help other people grow them as well (that includes all kinds of folks, testers, developers, product people, and so on). The more people know, the higher the chance for quality outcomes. The more you can share the load, the more you can contribute in new ways as well and grow yourself.
Not everyone has the privilege to do so, yet if you do, you might want to have conversations about…
seniority level and related salary range changes (especially if you’re already put in a special position compared to others),
role changes (maybe a different and potentially higher paying role is intriguing to you, like SRE, InfoSec, etc.), or even
company changes (if a management position is not for you, I suggest to look for principal / staff / senior expert level roles).
Thank you @lisihocke for sharing a thought-provoking and inspirational Masterclass Webinar.
I have a feeling folks will wanna come back to this Masterclass again (and again). A recording will be available in the coming weeks and available to Ministry of Testing Pro Members. I’ll reply back here when it’s available.
Side note about Pro Membership
If your team isn’t yet set up with a Pro Membership then I recommend having a chat with your manager to ask them about your learning and development budget. There is so much incredible learning material available for such good value for money.
Thanks to everyone who asked a question.
During the Masterclass the following questions were answered:
What first glance post its would you expect from someone who doesn’t have experience with spring or java? — @deborahreid
Do we have access to the miro exercises outside of this call, to reference later on? — SMS
if the language seems alien, how about using those online code convertors? — @gunesh
Lets say you come across some technology where you struggle to understand its concepts & how it works. How do you tend to approach getting a good enough technical knowledge of it? — @rforjoe
you said the perception in the community, does it call for seeking validation from the community? — @gunesh
What are your thoughts on pairing? Has it helped you in your technical journey? — @rforjoe
I’ve looked in my app’s code but I have really hard time understanding backend code. There are libraries, lots of classes and instances of those. Many layers of abstraction.Where to start? — @ifs
And we ran out of time to answer the following.
If someone is more visual, what’s the best way to try and dig into code/code reviews/command line? — @deborahreid
What is your opinion about algorithm? If you know to write and read algorithm, can that be considered as “reading the code” and understanding it? — @layla
Do you feel being technical sometimes makes testers focus too much on technical issues rather than potentially bigger customer impacting issues with the product? eg long discussion about a function name, or how the code has been written when certain features aren’t working. Have you come across that? – @rforjoe
Along with Angie Jones, who else inspires you – in relation to the topic of technical confidence? — @simon_tomes
If someone is more visual, what’s the best way to try and dig into code/code reviews/command line? — @deborahreid
If information that’s presented more visually helps you, I suggest to make use of visualization techniques also for these topics.
For understanding a piece of code better you can use mark whatever is important for you. This could be highlighting structure, circling variables declared and drawing arrows to where they are used, marking syntactical elements you’d like to know more about, control flow mechanisms, domain language used (or not used), etc. You could do this in an analog way with pen and paper, or digitally. You could add images, emojis, or any annotation that helps your understanding.
For code reviews it can help to draw things out on a whiteboard so you can have conversations about the underlying model and architecture with your teammates. Or maybe walk through the changes together with them and mark interesting points and connections as you talk.
For command lines maybe sketchnotes help to grow understanding and learn new things, or document what you learned. For example, I love Julia Evan’s work of breaking down complex topics in consumable chunks and presenting them in a visually engaging way. Like on bash redirects, on bash errors, or these ones on debugging - too many awesome examples to list them all.
What is your opinion about algorithm? If you know to write and read algorithm, can that be considered as “reading the code” and understanding it? — @layla
For me, algorithms are well-defined instructions with clearly defined steps to solve a particular problem. While a lot of these exist outside of code they could be codified, and of course you’ll have a lot (more or less complex) algorithms in your product’s or project’s code as well. While I don’t think understanding algorithms in general and reading code is the same thing, I do think that if you usually don’t have a hard time understanding algorithms (e.g. in pseudocode), then you can draw from that understanding when reading code. I don’t think it’s a prerequisite, though, as everyone reads code differently, even very experienced programmers (can only encourage folks to join or start a code reading club, it’s fascinating what you can learn with and from each other).
Do you feel being technical sometimes makes testers focus too much on technical issues rather than potentially bigger customer impacting issues with the product? eg long discussion about a function name, or how the code has been written when certain features aren’t working. Have you come across that? – @rforjoe
Yes, I did come across folks who get too focused on details and lost sight of the actual problem to solve. Sometimes that was me. At times this is still me. I’ve seen this across all kinds of roles, with fellow developers, product people, domain experts, and others. I’ve also seen this the other way around, people staying too high level and not seeing all the details required to build a quality solution to the problem at hand. Same here, across all roles.
I believe we continuously need to find a good balance for our context and will always fluctuate a bit within this range. This is also one of the things I love when working in real teams. We are not alone in this, instead we get the collective best of everyone at any given day. We can hold each other accountable and get us back on the bigger picture or indicating important details to focus on, e.g. in order to solve the bigger underlying problem in the end. Both perspectives are important - the challenge is to know what to focus on when, and the answer probably differs from team to team.
Growing technical skills allows us to see more of the whole and understand how things are connected. In my experience this helped me (and other folks in my teams) massively also with these kinds of conversations.
That being said, if there are customer-impacting issues that one person definitely wants to fix yet the rest does not seem to care as much, it seems there’s another topic at hand that involves prioritization as well as company/team culture influences and forces that make people behave in the way they do. Personally, I would seek that conversation and have the team aligned on what issues are considered worth fixing and which ones are not, and what we do when we learn about a new issue. I’m a fan of zero-defect tolerance policies - which don’t mean that there won’t be an issue left in the implementation, yet we decide on any issue coming up right away and tackle the ones worth fixing also right away (instead of having them rot as waste in a backlog).
Along with Angie Jones, who else inspires you – in relation to the topic of technical confidence? — @simon_tomes
So many folks! Let me share more awesome people that inspire me in this context.
There’s Julia Evans as already shared above. I just love seeing her learn in public and always share back with the community in such a valuable way.
Then there’s Amitai Schleier - pairing with him was a real eye-opener for me! just loved his calm methodical approaches based on his massive experience. It was amazing seeing him use all the different tools he picked up over time to figure something out.
Maaret Pyhäjärvi of course! What she shares for years on contemporary exploratory testing is super inspiring to grow technical confidence and add more tools to your toolbox. I also love the following quote from her: “People keep asking me what is the tool and language and methodology they should learn and know. This whole software development thing though, it is not about what you know but what you can figure out in a reasonable timeframe. Much more of connecting many kinds of information (even some held by other people) than any of us knowing it all.”
James Thomas is another one! I’ve seen him make use of his whole toolbox to dig deeper, learn more and discover valuable information at the time it’s needed. At the same time he breaks his approach down for folks in a digestible way and is the first one to encourage them on their own technical journey.
Emily Bache is awesome, too! Super knowledgeable and very kind. I love her way of teaching: going step by step, breaking complex things down to simpler concepts and actionable steps to experience it for yourself, and making her technical sessions accessible to a whole variety of folks.
Finally, there’s in general the folks from the ensemble/mob/teaming community. Everyone working together on the same thing, same time, same place and same computer was and is super inspiring to me for growing technical confidence - we’re not alone in this, together we have all the pieces needed to figure it out.
