Skip to main content

Requirements Analysis is comparable to "Sudoku"

Are you familiar with Sudoku? It's a number puzzle that challenges your logic. It's a 9x9 grid where composed of sets of 3x3 tiles. Initially, the grids are pre-filled with a few numbers and the goal is to fill each grid, row, and column with numbers from 1-9 without duplication.

Screenshot from Wikipedia

Requirements analysis is a crucial task that a QA must do well for this is the pillar of the project's testing outcome. We must immerse ourselves in the requirements specifications, clear out any unclearness or uncertainty in the expected results, think of any possible specifications that were missed, consider how it might work with other features, and imagine different scenarios that an end user could do.

Now how does this task compare with Sudoku?

Empty cells in grids

Requirements, no matter how the product owner/business analysts try to polish it the best as they can, will always have something that a tester might think is missing or unclear. This is like us looking at a Sudoku puzzle for the first time. There are numbers plotted but it's not complete.

Looking at the pre-filled numbers

Once we receive the requirements, QAs will have to read and understand them first. This is the only way we can derive our questions like:
  • Specs: The user will automatically be logged out when they're idle.
    • "How many minutes before they get logged out?"
    • "What exactly happens as soon as they get logged it? Will they be a modal first before they get logged out they it just happens immediately?"
  • Specs: The user will be able to purchase the product when they have sufficient points.
    • "What if the end user is a blocked user?"
    • "What if the user had the items in the cart but before they checkout, their points got expired?"
  • "What about x feature that has a similar component? Do they have to be consistent?

Filling up the empty cells

A QA must have good communication skills, patience, and good organizing skills to effectively raise these questions to the team and keep track of everything.

As we resolve each question one-by-one, we can start to fill the empty cells. We start to understand the connection of the grids, rows, and columns so that all of them get their 1-9s.

Completion of the puzzle

What's next? For a QA, the next step (or in reality, it could be concurrent) is to create the test cases.

Ensuring that we are basing our test cases on clear requirements means that we'll be able to test the right thing, close to how the team intends the software to be.

Labels:

Popular posts from this blog

Reframing how I identify bug root causes

It's been more than a year now since I've set up our bug tracking in JIRA. In there, I've set up an Issue Root Cause custom field where it had the following options: Incorrect coding Unclear / Missing / Incorrect Requirements Unclear / Missing / Incorrect Design Insufficient / Duplicated / Incorrect Testing Deployment Issue Environment Third-party issue My thoughts when I listed these as options is so that it would be easy to identify which team is responsible for the cause why we had that bug. They're pretty straightforward -  Incorrect coding  is of course when the developers didn't follow the expectations,  Unclear / Missing / Incorrect Requirements is because there's a gap in the requirement, and so on. And also, it's because that was the way it's done in my previous company so that's also my initial knowledge source. Recently, I've been reading a few articles regarding Shift Left, reducing silos, and generally how quality is a team activit...
Read more

QA Tools: Custom Test Case Generator in Google Sheet using Google App Script

When testers have to document test cases, it's usually done in the traditional format of putting all your test cases and steps in one sheet. Once it accumulates, for me it can be overwhelming to look at. It looks something like this: As a solution, I decided to make a tool that will help me focus on only drafting my test scenarios and look at my test cases one at a time. I'd like to share this here with everyone else who's like me. Hopefully, it can make your testing journey even a little better. Test Case Generator Tool This tool is for QA or non-QAs who need to write test cases. What it can do: Write your test scenarios in one tab Focus on writing steps for each test case one sheet at a time Generate an import file Generate a test execution document Sample test execution document: Scroll to the bottom to see how it works. Sheet Purpose Test Scenarios This is where you set the details for this test set/the project/story/epic where you're creating the test cases u...
Read more

A Bug's Life! Defect Management Process in Software Testing

First things first, what does a "bug" mean in the software development process? A bug is what we call a behavior that is different from what's expected based on the provided requirements. A tester's main purpose is to find and report bugs in the system as early as possible. In some companies, it's sometimes called a "defect". They actually mean slightly different if we go by the book. In this post, I'll be covering the lifecycle of a software bug which are issues that are found during the development phase. You're testing the system and you found a bug. What is the first thing you do? a) You immediately write a bug report b) You try to reproduce it c) You complain "How could this very obvious bug reach QA? Dev should've spotted this earlier ugh." The formal answer is B (I'll just let you figure out what's the informal answer), It's common for a QA to be gaslighted. "I cannot reproduce this bug.", "It doesn...
Read more