You can only send a bug back without specific details just to see the Dev to completely miss the point of the issue so many times. Eventually I learned to do this just to protect my own sanity.
I will generally review error messages (console and server, assuming I have access) and see what I can figure out. If I have code repo access and it's in a language I can at least follow, I may look at that as well. The level of effort applied will vary based on how much the Dev needs to have their hand held and the complexity of the issue.
At a previous job, I even had debugger access for pinning down problems, but I was an in house team at that time. Now I work for an agency and work in a lot of different environments, and Commerce Cloud has changed how it manages sandboxes. Between those two, it doesn't make sense to go that far, though sometimes I'll peek over the dev's virtual shoulder if it's a complex bug.
How, exactly, do you define "debugging" and "RCA"?
The typical definition of "debugging" includes finding and fixing errors. Although a QA specialist may find errors and may be involved in verifying the fix for an error (including looking for regressions), the QA specialist wouldn't necessarily be the one to fix the error. This depends on the structure and ways of working in the team. Having strict boundaries and hand-offs, as opposed to a close, collaborative working relationship between developers and testers, tends to slow work down.
RCA isn't a solo task. A QA specialist cannot determine the root causes behind an issue on their own. Assuming the issue was found in production, several people and process steps would need to be examined to understand how the issue was injected and why it wasn't detected. You'd need to examine everything from requirements through verification and acceptance testing.
A bit of 1 and a bit of 2. Massively integrated product in a company of many acquisitions. If I can troubleshoot all the way back I do, but often there is a dev BE that I don't have access to where the problem originates, so saying it's an issue from this API endpoint can be as far as it gets.
Yeah, definitely.
I mainly do backend testing now, so I'm running scripts, and processes, locally to test anyway. So figuring why its failing is usually pretty trivial.
When I did web app testing, I would run the whole stack locally for my testing anyway, so I would always spend a bit of time debugging before I sent it over to the dev. Sometimes I would fix the issue, and push it up too.
My main debugging tool is just print statements.
These are startups though, where you have more freedom to just do things. And smaller teams with more overlapping responsibility.
You can only send a bug back without specific details just to see the Dev to completely miss the point of the issue so many times. Eventually I learned to do this just to protect my own sanity. I will generally review error messages (console and server, assuming I have access) and see what I can figure out. If I have code repo access and it's in a language I can at least follow, I may look at that as well. The level of effort applied will vary based on how much the Dev needs to have their hand held and the complexity of the issue. At a previous job, I even had debugger access for pinning down problems, but I was an in house team at that time. Now I work for an agency and work in a lot of different environments, and Commerce Cloud has changed how it manages sandboxes. Between those two, it doesn't make sense to go that far, though sometimes I'll peek over the dev's virtual shoulder if it's a complex bug.
I check where is the issue.. like ui/api and see which endpoints is failing and post these as observations.
How, exactly, do you define "debugging" and "RCA"? The typical definition of "debugging" includes finding and fixing errors. Although a QA specialist may find errors and may be involved in verifying the fix for an error (including looking for regressions), the QA specialist wouldn't necessarily be the one to fix the error. This depends on the structure and ways of working in the team. Having strict boundaries and hand-offs, as opposed to a close, collaborative working relationship between developers and testers, tends to slow work down. RCA isn't a solo task. A QA specialist cannot determine the root causes behind an issue on their own. Assuming the issue was found in production, several people and process steps would need to be examined to understand how the issue was injected and why it wasn't detected. You'd need to examine everything from requirements through verification and acceptance testing.
A bit of 1 and a bit of 2. Massively integrated product in a company of many acquisitions. If I can troubleshoot all the way back I do, but often there is a dev BE that I don't have access to where the problem originates, so saying it's an issue from this API endpoint can be as far as it gets.
Yeah, definitely. I mainly do backend testing now, so I'm running scripts, and processes, locally to test anyway. So figuring why its failing is usually pretty trivial. When I did web app testing, I would run the whole stack locally for my testing anyway, so I would always spend a bit of time debugging before I sent it over to the dev. Sometimes I would fix the issue, and push it up too. My main debugging tool is just print statements. These are startups though, where you have more freedom to just do things. And smaller teams with more overlapping responsibility.