Black-box testing is a method of software testing where the internal workings of the system are not known to the tester. Instead, the tester focuses solely on inputs and expected outputs, treating the software as a "black box." The goal is to validate whether the software behaves correctly for different user inputs, without concern for how the system achieves the results. This method is ideal for functional testing, user acceptance testing, and system-level validation. In contrast, white-box testing involves examining the internal code, logic, and structure of the software. Testers have full access to the source code and design documents, allowing them to create test cases that target specific execution paths, conditions, or loops. While black-box testing ensures that the software meets user expectations, white-box testing ensures that all internal logic is correctly implemented. Using both approaches together provides more comprehensive coverage and strengthens overall software quality.

Retesting after fixing a bug is essential because changes to the code can introduce new issues or have unintended consequences on previously working features. This is where regression testing becomes critical. Regression testing involves re-running previous test cases to ensure that the bug fix hasn’t broken any other part of the system. When a section of code is altered, it may affect dependencies or interact differently with other modules, especially in large or complex systems. Even a minor change in one function might impact others that rely on it. Automated regression tests are often used to save time and maintain consistency across multiple iterations. These tests help maintain system stability over time, ensure that functionality is preserved, and provide confidence that the application still meets its original specifications. Without regression testing, new bugs can silently enter the system, leading to unreliable or unpredictable software behaviour after deployment.

Automated testing significantly enhances the efficiency and reliability of the software development process. It involves writing scripts or using tools to run predefined test cases without human intervention. This approach allows tests to be executed quickly and repeatedly, especially during iterative development where frequent changes are made. One major advantage is consistency—tests are run the same way every time, reducing the chance of human error. Automated testing is particularly useful for regression testing, load testing, and repetitive validation tasks. It also provides rapid feedback to developers, helping identify bugs early when they are easier and cheaper to fix. Although there is an initial time investment in setting up automated tests, it pays off over time by speeding up the development cycle, increasing test coverage, and enabling continuous integration and delivery practices. Moreover, it allows teams to confidently make changes to the codebase, knowing that any issues will be flagged immediately by automated systems.

Test coverage is a metric that indicates how much of the software's source code has been tested by a given set of tests. It helps assess the thoroughness of the testing process and identifies parts of the codebase that may still be untested. High test coverage is generally desirable, as it reduces the risk of undetected bugs. Coverage can be measured using various criteria, such as:

• Statement coverage: Checks whether each line of code has been executed.

• Branch coverage: Verifies that each possible path in control structures (like if-else statements) has been tested.

• Function coverage: Measures whether each function or method has been called.

• Condition coverage: Tests whether each boolean expression in decision-making structures has evaluated both true and false.

Tools like JaCoCo (Java), Istanbul (JavaScript), or Coverage.py (Python) help calculate test coverage automatically. However, high coverage alone doesn’t guarantee quality—tests must also be well-designed to check for correctness and edge cases.

Exploratory testing is an informal, unscripted approach where testers actively explore the software to find defects, often relying on their own intuition and experience. Unlike scripted testing—where predefined test cases are followed step-by-step—exploratory testing allows testers to learn about the system while interacting with it. This style encourages flexibility, creativity, and real-time decision-making based on the tester’s observations. It is particularly effective for uncovering unexpected behaviours, usability issues, and edge cases that may not have been considered during test case design. Exploratory testing is most useful in the early stages of development, in complex systems with dynamic behaviour, or when time is limited and full scripting isn’t practical. It also plays an important role when verifying changes from bug fixes or last-minute modifications. While it’s less structured and harder to reproduce, exploratory testing complements formal methods by uncovering issues that automated or scripted tests might miss, especially those related to user experience and interface inconsistencies.