Software Testing is perhaps the least-understood and most critical component of the Software Development process in the Software Development Life Cycle (SDLC) with roughly 40-45% cost associated with it. This article explores the importance of a Testing Engineer towards completion of any successful software project and throws some light on the hurdles that a Testing Engineer encounters and summarizes effective solutions for the same.
Testing presents a very interesting anomaly for the developers and testers. During scoping and development phase, developer tries to build a software application from the some what abstract requirement specification (RS document). Now next comes Testing. A well experience Testing engineer creates a series of Test Cases with the intention to "knock down" the software that has been built by developers with lots of efforts. So at this moment, you may feel, the role of testing is a destructive and your role as a tester in the development team as a villain. Is it a wrong profession? The answer is absolutely No!. However the aim of testing is somewhat that we might expect.
Objectives of Testing: The main aim of testing is to execute some test cases, manually or through automation with the aim of finding the unknown errors/bugs in the given software application. So many times, I have observed, testers calling a particular Test Case as good test case which always passes. Is it right? No! a good Test Case is the one which has a very high probability to fail. Let me give a example of my previous project. It was a GUI application. If the user clicks on Submit button in the given form, a new page was presented to the user with the modified URL at the address header of the browser window. Everything looks absolutely fine. But if you cut and paste the modified URL to the new browser window and press Enter key, this fails to bring the same page. According to me this is a good test case which we simply don’t think. Hence, the design of a Test Case should be such that so it can uncover the unknown errors. That’s why I always give lots of importance to the testers as they think Out of Box. The intention of testing is not to show that the given application is free of bugs. But to say that defects are present in the application, so better fix them before you ship the application to the client. Please note down that if the bugs have slipped in the testing phase and discovered either by the end users or client. The cost to fix them during the maintenance phase is 50-100 times of the cost fixed during the development phase.
Test Case designing criteria: As you know that the main objective of designing test case is to uncover the serious, unknown bugs in the given software application. To achieve this goal you can take white box and Black box testing approaches.
White Box Testing White box testing is a methodology to design the test cases that uses the control structure of the application to design test cases. Using white box approach, you can write the test cases that make sure that all the independent paths of a given module have been at least executed once. It also checks all the Boolean conditions, boundary conditions and validate internal data structures.
Black Box Testing: Black box testing approach helps in designing test cases which focus on the functional requirements of the given software. Hence this approach helps you to design a set of input values that will completely tests all the functional requirements of the application. It is important for you to understand that Black Box testing is not an alternative approach of White Box testing or vise versa. Rather it is a complementary approach that help in discovering a different type of bugs that can not be found by white box testing. Black box testing finds the incorrect or missing methods (functions), interface related errors, I/O