One of the biggest challenges I typically face when joining a development team is understanding the silo between programmers & testers (& other team members).
I approach this challenge by referring to both roles with the generic term of “Developer”, whilst using “Programmer” & “Tester” to differentiate between the roles when required.
I use the term “Developer” as we are both helping to develop software. I believe I got the analogy of eating from Michael Bolton – you can’t keep stuffing food in your mouth (programming) without swallowing (testing).
This post builds on that idea to share how I use the fire triangle as a metaphor for activities & roles that play a part in software development.
Several projects I am working on within my organisation are adopting SAFe in order to build software solutions, so I thought I should perform some SAFe testing!
With my Agile background, I am able to provide a lot of value in helping the teams follow an iterative development lifecycle (predominantly Scrum), but I have little experience of processes outside of the development teams themselves.
I also seem to struggle to get my message across to senior stakeholders within my organisation who are new to Agile & SAFe.
This is the 2nd post in my series on Truth. It builds on the first post by hopefully demonstrating how my opinions on truth & “Living Documentation” have changed after some research into what is truth.
This research was done in preparation for the fabulous MEWT conference. Here is a link for the slides of my “Single Source Of Truth Is A Lie” talk – this post aims to follow the structure of that talk.
As you may be aware, I follow certain testing folks in the Context Driven community. Some of these Testers are members of the Miagi-Do School of Software Testing.
I have read & heard about this Miagi-Do school for a while – I knew I had to complete a challenge to ‘gain entry’ in order to prove my worth, but I had never got round to following up on how I go about receiving a challenge.
This post is about using the output from my Testing The Time Machine dojo to help me develop my exploratory testing, presentation & facilitating skills.
The previous post includes what I learnt from the session generally, in terms of organising a geek night & presenting. This post is about what I have learnt from the session output combined with the previous post in order to identify clear goals for my continued exploratory testing learning as well as improving the dojo.
>Its been around 12 months since I started on my learning journey & as I’m starting to look for my goals for the next 12 months I thought it would be wise to take stock & see what I have & haven’t achieved.