What is this project all about?
Can I set up the project locally? How? What are the dependencies?
How do I know if I installed the project properly on my machine?
How do I contribute? What is the existing team process?
Did I break anything after making changes to the code? Are there any tests I can run to make sure that the project is still stable? What sort of tests do we have?
What problems do we face everyday that nobody seems to be trying to solve?
What’s something that’s true for me but a lot of people do not agree with? Why do I believe the opposite?
Where do we want to explore next?
What do we stand for? What values do we deem irrevocable?
Which habits do we need to exercise? Which ones should we stop?
Are we doing something for fun? How did we end up doing this particular thing we’re into now?
What questions do we need to ask someone?
Who do we need to thank?
Which stories about ourselves should we rethink?
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.