88""Yb 888888    db    8888b.  Yb  dP   888888  dP"Yb    888888 888888 .dP"Y8 888888 
88__dP 88__     dPYb    8I  Yb  YbdP      88   dP   Yb     88   88__   `Ybo."   88   
88"Yb  88""    dP__Yb   8I  dY   8P       88   Yb   dP     88   88""   o.`Y8b   88   
88  Yb 888888 dP""""Yb 8888Y"   dP        88    YbodP      88   888888 8bodP'   88
Software Quality Assurance ★ Test Automation ★ Manual Testing
Current Date & Time (Pacific) ★

------------------------------------------------------------------------
My QA Philosophy 🤔
Go back ⮐

Thoughts on Software Quality Assurance 💭
- I see my role as an observer and communicator, not as the gatekeeper
- or ‘quality police.' I provide feedback, not roadblocks. If the team
- wants to ship something, my job is to make them aware of potential
- issues, not to hold things up. This approach has helped me build
- strong, collaborative relationships with developers, designers, and PMs.

- Quality is a team effort, not just a post-coding activity.

- QA teams are there to complement and enhance quality efforts,
- not to replace them entirely. Developers, product managers,
- designers, and other stakeholders play a crucial role in maintaining
- quality standards throughout the development process.

- It's impractical to test every possible scenario.

- Additional defects found by exhaustive testing may not justify
- the resources invested in leaving no stone unturned.

- Not all parts of an application are equally important
- or carry the same level of risk.

- Testing should be concentrated on the areas that are most critical
- to the users and have the highest impact on the user experience.

- Not all bugs are worth fixing.
------------------------------------------------------------------------
A Holistic Approach to Quality
My approach to quality assurance goes beyond finding bugs. I
look at the application as a whole, identifying gaps in requirements
and assessing not just functionality but the overall user experience.
Often, I find areas where the code meets the technical specifications,
but the spec itself didn't fully consider certain user perspectives or
scenarios. My goal is to provide feedback that aligns with real-world
usage, helping teams anticipate potential issues and improving the product
for end users. I aim for software that's as functional as it is user-friendly.
------------------------------------------------------------------------
Work Style and Collaboration
I value..
thoughtful, independent work and can produce high-quality results
in less stressful environments. I perform best in environments
where I have the space to think things through and manage my tasks at
a steady, efficient pace. I prefer fewer meetings, minimal
distractions, and an asynchronous work style that allows me to focus
deeply and deliver quality work while still staying aligned with the
team. While I work best when I have time for deep focus and independent
tasks, I also thrive in smaller collaborative settings, such as working
closely with developers. I'm always ready to seek help when I hit a
roadblock or be there for the team when they need me.

I'm comfortable..
with vague or evolving requirements. I don't need everything spelled
out for me or much handholding. In fact, I actually prefer unstructured
environments because they give me the freedom and autonomy to figure
things out as I go. I trust my judgment and experience to guide me when
things aren't perfectly laid out and enjoy the challenge of navigating
ambiguity. If something doesn't feel right, I'll ask for clarification,
but I'm comfortable with taking the initiative to find solutions
independently.

I'm not a fit for..
environments with aggressive deadlines, hustle culture, or sprint
planning that holds you hostage based on initial story point estimates.
Most of my previous roles have had very few deadlines, allowing me to
work at my own pace, which seemed to always satisfy the team and sync
well with the overall workflow. I've primarily worked in small companies
and very small teams with sometimes just a couple of developers where
the focus was on collaboration and delivering quality work, not rushing
to meet deadlines.
------------------------------------------------------------------------
Thoughts on Waterfall, Agile, Scrum, Kanban 💭
I've worked in a mix of Waterfall and Agile setups, and it's been a
bit of a mashup. In some places, things were handed off to QA after
devs finished their initial coding, which was like Waterfall with Agile
ceremonies and a 2-week sprint sprinkled on top. Another place ran
more Kanban style, no timeboxed sprints, no deadlines. Also have been
involved in the design phase and at one place I was taking stakeholder
requests and turning them into requirements.

Agile/Scrum Anti-Patterns ❌
Tying story points to hours is an anti-pattern. Story points are meant to
represent effort or complexity, not time. If you're linking them to hours,
you might as well just call them hours from the start.

Dividing points evenly among the team is flawed. For example, if there are
30 points and 5 people, it doesn't mean each person gets 6 points. Story
points are about the collective effort, not individual quotas. Splitting
them like that assumes everyone's work takes the same amount of time
and effort, which is exactly what story points aren't meant to represent.
Team members have different strengths, and not every task is equal in
terms of complexity or effort. Plus, everyone works at their own pace,
so treating points like they're interchangeable leads to unrealistic
expectations.

Another pitfall is treating estimates like commitments. Estimates are just
guesses based on what we know at the time, and they're often wrong. Yet,
in some places, once an estimate is made, it's treated like a firm
commitment.

I've also seen QA get a fixed number of points based on dev points. If a
dev ticket is 4 points, QA automatically gets 2 points. It's like assuming
cleaning the kitchen is always half the effort of cooking dinner.

When story points are tied to hours or treated as firm commitments, it
leads to micromanagement and prioritizes output over quality. For me,
it's about collaboration, delivering value, and continuous improvement,
not chasing numbers or deadlines.
  1. What Is Story Point Estimation?
  2. Commitment vs. Forecast: A Subtle But Important Change to Scrum
  3. Story Points: To Estimate or Not to Estimate
------------------------------------------------------------------------
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. This flexibility allows me to uncover
issues that might otherwise slip through the cracks. It also
encourages usability and UX observations that may not be considered
during a structured test. It's where testing transforms into an art,
using my curiosity, intuition, and testing instinct to uncover
unexpected issues.
------------------------------------------------------------------------
Thoughts on Automation Testing 💭
I'm all for automation, but I feel the idea of automating
everything should be approached with caution. I'm not jumping
on the automate everything bandwagon and recognize the pitfalls
of flaky tests and heavy maintenance burdens. It's not a
magic wand that makes manual testing disappear. There's a
misconception that it always saves time, but in reality, that's
not a guarantee. I believe in a balance between manual and
automated testing.

- Automation doesn't eliminate the need for manual testing.
- Automation won't always save time over manual testing.
- Not every test is a good candidate or suitable for automation.
- Creating an automation script requires an initial time investment.
- Automation scripts require an ongoing time investment (maintenance).
- Automation suite can grow too big and become unmanageable.
- Be prepared to deal with and troubleshoot flaky tests.
- Automation often leads to unexpected challenges.

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
------------------------------------------------------------------------
Top ⇧