Thoughts on Software Quality Assurance 💭
- QA shouldn't only be the person who shows up after the party and
- says, "Hey, someone spilled wine on the couch." 🍷 QA should be
- the one saying, "Hey, maybe don't set the red wine next to the
- dance floor in the first place."
- Every project, every team, and every challenge teaches me
- something new. I've learned a lot from the people I've worked with.
- I see my role as an observer and communicator, not as a gatekeeper
- or the 'quality police.' My job is to provide insights so the team
- can make informed decisions, not create roadblocks.
- Don't just make sure nothing's on fire, ask why the gas line's leaking.
- Don't just inspect the faucet. Inspect the plumbing.
- QA isn't just about clicking through features and reporting obvious
- bugs. It's about digging deeper even when things seem fine, asking
- whether things actually make sense, catching the stuff no one else
- thought to look for, and not assuming what's given to you is correct.
- See why
"It works" isn't enough in QA.
- The foundation for quality starts upstream even before a single
- line of code is written. Quality issues can start way earlier in
- fuzzy requirements, unclear designs, unchallenged assumptions,
- and overlooked scenarios. Sure, testing can catch the cracks
- later, but it's a lot harder to fix the foundation after the
- house is already built. See an
example of a bug caused by a
- missing requirement.
- If QA collaborates early they can help the team spot where
- cracks might form before the concrete is even placed.
- Tight deadlines don't help either. If teams are under chronic
- pressure to hit deadlines, it often leads to rushing, cutting
- corners, and a string of hotfixes that just patch up other
- hotfixes. That's when quality starts to slip, because the
- focus shifts from doing things right to just getting it done.
- You're shaping the product with a focus on user experience and
- business impact. Say you're testing a new checkout flow. The goal
- is more sales. If the process feels cumbersome you flag it, even
- if there are no functional bugs, because it might cause people
- to abandon their cart.
- Not all parts of an application are equally important or carry
- the same level of risk.
-
Not all bugs are worth fixing. In the real world, teams don't
- have unlimited time or dev resources to fix every bug and make
- everything perfect. You prioritize. Some bugs just don't matter
- enough to fix, and so you mark them as "won't do" and move on.
-
Look at the pull request and diff, even if you can't read the code.
- How big of a change is it (one file or ten?), and in which areas?
- Check the PR convo too. If it says, “Wait, are we sure this is the
- right behavior?” or “Quick patch before launch,” then you should
- probably test more thoroughly. I'm not reviewing code; I'm looking
- at PRs to understand scope, risk, and the story behind the change.
------------------------------------------------------------------------
Thoughts on Manual Testing 💭
- I find value in exploratory testing. It's the freedom to approach
- testing naturally, seeing the software through the eyes of an end
- user. Without the confinement of scripts, it opens the door to
- creativity and adaptability.
------------------------------------------------------------------------
Thoughts on Automation Testing 💭
- Automation doesn't replace manual testing. Manual testing is
- needed for exploring new features, identifying edge cases, and
- understanding the user experience.
- Not every test is a good candidate or suitable for automation.
- The Automation suite can grow too big and become unmanageable.
- Be prepared to deal with and troubleshoot flaky tests.
- Don't forget to
test your tests. Make sure the assertion
- fails when it should and passes when it should...consistently.
- Looking ahead is important. If the product roadmap says a part
- of our site is getting a facelift in the next couple of months,
- maybe we shouldn't go all-in on automation scripts just yet.
- The last thing we want is to spend more time maintaining
- automation scripts than we save by having them.
- Also we need to keep in mind that automated scripts can be
- sensitive, behaving differently between environments. What
- works perfectly in your local environment, might throw a fit
- in the
GitHub Actions runner.
------------------------------------------------------------------------
You made it all the way down here, so we'll give you a Joke.
Joke API source file:
jokeApi.js
------------------------------------------------------------------------
