Ready to Test (QA)

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) ★

------------------------------------------------------------------------
Work Style and Collaboration
Go back ⮐

I know being upfront about my preferences might limit some
opportunities, but I'm more interested in finding the right fit
than just landing any job. I'm not here to craft a generic
LinkedIn profile full of safe, predictable statements that tick
all the boxes.

This is my personal site, and I want to be transparent about about
where I thrive and where I don't. Trying to tell people what they
want to hear is a short-term move. I'm in it for the long haul,
and that starts with finding the right fit.

I value..
thoughtful, independent work and can produce high-quality results
in less stressful environments. I perform best in environments
where the pace is steady and manageable, which allows me to
consistently deliver high-quality work without feeling overwhelmed.
While I work best when I have time for deep focus and independent
tasks, I also thrive in environments where collaboration is focused
and efficient, 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. I actually like when things aren't
always perfectly defined. It gives me the freedom to think critically
and solve problems on my own. When there's ambiguity, I see it as a
chance to get creative and take initiative. It's not something I try
to avoid. It's more like an opportunity to trust my judgment, explore
different solutions, and figure out the best way forward, even if the
path isn't totally clear. I find that kind of flexibility pretty rewarding.

My Ideal Work Environment
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. In others, I've been involved in the design
phase, and at one place, I was taking stakeholder requests and turning
them into requirements. I actually prefer getting involved sooner. It
helps catch potential issues before they become bigger, time-consuming
adjustments later on.

Scrum feels like a more prescriptive way of doing Agile, with its
time-boxed sprints and ceremonies (meetings). It's a bit more
structured than what I find works best for me. I've found it can be
harder to adapt to the level of oversight, as I tend to thrive in
environments where I have more independence. I've found that Scrum
can end up focusing too heavily on output and deadlines over quality,
which creates unnecessary stress that can hinder both individual
performance and overall team success.

I prefer a more Kanban style approach, where the focus is on
flexibility, flow, and collaboration. There's less pressure around rigid
processes, and more emphasis on getting things done thoughtfully and
at a sustainable pace. Additionally, Kanban generally involves fewer
meetings, allowing for more time to focus on the actual work. I believe
Kanban aligns more with the spirit of the Agile Manifesto, which
prioritizes flexibility, collaboration, and adaptability over rigid processes.

That said, I've worked at one place that practiced what I'd call
"Light Scrum", and it worked fairly well. There were no strict deadlines,
no story points, and the devs and I weren't shackled to the estimates we
made during sprint planning. It was more collaborative and less about
chasing numbers or rigid deadlines.

Agile/Scrum Anti-Patterns ❌
Story points = hours?
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.

If you divide story points equally among the team, you're treating them like
they're based on time, assuming each person will spend the same amount
of time on their tasks during the sprint. Splitting them evenly suggests
that everyone will contribute the same amount of effort, which isn't true.
Some tasks might be easier or harder for different people, and their pace
can vary.

We'll ask for estimates then treat them as deadlines
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.

Assuming cleaning the kitchen is always half the effort of cooking dinner
I've experienced a situation where QA points were determined as half of
dev points, which can oversimplify the complexity of testing and didn't
reflect the true effort involved.

The story point trap
When story points are treated like a timecard or a strict work quota, it
leads to micromanagement and puts too much emphasis on output
instead of quality. I've experienced that in one environment, and it's
not something I'd want to do again. Most places I've worked at were
much more flexible, focusing on collaboration, delivering value, and
continuous improvement over chasing numbers or rigid deadlines.

------------------------------------------------------------------------
Top ⇧