Discuss software testing

Validation can be a manual or automation. It usually employs various types of testing techniques, i. Generally, testers perform validation, whereas customers can also validate the product as part of User acceptance testing.

Every business considers the customer as the king. Thus the customer's satisfaction is a predominant need for any business. For example, customer satisfaction and loyalty in online shopping and e-commerce environments is a useful indicator for long-term business success.

One of the critical objectives of software testing is to improve software quality. High-Quality software means a lesser number of defects. In other words, the more efficient the testing process is, the fewer errors you will get in the end product. Which, in turn, will increase the overall quality of the test object. Excellent quality contributes to a significant increase in customer satisfaction as well as lower maintenance costs. One of the objectives of software testing is to avoid the mistakes in the early stage of the development.

Early detection of errors significantly reduces the cost and effort. The prevention of defects involves doing a root cause analysis of the defects found previously and after that, taking specific measures to prevent the occurrence of those types of errors in the future. Efficient testing helps in providing an error-free application. If you prevent defects, it will result in reducing the overall defect count in the product, which further ensures a high-quality product to the customer.

Another essential objective of software testing is to identify all defects in a product. The main motto of testing is to find maximum defects in a software product while validating whether the program is working as per the user requirements or not. Defects should be identified as early in the test cycle as possible. The purpose of testing is to provide complete information to the stakeholders about technical or other restrictions, risk factors, ambiguous requirements, etc.

It can be in the form of test coverage, testing reports covering details like what is missing, what went wrong. In their own way, everyone is testing all the time. As they should. Agile or Waterfall, Scrum or RUP, traditional or exploratory, there is a fundamental process to software testing.

Every project needs a Test Strategy and a Test Plan. These artefacts describe the scope for testing for a project:. And so on… Whatever methodology your project follows, you need to have a Test Strategy and Software Testing Plan in place. Make them two separate documents, or merge them into one. Without a clear test strategy and a detailed test plan, even Agile projects will find it difficult to be productive.

Why, you ask? Well, the act of creating a strategy and plan bring out a number of dependencies that you may not think of otherwise. Usually, a functioning organisation will have nailed their device and OS support strategy, and review it quarterly to keep up with the market; test managers creating a strategy or plan for their project will help validate the enterprise-wide strategy against project-specific deliverables.

Among other things, the test plan also helps define entry and exit criteria for testing. This is important as a control for the rest of the team. Testing performs this all-important gatekeeping function, and helps bring visibility to any issues that may be brushed under the carpet otherwise.

Now that you have a strategy and a plan, the next step is to dive into creating a test suite. A test suite is a collection of test cases that are necessary to validate the system being built, against its original requirements. And you probably have investors backing you, or another product of your own that is subsidising this new initiative until it can break even. In such a scenario, you may use lesser negative testing and more exploratory or disruptive testing to weed out complex, critical bugs.

And you may want to leave out the more rigorous testing to until you have a viable product in hand. You then review the core test suite against individual project requirements to identify any gaps that need additional test cases. With good case management practices , you can build a test bank of the highest quality that helps your team significantly reduce planning and design efforts.

Ultimately, you need to do adequate amount of software testing to ensure your system is relatively bug-free. You need to understand your test environment requirements clearly to be able to decide your testing strategy.

For instance, does your app depend on integration with a core system back end to display information and notifications to customers? If yes, your test environment needs to provide back end integration to support meaningful functional tests.

Can you commission such an end-to-end environment to be built and ready for your sprints to begin? Depending on how your IT organisation is set up, maybe not. This is where the question of agile vs a more flexible approach comes into picture. Could you have foreseen this necessity way before the sprints began? Probably not. If not, then your test strategy will be different.

It is common practice to schedule integration tests just after delivery sprints and before release. Your team can then run a dedicated System Integration Test, focusing on how the app components work with the back end to deliver the required functionality. So while app-specific bugs will primarily be reported during the sprints, functional end-to-end bugs will crop up during the integration test.

You can follow this up with a UAT cycle to put finishing touches in terms of look and feel, copy, etc. How your team execute test cycles depends on the enabling infrastructure, project and team structure in your organisation. Reviewing test environment requirements early on is now a widely recognised cornerstone for good project management. Leaders are giving permanent, duplicate test environments a good deal of thought as an enabler for delivery at pace.

Right—so you have done the planning necessary, executed tests and now want to green-light your product for release. You need to consider the exit criteria for signalling completion of the test cycle and readiness for a release. Ultimately, what works for your team is down to your circumstances and business demands.

Remember that nobody can afford serious defects to remain unfixed when you launch to customers—especially if your product handles sensitive information or financials. This chapter briefly describes the methods available. The technique of testing without having any knowledge of the interior workings of the application is called black-box testing. The tester is oblivious to the system architecture and does not have access to the source code. Typically, while performing a black-box test, a tester will interact with the system's user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.

White-box testing is the detailed investigation of internal logic and structure of the code. White-box testing is also called glass testing or open-box testing. In order to perform white-box testing on an application, a tester needs to know the internal workings of the code.

Grey-box testing is a technique to test the application with having a limited knowledge of the internal workings of an application. In software testing, the phrase the more you know, the better carries a lot of weight while testing an application.

Mastering the domain of a system always gives the tester an edge over someone with limited domain knowledge. Unlike black-box testing, where the tester only tests the application's user interface; in grey-box testing, the tester has access to design documents and the database.

Having this knowledge, a tester can prepare better test data and test scenarios while making a test plan. The following table lists the points that differentiate black-box testing, grey-box testing, and white-box testing.