Whether you’re managing a household or troubleshooting a broken garage door, they reveal how these experiences can apply directly to understanding complex systems in your testing work.
What You’ll Learn:
Leveraging everyday problem-solving: Learn how daily tasks like planning meals or fixing household issues can develop your systems thinking skills for testing.
Deepening your systems understanding: Discover how a better understanding of the systems you work with can improve your ability to find bugs and strategize your tests.
Building continuous improvement: Explore practical examples of applying systems thinking in real-world testing scenarios and why it’s essential for effective test automation.
Gaining confidence through practice: Find out how regularly applying systems thinking to your testing can boost your confidence in handling complex testing environments.
After reading, we’d love to hear from you:
What everyday problem-solving habits have helped you improve your software testing?
Will you apply any of the strategies from the article to improve your systems thinking?
Gonna take this a little sideways, It reminds me a little of a social media thread I visited, where a guy gave recommendation för career moves for like 30yo’s. One thing he rooted for was to “follow your passion”, a thing I see as pretty stupid to say to a 30 yo. If you’re a passion follower you A are born in a community where passions are supposed to be followed B you have something really extra to exploit. To tell the average joe to all of a sudden follow passions is maybe not so good. If he hasnt done it already he most probably will not do it either at 30yo.
What I want to say here, after reading the article is - use your energy wisely. To learn about the system is not what makes you a good automation guy. For me, noone have to tell me to exploit the systems I work with in the way my brain tells me to exploit the system. Do not try too hard to understand stuff that really don’t is your cup of tea to understand. If you do get your energy from knowing how to master Cypress to push this or that impossible button or making it see a frog in a picture of a wood, do that more.
An anectdote about this was a really good partnership I had a couple of decades ago with an automation of a CLI/API environment - I did really love that system but hated the automation environment and randomly run into a guy that was the exact opposite. We teamed up and that automation was pretty d*mn good.
Sometimes especially managers have a way of looking at employees as “resources” or even worse “engineers”, supposed to be equally competent and passionate about everything, kinda like that engineer on Jules Vernes deserted Island that could just fix anything. Of course that T metaphor is true that you shouldnt just get deep in whatever, but I think, with all the talks latest decades of the agile way of working where those stable teams are going to solve everything, well, in all agile operations Ive been last say 15 ys there has never been bad that a software guy or girl goes deep in whatever rocks that persons boat. We’re people with brains and brains arent tabula rasas.
So when I started my career as a software tester I had the habit of multi-tasking especially picking multiple tickets at a time or committing to different tasks without focusing on the priority. This issue severely impacted me when I started my journey in automation testing, as I had lack of clarity in the roadmaps so I picked UI Automation, API & Mobile apps automation at the same time which ultimately led me to a deadlock situation where I was unable to move forward, finally to resolve the issue I had given up on API & mobile apps automation for time being and started focusing on UI Automation.
However, this was not the first time I faced such an issue in my professional life. I had the same issues in my personal life, where I prioritize multitasking over prioritizing every task individually and would rather try to complete all the tasks at the same time, which eventually leads to the wastage of time and effort as none of the tasks is eventually completed.
So, I started by focusing on short-term and long-term goals. I also started making a to-do list and writing in a journal.
Now how does this habit help in software testing?
As these habits helped me achieving the goals that I planned, I started making a To-Do list for my office work. I would make a To-Do list every day, and that’s my first task in the morning. At the end of the day, I ticked the task that I had completed. The benefit is that I’m aware of what I have to pick and complete throughout the day. Also, in case someone asks me about my work details, it is a bit easy to share.
Through journaling my documentation practice gets stronger so that is also helping me in my writing skills as well as in documentation in my job.
I do this too, and do update it every morning and after lunch. It also has the effect of making me extra motivated for what I have to do since I give myself an assertion I’m doing the right things.