Having received a handful of calls these past few weeks, I’ve realized that I’m thinking more about learning opportunities now than only looking at an offer’s compensation package. Salary still matters of course but there’s more to a day job than just allocating money for expenses and savings. Work wouldn’t be fun when there’s only menial work to do. What would I learn if I took an offer in exchange for my services? Will I be doing something I’ve never done or tried before? Is this work meaningful, both for our customers and for me as an individual?
And some more questions to recruiting employers on the top of my head:
- How does the existing software development and testing process work in the organization?
- Are testers embedded into software teams? Or do they work in silos, away from the developers?
- What does a software team look like and compose of?
- What does the day-to-day work look like for the software tester?
- How many testers are there currently in the organization? And what’s the existing ratio of developers to testers?
- What technologies do the organization currently use for testing? Are there automated checks? Is there an existing CI system?
- Does the organization use containers? Visual testing? Machine learning?
- Who are the organization’s actual clients? Which lives are we trying to improve on a daily basis?
- How do the software teams get feedback from the people who use their applications?
What does our team actually want to accomplish this particular sprint?
Do I know my teammates well enough?
Does everyone in the team feel safe working together with each other?
Can I rely on everybody in the team?
What does a user story mean to us?
Do we even need tickets in order to perform our best work?
Do we truly need this specific document to move forward?
How can I help a teammate feel good with the work he/she is doing?
What’s the minimum amount of input do we need in order to start?
What’s the 20% of activities that contribute to 80% of outputs we desire?
Do we believe in what we are building?
Which rules, in reality, help us become the best versions of ourselves? Which don’t?
Who is in charge of the testing that the team needs to do?
Who do I want to connect with today?
How do I need to think when I’m testing?
Did I help someone yesterday?
Why do I say that a product is of good quality?
What do I really do?
How much documentation is necessary?
Where did I fail this week? Did I fail enough, or was I playing safe?
What stories do we need to tell? To whom do we tell our stories?
What am I afraid of? Why am I afraid?
What am I supposed to do next?
I’ve mentioned Jame Bach and Michael Bolton’s ‘Rapid Software Testing’ ebook before. I am citing their resource once more today because they’re worth revisiting again and again, for software testers. Many of the things I’ve come to believe in about software testing are here, explained well in interesting lists, charts, and descriptions. Such are the things that junior software testers need to fully understand, as well as the stuff that seniors should thoroughly teach.
Quoting some lines from the slides:
- All good testers think for themselves. We look at things differently than everyone else so that we can find problems no one else will find.
- In testing, a lot of the methodology or how-tos are tacit (unspoken). To learn to test you must experience testing and struggle to solve testing problems.
- Asking questions is a fundamental testing skill.
- Any “expert” can be wrong, and “expert advice” is always wrong in some context.
- The first question about quality is always “whose opinions matter?” If someone who doesn’t matter thinks your product is terrible, you don’t necessarily change anything. So, an important bug is something about a product that really bugs someone important. One implication of this is that, if we see something that we think is a bug and we’re overruled, we don’t matter.
- It’s not your job to decide if something is a bug. You do need to form a justified belief that it might be a threat to product value in the opinion of someone who matters, and you must be able to say why you think so.
- In exploratory testing, the first oracle to trigger is usually a personal feeling. Then you move from that to something more explicit and defensible, because testing is social. We can’t just go with our gut and leave it at that, because we need to convince other people that it’s really a bug.
- Find problems that matter, rather than whether the product merely satisfies all relevant standards. Instead of pass vs fail, think problem vs no problem.
- How do you think like a tester? Think like a scientist, think like a detective. Learn to love solving mysteries.
- What processes and tools are do I need to be effective in performing my work? Are there ineffective systems that I blindly keep using?
- How can I provide immediate feedback to the people that I serve?
- Why did my colleague or client arrive at this sort of assumption/conclusion? What do they need?
- How can I learn new interesting things quickly? Which interesting topic of inquiry may be of some use to me in future endeavors?
- What sort of work conditions allow me to do my best work? How come I can’t deliver in certain environments?
- How can I help my customers find answers to their questions? What solutions can I share that will help them achieve their goals?
- How can I say that I’ve improved at something important to me? Where am I now and where am I going?
I always ask myself questions. They are friends who help me learn, they guide me about what to do. They don’t provide any specific answers, no list of items to tick off, but they do make you understand what is valuable and why there is a constant need to study. They force me to be brutally honest with myself, they let me decide which things I want to be a master of.