ianahilario

We just had our all-hands meeting and I'm watching the slides of our various development teams about their accomplishments for the year - from the release of our products to technology upgrades to some major refactors. I started imagining what our QA slide would look like, but then I kept getting stuck. At the end of it all, the most important gauge of software development in general is that we've delivered working software. But in what area can the QA team take credit for the success? Is success in the number of bugs found during testing? When I was starting my new job, I was happy that I was able to catch a lot of bugs before the changes were deployed to production. One day, a developer asked me this: "Why is QA happy that there are a lot of bugs?" I told him, "Well, it's my job to find bugs before someone else finds them." And then he dryly replied, "I see." It got me thinking later if my mindset is actually correct. With the introduction of...

Professional book writers still have proofreaders and editors up to this day, but why is it that there's a rush to drive away manual testers? There's probably an AI tool somewhere out there to check the book's grammar and spelling errors. But what the AI cannot do (for now) is assure the quality of your book - ensuring consistency, style, voice, the quality of how the sentences are written, and identifying plot holes. How good is the story overall? What specific plot points can be improved? Are the characters well-written? Is there enough build-up before the climax? Comparing this to software testing, I believe that the same thing applies. Testing beyond what the requirement tells you, beyond what you see in plain sight is where the real value of a QA stands. However, from time to time you'll see companies or hear some people undermine the value of QA. Some even think you don't need any skills to do this. It's like they're saying you can pick up any random p...

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...

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 ...

You'll be surprised to know how broad the testing industry is. Of course, we can break it down into manual and automation testers/test engineers. But there are also different types of test classifications such as functional testing, regression testing, performance testing, accessibility testing, localization testing, etc. For automation you have a lot of frameworks and approaches you can explore as well. Fail to plan and you plan to fail We don't test all the time, or at least literally. For a successful test to happen, we should have a good test plan, design, and process in place to ensure everything will run smoothly when we do that actual testing work (which is the test execution phase). Examples: Test Plan and Strategy. This is an important process especially when you're testing a project for the first time. It gives you a space to think about what and how to test the product overall. Some topics covered are testing timeline, testing type and approaches, defect manageme...

When I was still in college taking up my Information Technology course, our curriculum is mostly centered on programming. We didn't really have a major back but most of the major subjects are about learning C, Java, HTML, CSS, Javascript, Python, game development, mobile development, etc. So yeah, as a student the only career track that I know about this field is being a software developer. No one enrolls in an IT course and says "I want to be a software tester when I graduate!". I don't even know that such a career exists. For this post, I'm just going to share high-level detail about what we do in software testing. In a nutshell, software testing is like being in a courtroom I get this mental image in my head sometimes whenever I do my work so I'll just share this. Forgive me for my poor analogy because I'm not familiar with terms in the court.  Imagine that you're in a court room where the software is the defendant and the testers are the prosecutio...