Background: This is important in general for any testing but I think this is particularly more important in agile when a critical feature is on the line which needs to be released early for various business reasons. Coming up with important bugs early in the test process is then a vital and very practical approach to add value as a tester in the team.

As a professional tester what approach/techniques do you personally keep in your arsenal

to find important(business critical) bugs faster and early in the testing?

Note: Please answer this NOT based on opinion but based on facts per your actual experience working as a tester in actual projects in agile.

Basically please mention what actually worked for you!


5 Answers 5


Find Bugs Faster and Earlier:

All of the following have worked well for me in several companies:

Before test code or automation is even written:

  • Use well thought out test data strategies to ensure reliable repeatability for manual testing

  • Use extensive linting in application code to prevent likely bug situations in the first place

  • Have quality application code practices in place so that easily avoidable bugs are avoided

  • Use persona testing to reflect real world cases and scenarios and workflows from an actual users perspective

  • Talk through the test cases during backlog refinement and when initially preparing to work on the feature to ensure that tests, workflows and testable code are first class citizens

Once application code is being written:

  • Shift testing "left", i.e. more unit and less end-to-end

  • Make sure unit tests actually mock the database and network

  • Use Automation to run thousands of tests repeatedly and quickly

  • Use parallelization to run tests on multiple machines more quickly

  • Maintain high test coverage so regressions are spotted quickly and early during development

  • Use the test pyramid as a guide and focus on unit testing with mocked and stubbed dependencies

  • Use CI/CD practices to ensure tests are run consistently and code merging depends on them passing

  • Test at multiple levels (unit / integration / e2e ) to ensure bugs have a good chance of being caught early

  • Thank you Michael. Although I believe all of the above are very good test practices in general but I think they don't directly relate to the question as mainly focused on automation. The very first cycle of testing is always manual as automation takes time however once its done , it saves lot of time in each successive test cycle. Dec 29, 2022 at 11:16
  • @VishalAggarwal good point. I've updated the list and divided it into non-automation-code and automation-code sections. Dec 29, 2022 at 12:10
  • 1
    It is important to note that there are two distinct situations to cover - running tests against existing code to make sure it isn't broken by the new feature. This form of extensive regression testing of the existing code base is best done thru automation. The second situation - testing of new features - can be done manually in a more manageable fashion (but of course manual testing only makes sure it works 'today' and over time it will become impractical to test all the cases manually (due to the time it takes) and choices have to be made. Dec 29, 2022 at 12:16
  • Thanks Michael. A very good point! Dec 29, 2022 at 12:50

Direct answer: The best tool I've used is strong familiarity and long experience with the product and its technology stack. Over time (meaning months, or years -- not days or weeks) you develop a kind of "acquaintance" with the product. You learn the areas where things break most often, when features are modified or added. This then leads you to the test cases you need to run first to catch any bugs in those areas.

Indirect answer: (i.e. now I'm questioning the question): Bug prevention is always, always better than bug detection, no matter how quickly or how early the test team catches those bugs. So also -- over time -- as you discover the areas of the product most prone to trouble, you should engage with the developers to see about re-architecting those areas to prevent the bugs you so quickly found.

  • Thank you however I disagree as finding defects faster based on "strong familiarity and long experience" does not make one effective tester. A effective tester should be able to find defects faster in relatively new application as well based on his testing skills alone using the right approach and techniques. Dec 29, 2022 at 11:40
  • The "right approach and techniques" will be radically different based on what is being tested -- and only experience (gained individually or shared through mentoring) can provide that insight. Consider the differences between testing a mass marketed game app for an Android phone, or testing an enterprise software system used by a large business to manage its accounting needs, or testing the embedded software used by a driverless vehicle. No tester, no matter how skilled, can immediately know the right approach and techniques for all those different kinds of systems.
    – JDM
    Dec 29, 2022 at 12:28

This is what kind of helped me in finding important bugs faster:

  • Understanding the "crux" of the feature usage from user perspective from user story/ exploratory testing
  • Modelling an diagram of the feature(end to end) highlighting key interaction points
  • Visually creating an data flow path
  • Identifying different states the feature can get in to and all possible different ways to reach them through UI/Backend
  • Ultimately convert all my understanding in to decision table format matrix to form specific test scenarios

And, and and questioning all along to solidify my understanding - asking the right questions to the right people in the right context.

enter image description here

  • 1
    All good ideas with a broad application to most any kind of software or system. The emphasis on the end user (as per the 1st bullet) is especially helpful, as it will reveal the bugs most noticeable to the end users.
    – JDM
    Dec 29, 2022 at 12:37

To create risk matrix while test an idea-documentation. Then make a list "how to avoid these possible bugs" or "accept a risk". In addition add columnn "How much that acception costs?" for accepted risks. Fill the column for every risk.

quality-oriented process works for me.


It seems you are asking about advice for testing approach with feature testing on one project, not set of unknown projects. I have an assumption, that testers should have some experience with this project.

Short answer:

Really strong knowledge and huge experience with the project and its tech stack.

Long answer:

You should have right processes for all aspects of your project under the testing to have possibility to do quick and effective testing:

  1. Products provide clear AC(Acceptance Criteria).
  2. Developers implement this feature and cover them with Unit tests.
  3. DevOps provided proper pipelines to build and deploy this feature on testing envs.
  4. Start testing and test case creation ASAP as you get AC(before real implementation).
  5. Flexible and stable testing environment, that allows testers to focus on testing only, not infrastructure or environments troubleshooting.
  6. We can't find all bugs in short period of time, but we should find all blockers and critical bugs to fix them before actual release. I would focus on Critical path testing.

This type of testing focuses on functionality used by typical users in their daily activities. The idea itself is borrowed from project management and transformed in the context of testing: most users mostly use some subset of application features. These features need to be tested once we have ensured that the application works in principle (the smoke test was successful).

  • 1
    please share any feedback if you vote down. Dec 29, 2022 at 17:29
  • I think knowing an application deeply by using it over a long period of time does not equate effective testing skills. Jan 4, 2023 at 1:51
  • 1
    Possibly I used the not right words for it. My main idea was about experience with tech stack and domain area of application under testing (is it just simple web site or some mobile app, or maybe something from AdTech ). Each of those areas has each own terminology, specifications and details. I ddin't have such cases in my working experience, that people without those key knowledge could find important bugs faster and early in test process. They definitely will find something, but it will take more time. Jan 4, 2023 at 16:11
  • 2
    Knowing what the application is meant to do is important. Imagine testing a car's brake software without knowing about ice and snow. Imagine testing a statistics application without knowing statistics. How effective are your tests going to be?
    – C'est Moi
    Jan 5, 2023 at 12:07
  • 1
    @VishalAggarwal, you didn't ask "What are effective testing skills?" You asked "How can the most significant bugs be found quickly?" A deep knowledge of the application from long experience is a valid answer to that question, as my own experience has affirmed.
    – JDM
    Jan 11, 2023 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.