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 QA and Support ★ Automation ★ Manual Testing
Current Date & Time (Pacific) ★
------------------------------------------------------------------------
Testing Skills 🖥️
Go back ⮐
Roots in UX: The Beginning and Outlook
My journey began in usability testing and UX research, which gave me a
deep understanding of how users interact with products. Since then, I see
software through a UX-first lens that others often overlook, focusing on
the user experience alongside functionality. From there, I transitioned
into manual testing, learned a bit about JavaScript at another job, and
most recently have been working with test automation.
Sole QA to a QA Team: Experienced in Different Environments
In three of my four QA roles, I was the first and only QA hire at small
companies, so it was just me, a few developers, and a product manager,
making for a really tight-knit team. One of the places didn't have
a product manager, so I helped out with gathering and refining
requirements from stakeholders. In my other role, I worked with a team
of five QA analysts and three product managers where things were much
more defined and structured.
Beyond the Checklist: Thinking Critically
I'm someone who thinks beyond the basics and doesn't just follow
the checklist of “Did this pass or fail?” My approach to QA is more
about exploration and critical thinking than just following structured
test cases. My real strength? Finding issues others miss or don't think
about. It isn't just about confirming if something works, but is also
asking, Should it work this way? How well does it work? How secure is
it? Does it make sense for users? A feature might work as designed, but
that doesn't always mean it works well. Does it guide users smoothly
or create friction?
Looking at the Specs: Are There Gaps in the Product?
I look at the application as a whole, identifying gaps in requirements
and assess 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.
Getting QA Involved Early = Better Outcomes
QA works best when I'm involved early. I catch issues before they turn
into bigger problems, even before development starts. By reviewing designs
and specs upfront, I can catch potential issues early and ensure smoother
development down the line.
Not Just Coding: Hands-On Testing Driven by Curiosity
Don't be deceived by all this tinkering with code. I enjoy and dedicate
a lot of time to manual hands-on testing, especially exploratory testing.
I love the freedom it gives me to uncover issues in creative ways. I
dive in headfirst, trust my instincts, and see what breaks. I'm motivated
by curiosity and the freedom of discovering issues through exploration.
Identifying Risks: QA That Considers Business Impact
I focus on identifying risks that could impact the business, not
only finding the bugs.
Instead of simply saying, "Here's a bug, this doesn't work."
I ask, "How might users react? How could this affect the company?"
When building an app, it's not just about the features, it's also
about considering the real-world impact of the product's design.
Are we overlooking something that could frustrate users, damage the
experience, or even hurt the brand? QA isn't just about testing.
It's about understanding the bigger picture, anticipating risks, and
ensuring the product succeeds on every level.
Clear and Detailed Bug Reporting
When I'm reporting a bug, I don't just toss out some dry steps and
call it a day. I make sure to walk you through it. Every step, and
every bit of the breakdown. I'll show you where things went off
track and what should've happened instead. For more complex issues,
I'll create a video and narrate the whole thing, so you're not
left guessing. You'll hear exactly what's going wrong, why it matters,
and how we can fix it clearly.
Example of My Bug Report Breakdown
- Preconditions: Establishing the context for the bug, if necessary.
- Environment: Browser, OS, mobile, desktop, etc..
- Steps to Reproduce: Here's exactly how to make it happen.
- Actual Result: What went wrong, plain and simple.
- Expected Result: This is what was supposed to happen.
- Screenshot(s): A picture speaks a thousand words...
-
Narrated Video Walk-through: I'm talking through it, explaining
every step, every detail, so you get it. No guesswork, no
confusion. Just clarity.
- Notes: Additional info, console errors, links to related tickets, etc.
Bug Triage and Prioritization
If it's a bug that's not urgent, I'd just throw it in the backlog and let
the product team review it when they're sorting out the next sprint.
However, if it's critical, or needs fixing soon, I'd message the PM or
Dev, or tag them in the Jira ticket.
Analyzing and Troubleshooting: From IT to QA
In addition to QA, I also have experience in IT support, networking,
and server administration. I also have a few computer certifications.
I'm still hands-on with IT. At home, I've set up VLAN tagging and
SSID segmentation to separate traffic into multiple networks.
IoT devices, guests, and trusted systems are isolated for security.
Firewall rules control traffic between these subnets and the WAN.
An Intrusion Detection and Prevention system (IDS/IPS) monitors
and helps block security risks.
------------------------------------------------------------------------
Top ⇧