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 related errors, performance related issues, memory leaks issues, initialization and termination errors.

By now, you will be clear that white box testing is performed early in the testing process, i.e during Unit Testing phase ( by the developers on their modules) while the Black box testing is done to a complete application by the external testing team.

Discussion with my experience:
As I have already discussed that a good developer’s aim is to develop the robust code and the goal of a software tester is to break this robust code by finding bugs, and find them as early as possible, and make sure they get fixed. At first glance it may appear that a software engineer’s job would be easier than a software developer. Breaking code and finding bugs must surely be easier than writing the code in the first place. Surprisingly, it's not. The methodical and disciplined approach to software testing requires the same hard work and dedication that programming does. I remember my discussion with one of the senior Professor at IIIT Bangalore, for the development and testing team contributions towards completing a software project. He says that the role of the testing team is as important as a mother who cares a baby for nearly nine months before the baby see this beautiful world.

I am sure that you will agree with my experience of working towards completing a software product as a Developer or a Testing Engineer. Once the Software product is delivered to the client after proper testing with the efforts of so many sleepless nights. And now, We expect the praising words from the client in the next email. Contrary to that, get a big list of the bugs reported by the end users in the application code. It forced me to think that when these bugs were introduced in the code? As a quality person, a question always disturbed me "How did those bugs slipped from testing phase?"

Let us assume that the final application contains bugs. The source of these bugs could be any of the following

• By chance, the end user executed the portion of the software, which was never given to the Testing Team to test.
• The testing engineer was just a fresher and was governed by the instructions from the developers for testing the functionality of the code and did not checked the input values with those boundary values which the end user has checked.
• And the most frequently error is the mismatch in development and the end user testing environment. I have observed that the client environment was not kept in consideration while testing the application at offshore.
• The bugs reported by testing team were not monitored/ tracked properly. What I mean here that once you send all the bugs reported by you to the development team and they missed any of them and took the next built of the application to test. At this point I have always found that once the developer says that he has closed the status of the bug (means fixed the problem), we go with the developers word and did not test the application for the same error. Also maintaining the XL Sheet or any mode of bug report is difficult to maintain.

As a testing engineer you should consider all of the above points while testing any software application. If you want that the application should be robust and bug free, this difficult and time consuming process requires Technical knowledge and proper planning too. Good co-ordination between developers and testers plays a key role behind any successful project. Testers must have good technical knowledge so they can take part in the development-related discussions. Mostly, I found that a Testing Engineer is a Developer plus many more. While a particular developer concentrate towards only one module (some part) of the application, on the other hand, a Tester knows overall functionality of the application. It is his/her skill to test the application from all angles, keeping end users in the mind. Let me take my example, I moved in the field of testing after having good development and teaching experience. In starting, I observed many times that there is a big gap between testing and the development team. Development team and the testing teams will not take part in each others meetings where they discuss the issues and the planning. The developer team thinks that the testers do not have the technical knowledge so it is simply wastage of time to have discussing any technical issue with the testing team. Do you think that the development team is right? I say, Yes if the Testing team does not have the technical knowledge and say No if the Testing Engineers are having a sound technical knowledge. As my background is J2EE, I was teaching this subject from couple of years. Before testing any J2EE application, first I see the code without knowing the functionality of the application. It helps me in understanding the logic of the code. At this level when the suggestions are given to the developers, they start appreciating my views and the gap between the development and the testing team starts narrowing down and finally we, together are ready to deliver the robust code to the client. So you, as the testing engineer, should understand the application well and have an out of box thinking during testing the application.

Let me discuss a generic Software Testing Life Cycle (STLC) which runs parallel with the Development Life Cycle (SDLC). In a common scenario, testing of any large application can be divided in two portions: (1) The Functionality portion, which is nothing but verification and validation against the Requirement Specification (RS) and the other (2) Performance evaluation against the client requirements.

Sometimes, I have seen that most of the people underestimate the testing activity and feels that it is required only at the end of the development life cycle. It is a wrong notion. Testing activity runs parallel to the development. When the development phase of application is in the Requirement Phase, STLC says that it is the right time for you to create and finalize the testing templates, Test Plan, Test Strategy, Performance Criteria of the application (if any given by client). Now when the development of an application moves to Design Phase, being a testing person, ensure that you develop the Test Cases to ensure that product which will be developed can be tested as per the RS Document (requirement Specification ). It is important to know that the main aim of the test case designing is to find the undiscovered errors in the application. Mostly we take two approaches in the mind for designing good test cases (a) Black box testing and (b) White box testing. Black box testing means that it is not important for you to know the internals of the code. Here you are checking the functionality checking like if you give any input, it is properly accepted and you receive the output. For example, if I click the submit button for registering myself for a particular forum, I get the proper acknowledgement page in return. On the other hand White box testing needs a good knowledge of the code and hence mostly the unit test cases are written and verified by the development team. The aim of both type of testing is to uncover faults/bugs in the given application. It is always good if you get an opportunity to have a peer review from the senior developer team members like PM or the Module lead. Also it is the high time when you can trace your System Test Cases with the RS Document, what we call the traceability matrix, which helps you in covering full functionality of application during testing.

Now once the coding is ready, developers goes for the Unit level testing and then we as a Testing experts start the System testing phase which is nothing but validating the application against the Client requirement. Once you find the bugs in this cycle please ensure that you are logging these bugs in the defect tracking system, which can be seen by the development team and they can fix the bugs. Here you can use, defect tracking tools, some are freely available. I always found that the use of defect tracking tool helps you in tracking the status of a given bug and save lots of time. Later you move to the Integration testing followed by Performance Testing. During the functional testing if your budget allows you to get the automation tools you can go for the tools like Robot or Winrunner for automating your functional testing. If you are developing a web application like online banking, Online shopping etc, the performance studies of the application is very important. It is also important for you to know the threshold point, break point of the application. For performance or the Load testing you can use the tools like Load Runner or Virtual User functionality of the Robot again.

Today, most grown-up companies treat software testing as a technical engineering profession. They recognize that having trained software testers on their project teams and allowing them to apply their skill early in the development process allows them to build better quality software helps in saving lots of money and efforts.

Conclusion:
Finally, I summarize my this article by writing that the carrier in the software testing is challenging, critical and needs a good out of box thinking. Expertise and understanding of the testing tools like, Robot, Purify, Winrunner, Loadrunner will help you in saving time and important resources in the testing phase. With the size and complexity of today's software, it is essential that you should do testing professionally and effectively. To be an effective software tester, it's important to have at least a high-level programming language knowledge, understanding of the overall development life cycle process used to develop a software product.