Designing test scenarios would be my bigges QA challenge. After breaking down the criteria, I could comprehend them, but writing thorough, effective test cases was the true issue. It was more than creating steps—it was about thinking critically from numerous viewpoints, predicting edge cases, contemplating positive and negative scenarios, and catching anything crucial. That component challenged me since it requires a deeper perspective than just testing. I had to think like the user and business. If I had more time, I would make my test case design more strategic and complete. Expanding edge cases, covering unanticipated user behaviors, and improving requirements, test cases, and defect traceability are my priorities. I would also spend more time clarifying bug reports, specifically repeatability methods and impact descriptions, to make them developer-friendly. Quality assurance is about critical thinking, precision, and communication, not just detecting faults. This experience would help me contribute to a real QA team. I now understand the need of requirements analysis, systematic validation processes, explicit issue documentation, and tool organization. Most importantly, it showed me where I needed to improve, giving me real experience and a growth mentality for a QA team. I could add value rapidly and improve my testing with that combination.

Companies prefer test case management tools over spreadsheets because they provide better organization, real-time collaboration, traceability, and reporting. They reduce manual errors, make it easier to track test coverage and progress, and integrate with development tools—making testing more efficient and transparent across the team.

Assigning the wrong severity or priority can lead to critical issues being overlooked or minor issues being overworked. It causes wasted effort, delays important fixes, and can negatively impact product quality and user experience.

@Chantal Brown For me if a developer disagrees with the severity/priority, my first instinct wouldn't be to disagree with him/her. I'd get them to work with me collaboratively vice me being defensive. We should review the bug together to make sure we are looking at the same impact and reproduction steps. We would need to listen to each others perspective on my assessment vs their technical perspective. If we still disagree, might have to bring in a third party who can slap the table on decisions based on impact/risk not our opinions

As " Verify that the email and password icons are sized appropriately" is written, it would not be accepatable. "Sized appropriately" is subjective and not measurable. One tester could think the icons look fine, while another disagrees. This just creates inconsistent testing results and unclear expectations for developers. You can ask the developer for exact icon dimensions, alignment rules, and visual behavior.

A Jira bug ticket is helpful when it’s clear, detailed, and includes steps to reproduce, expected vs. actual results, and supporting evidence like screenshots or logs. It’s frustrating when it’s vague, missing details, hard to reproduce, or lacks context, forcing developers to guess or ask follow-up questions.