Product Testing Vs Project Testing

Before we dive into differences of software Product Testing Vs Project Testing, it is essential to define the context that defines what software product and software project is.

A software Product can be a single software project or set of software projects owned by individual(s) or organization(s). Also, these software project(s) can be developed and tested individually or outsourced to different companies and finally integrated to work with each other to deliver end Product. So the real difference is the scope of testing and requirements.

Software Product Testing Testing is performed for your/organization's own product

Software Project Testing Testing is performed for individual project from a client or different functional groups in same organization.

Market requirements influence Clients or different functional the overall testing groups that drive requirements influence the overall testing Test Cases are reviewed internal to the organization Test Cases should be also reviewed by Client or different functional groups as well.

Product testing encompasses Project testing is very specific testing results of all individual to the software project under software testing projects test. Product testing will be Since every project has its end continuous activity if features date, software testing project are being added into a product also has its definite end date. over different releases.

As an end tester, there will not be much difference in testing either a product or a project. It is test scenarios and test cases, and requirements everywhere. However, here below are some differences between a product and a project, and differences from a testing perspective: 1. For a project, test plan is a must. All the documents related to that are to be prepared. For a product, test plan would have been made long time back. It is at max updated. 2. In project, client has to approve the test plan and test cases, and sign them off. In product it is not necessary. 3. In project, tester directly interacts with the client. In a product, tester interacts with the business

analysts. 4. In project, the dead lines are not flexible. In product testing, dead lines are flexible. 5. In project client hold the authority on the developed code. In product, client doesn't hold the ultimate authority on the code. 6. The budget for development of the project is given by the customer in case of project development. In case of product, the budget is given by the own company. 7. The features in a project are always new. However, in Product, the basic features remain same, and only a few new features will be added, or few existing features will be modified. 8. Because of point #6, more regression testing needs to be done in case of a product, and less in case of a project. 9. Since a product runs for years, test automation saves lot of effort, where as in case of projects, it depends on the duration of the project. 10. Usually, a project complies to a small environment, as specified by the client. So, testing only on the specified environment is sufficient. A product can be installed on a number of OS and other environment parameters, depending on the end user. So, usually, more compatibility testing needs to be done in case of product. 11. A project is used by the specific client for the specific purpose only. Hence tester needs to test only in that end users perspective. In case of a product, the same product can be used by a variety of clients. (For example, the same Enterprise Incentive Management application can be used by Pharma clients, Insurance clients etc). So, tester needs to consider all types of potential users and their usage and needs to test accordingly. 12. Licensing comes into picture in case of a product. Thus scenarios related types of license, their registration and expiry etc needs to be tested for a product. Licensing does not exist for a project. 13. Test planning depends on the software development life cycle. Usually, it will be different for a project and a product. 14. Chances are very high to get onsite opportunities for the tester working in a project. Changes are very less in case of a tester working on a product. 15. Economic recession badly hits a software project. The customer may halt or stop the project, in which case, the test engineer may lose the job sometimes. In case of a product, a short term (0-1year) recession may not hit the engineer, as the company keeps adding the new requirements. In fact, the test engineer may get more work, if the company tries to add some innovative requirements to lure the customers into buying their product. 16. In case of a project, competitors do not come into picture, except at the senior level management. In case of a product, the tester also should consider the competitive products while testing. Sometimes, the tester needs to evaluate the performance against competitors' products. Behavior of the product with the competitors' products coexisting on the same machine needs to be considered. Also, tester needs to check any violation the copyrights. -----------------------------------------------------------------------------------------------------------------------------------------

Application is more specific for a particular business requirement whereas product is more generic. In other words, application is used for solving a particular problem or solution for a specific need, whereas product development takes a broader perspective often larger. For e.g. Requirement Phase: When you build an application you look at particular user/client and understand their requirements. But for building a product the requirements are gathered not by looking at a single user but one does market survey and come up with most likely features that cross section of users will look at. These requirements are not only functional requirements but also platform/hardware requirements. Typically product offers set of features then it's up to the organizations to use some or all of them (MSExcel for e.g.). In some cases Product don't have all the required features, in such case it is customized to suite the need, in such case this implementation/customized version of product can be considered as application. Testing: Typically application is supported on single platform, the one that target organization has. For products it's variety of OS, hardware etc, you must have see typically product matrix. Hence it is necessary to test the product on all the combinations. Though it is not completely true but in most cases, once application is developed there are few enhancements. Also bug fixes are typically completed before User Acceptance testing. Since for product there is not a single customer, there is no UAT as such, once QA certifies product is released to market. Very fact that product is generic and is suppose to work in different scenarios it's very difficult to exhaust all the scenarios during QA testing, and as you know the defects are found in released product. The bug fixes for these are handled by patch releases (Microsoft is very good example for these patch releases, you must have seen SP1, SP2 etc even for OS). ----------------------------------------------------------------------------------------------------------------------------------If you are testing a product you wouldnt exactly know who might end up using your product so you should be cover a wide array of environments where as in application testing ie in most of the companies the environment is already known and you limit ur testing to that environment alone. -----------------------------------------------------------------------------------------------------------------------------------A project is usually an encompassing aspect that includes a product as an end result. If you like objectoriented concepts, think of the project as the overall class that is instantiated to create specific objects (products). (By this logic, products is also a class that is instantiated with a given project.) Generally speaking, a software project will be driven by such things as a lifecycle methodology and consist of a set of organizational processes that suggest good product development processes (as part of the methodology). A product will then be a consequence of that lifecycle. So, finally, to your point: testing a product is more testing the elements that go into a Product Development Process. There is, for example, the act of testing the finished product itself (meaning a

compiled bunch of source code or a completed Web application). There is also testing various elements of the process that go towards making that specific product: the design documents, requirements specifications, use cases, etc. Testing the project, per se, is more testing in the sense of looking at how estimation and scheduling is done. Or perhaps looking at how risk assessment, root-cause analysis, or impact estimation is done. These are "tested" at the project level because, usually, you use the same techniques for each project to filter down to the product. A few caveats: 1.) If you practice methodology engineering in your company or employ a specific process diversity paradigm, then the distinction between product and project can become a little blurred. 2.) If you do not have a broad definition of the term "testing" then some of what I said may not make sense to. Testing should not just be thought of as part of the reactive elements of a finished (or incremental) product but also as part of the proactive elements that go into the procedures by which a product is created.

The V Model

V-MODEL

The V proceeds from left to right, depicting the basic sequence of development and testing activities. The model is valuable because it highlights the existence of several levels of testing and depicts the way each relates to a different development phase. Unit testing is code-based and [click for larger image] performed primarily by developers to The V proceeds from left to right, demonstrate that their smallest pieces of depicting the basic sequence of executable code function suitably. development and testing activities. Integration testing demonstrates that two or The model is valuable because it more units or other integrations work highlights the existence of several together properly, and tends to focus on the levels of testing and depicts the way interfaces specified in low-level design. each relates to a different development phase. When all the units and their various integrations have been tested, system testing demonstrates that the system works end-to-end in a production-like environment to provide the business functions specified in the high-level design. Finally, when the technical organization has completed these tests, the business or users perform acceptance testing to confirm that the system does, in fact, meet their business requirements.

Although many people dismiss the V Model, few have done so with the careful consideration that Brian Marick, author of The Craft of Software Testing (Prentice Hall, 1995), has demonstrated. In a debate with Dorothy Graham at the STAR (Software Testing Analysis and Review) 2000 East Conference and on his Web site (www.testing.com), Marick argued against the V Model's relevance.

The Testing process and the Software Testing Life Cycle

Every testing project has to follow the waterfall model of the testing process. The waterfall model is as given below 1.Test Strategy & Planning 2.Test Design 3.Test Environment setup 4.Test Execution 5.Defect Analysis & Tracking 6.Final Reporting

Broad Categories of Testing

Based on the V-Model mentioned above, we see that there are two categories of testing activities that can be done on software, namely, Static Testing Dynamic Testing The kind of verification we do on the software work products before the process of compilation and creation of an executable is more of Requirement review, design review, code review, walkthrough and audits. This type of testing is called Static Testing. When we test the software by executing and comparing the actual & expected results, it is called Dynamic Testing

Widely employed Types of Testing

From the V-model, we see that are various levels or phases of testing, namely, Unit testing, Integration testing, System testing, User Acceptance testing etc. Let us see a brief definition on the widely employed types of testing. Unit Testing: The testing done to a unit or to a smallest piece of software. Done to verify if it satisfies its functional specification or its intended design structure. Integration Testing: Testing which takes place as sub elements are combined (i.e., integrated) to form higher-level elements Regression Testing: Selective re-testing of a system to verify the modification (bug fixes) have not caused unintended effects and that system still complies with its specified requirements

System Testing: Testing the software for the required specifications on the intended hardware Acceptance Testing: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria, which enables a customer to determine whether to accept the system or not. Performance Testing: To evaluate the time taken or response time of the system to perform its required functions in comparison Stress Testing: To evaluate a system beyond the limits of the specified requirements or system resources (such as disk space, memory, processor utilization) to ensure the system do not break unexpectedly Load Testing: Load Testing, a subset of stress testing, verifies that a web site can handle a particular number of concurrent users while maintaining acceptable response times Alpha Testing: Testing of a software product or system conducted at the developers site by the customer Beta Testing: Testing conducted at one or more customer sites by the end user of a delivered software product system.

The Testing Techniques

To perform these types of testing, there are two widely used testing techniques. The above said testing types are performed based on the following testing techniques. Black-Box testing technique: This technique is used for testing based solely on analysis of requirements (specification, user documentation.). Also known as functional testing. White-Box testing technique: This technique us used for testing based on analysis of internal logic (design, code, etc.)(But expected results still come requirements). Also known as Structural testing

Black-box Testing (Without user involvement): - Functionality testing - Volume tests - Stress tests - Recovery testing - Benchmarks