Let's explore the dichotomies in software testing to find the correct balance between two contrasting concepts to make your testing process effective.
Software testing is a discipline that involves various types of tests, approaches, techniques, and tools. Within this field, we very often encounter dichotomies - which can lead to confusion when making decision.
Dichotomies are crucial for a QA as it broaden their thought process and helps them in taking an informed decision during the design of test strategy.
It is highly recommended by TestersPilot to understand the key dichotomies and implement them appropriately in your testing strategy.
In this blog post, we will delve into these dichotomies in software testing, understand their implications, and explore strategies to find a balance between them for effective testing.
Manual vs Automation Testing
One of the most common dichotomies in software testing is manual vs automation testing.
In manual testing, human execute the test cases and verify the expected result to make the test pass or fail. Example: A QA engineer manually filling out the login form to check positive and negative test scenarios. The QA engineer would verify the error message shown if provided user name and password is not correct and accordingly marks the test pass or fail.
On the other hand, Automated testing involves code or specialised tools to execute pre-defined test cases. Most of the automation tools generally, simulate the user interaction on the website. Most common automation tools are Selenium WebDriver, Cypress, Playwright etc.
Example: A QA engineer writes a piece of code in Java using Selenium Webdriver library. This piece of code opens the browser, fills the login form and verifies the error message.
Real Environments vs Simulated Environments
Testing in real environments, resembling production setups, provides an accurate assessment of the software's performance and behaviour under realistic conditions. A real environment setup is generally called as UAT or pre-production environment.
On the other hand, simulated environments offer controlled and reproducible testing conditions. It is generally built using mocks or stubs to replicate the behaviour of internal or external dependencies.
For an example, an e-commerce website can have real environment where the website is integrated with actual payment gateway server and can accept the payment using test cards provided by payment gateway company.
Simulated environment in this case would be an in-house system which is developed to mimic scenarios of payment gateway failures. This allows the testing team to ensure that their e-commerce website functions as expected even when there are failures from the payment gateway.
Validation vs Verification
Validation focuses on assessing whether the software meets the intended user needs and requirements. In simple terms, validation ensures that software is build as per the expectations of end user. It answers the question "are we building the right product?"
Verification, on the other hand, involves checking if the software or system meets the specified requirements to build the right product. It involves reviewing the documents, code, system design, test documents etc to ensure that software building process is right. The overall purpose of verification is answer "are we building the product right?"
Smoke vs Sanity
Smoke testing is quick check to make sure the software is ready for further in-depth testing and it does not have any critical defect.
Sanity Testing is performed to verify that the new changes introduced in the system are working as per plan. It is a subset of regression testing and performed only after smoke test passes.
Depth vs Breadth
Testing depth refers to a thorough examination of specific functionalities or components, ensuring their accuracy and robustness.
On the contrary, testing breadth involves assessing multiple functionalities or the entire system.
The testing done only on login page will measure the depth of the testing, however the different features covered in testing will measure the breadth of testing.
Testing vs Debugging
Testing is a process which is done to verify the software is working as per expectation and meets the specified requirement. The goal of testing is to uncover the issues and enhance the quality of software
Debugging is an activity which is done to fix a defect or issue which is identified in testing. Debugging can also be done to understand the behaviour of existing code. The goal of debugging can be identifying the root cause of an issue, or gaining the understanding of existing code.
Functional vs. Non-functional Testing
Functional testing focuses on verifying that the software meets its intended functionality, while non-functional testing assesses aspects like performance, usability, security, and compatibility.
If one needs to differentiate these two testing types by example, then filling out a login form and verifying the error message would come under functional testing. On the other hand, filling out the login form and submitting them by thousands of user at same time would and checking for login response time would come under non-functional testing.
Regression vs. Exploratory Testing
Regression testing involves retesting previously tested functionality to ensure that changes or additions to the software haven't introduced new issues.
Exploratory testing, on the other hand, emphasises informal approach and does not go through scripted test cases or scenarios. Instead, it explore the software from different angles to discover the issue which were not known before.
Conclusion
By considering above dichotomies, one can design a testing strategy that incorporates a mix of approaches, techniques, and considerations, ensuring a comprehensive and effective testing process for your software.
Comments