Software Testing Interview Questions

What is Installation / Uninstallation Testing?

An installation test assures that the system is installed correctly and working at actual customer's hardware.

What is Usability Testing?

Usability testing is needed to check if the user interface is easy to use and understand. It is concerned mainly with the use of the application. Long answer: Usability testing is a technique used in user-centered interaction design to evaluate a product by testing it on users. This can be seen as an irreplaceable usability practice, since it gives direct input on how real users use the system.[1] This is in contrast with usability inspection methods where experts use different methods to evaluate a user interface without involving users. Usability testing focuses on measuring a human-made product's capacity to meet its intended purpose. Examples of products that commonly benefit from usability testing are foods, consumer products, web sites or web applications, computer interfaces, documents, and devices. Usability testing measures the usability, or ease of use, of a specific object or set of objects, whereas general human-computer interaction studies attempt to formulate universal principles. Goals of usability testing Usability testing is a black-box testing technique. The aim is to observe people using the product to discover errors and areas of improvement. Usability testing generally involves measuring how well test subjects respond in four areas: efficiency, accuracy, recall, and emotional response. The results of the first test can be treated as a baseline or control measurement; all subsequent tests can then be compared to the baseline to indicate improvement. Efficiency -- How much time, and how many steps, are required for people to complete basic tasks? (For example, find something to buy, create a new account, and order the item.) Accuracy -- How many mistakes did people make? (And were they fatal or recoverable with the right information?) Recall -- How much does the person remember afterwards or after periods of non-use? Emotional response -- How does the person feel about the tasks completed? Is the person confident, stressed? Would the user recommend this system to a friend? To assess the usability of the system under usability testing, quantitative and/or qualitative Usability goals (also called usability requirements[6]) have to be defined beforehand.[7][6][8] If the results of the usability testing meet the Usability goals, the system can be considered as usable for the end-users whose representatives have tested it. What usability testing is not Simply gathering opinions on an object or document is market research or qualitative research rather than usability testing. Usability testing usually involves systematic observation under controlled conditions to determine how well people can use the product.[9] However, often both qualitative and usability testing are used in combination, to better understand users' motivations/perceptions, in addition to their actions. Rather than showing users a rough draft and asking, "Do you understand this?", usability testing involves watching people trying to use something for its intended purpose. For example, when testing instructions for assembling a toy, the test subjects should be given the instructions and a box of parts and, rather than being asked to comment on the parts and materials, they are asked to put the toy together. Instruction phrasing, illustration quality, and the toy's design all affect the assembly process. Methods Setting up a usability test involves carefully creating a scenario, or realistic situation, wherein the person performs a list of tasks using the product being tested while observers watch and take notes. Several other test instruments such as scripted instructions, paper prototypes, and pre- and post-test questionnaires are also used to gather feedback on the product being tested. For example, to test the attachment function of an e-mail program, a scenario would describe a situation where a person needs to send an e-mail attachment, and ask him or her to undertake this task. The aim is to observe how people function in a realistic manner, so that developers can see problem areas, and what people like. Techniques popularly used to gather data during a usability test include think aloud protocol, Co-discovery Learning and eye tracking. Hallway testing Hallway testing (or Hall Intercept Testing) is a general methodology of usability testing. Rather than using an in-house, trained group of testers, just five to six random people are brought in to test the product, or service. The name of the technique refers to the fact that the testers should be random people who pass by in the hallway.[10] Hallway testing is particularly effective in the early stages of a new design when the designers are looking for "brick walls," problems so serious that users simply cannot advance. Anyone of normal intelligence other than designers and engineers can be used at this point. (Both designers and engineers immediately turn from being test subjects into being "expert reviewers." They are often too close to the project, so they already know how to accomplish the task, thereby missing ambiguities and false paths.)

Load Testing

Load testing is primarily concerned with testing that the system can continue to operate under a specific load, whether that be large quantities of data or a large number of users. This is generally referred to as software scalability. The related load testing activity of when performed as a non-functional activity is often referred to as endurance testing. Load testing is the process of putting demand on a system or device and measuring its response. Load testing is performed to determine a system's behavior under both normal and anticipated peak load conditions. It helps to identify the maximum operating capacity of an application as well as any bottlenecks and determine which element is causing degradation. When the load placed on the system is raised beyond normal usage patterns, in order to test the system's response at unusually high or peak loads, it is known as stress testing. The load is usually so great that error conditions are the expected result, although no clear boundary exists when an activity ceases to be a load test and becomes a stress test. There is little agreement on what the specific goals of load testing are. The term is often used synonymously with concurrency testing, software performance testing, reliability testing, and volume testing. Load testing is a type of non-functional testing. Long answer: The term load testing is used in different ways in the professional software testing community. Load testing generally refers to the practice of modeling the expected usage of a software program by simulating multiple users accessing the program concurrently. As such, this testing is most relevant for multi-user systems; often one built using a client/server model, such as web servers. However, other types of software systems can also be load tested. For example, a word processor or graphics editor can be forced to read an extremely large document; or a financial package can be forced to generate a report based on several years' worth of data. The most accurate load testing simulates actual use, as opposed to testing using theoretical or analytical modeling. Load testing lets you measure your website's QOS performance based on actual customer behavior. Nearly all the load testing tools and frame-works follow the classical load testing paradigm, which is listed in Figure 1. When customers visit your web site, a script recorder records the communication and then creates related interaction scripts. A load generator tries to replay the recorded scripts, which could possibly be modified with different test parameters before replay. In the replay procedure, both the hardware and software statistics will be monitored and collected by the conductor, these statistics include the CPU, memory, disk IO of the physical servers and the response time, throughput of the System Under Test (short as SUT), etc. And at last, all these statistics will be analyzed and a load testing report will be generated. Load and performance testing analyzes software intended for a multi-user audience by subjecting the software to different amounts of virtual and live users while monitoring performance measurements under these different loads. Load and performance testing is usually conducted in a test environment identical to the production environment before the software system is permitted to go live. As an example, a web site with shopping cart capability is required to support 100 concurrent users broken out into following activities: 25 Virtual Users (VUsers) log in, browse through items and then log off 25 VUsers log in, add items to their shopping cart, check out and then log off 25 VUsers log in, return items previously purchased and then log off 25 VUsers just log in without any subsequent activity A test analyst can use various load testing tools to create these VUsers and their activities. Once the test has started and reached a steady state, the application is being tested at the 100 VUser load as described above. The application's performance can then be monitored and captured. The specifics of a load test plan or script will generally vary across organizations. For example, in the bulleted list above, the first item could represent 25 VUsers browsing unique items, random items, or a selected set of items depending upon the test plan or script developed. However, all load test plans attempt to simulate system performance across a range of anticipated peak workflows and volumes. The criteria for passing or failing a load test (pass/fail criteria) are generally different across organizations as well. There are no standards specifying acceptable load testing performance metrics. A common misconception is that load testing software provides record and playback capabilities like regression testing tools. Load testing tools analyze the entire OSI protocol stack whereas most regression testing tools focus on GUI performance. For example, a regression testing tool will record and playback a mouse click on a button on a web browser, but a load testing tool will send out hypertext the web browser sends after the user clicks the button. In a multiple-user environment, load testing tools can send out hypertext for multiple users with each user having a unique login ID, password, etc. The popular load testing tools available also provide insight into the causes for slow performance. There are numerous possible causes for slow system performance, including, but not limited to, the following: Application server(s) or software Database server(s) Network - latency, congestion, etc. Client-side processing Load balancing between multiple servers Load testing is especially important if the application, system or service will be subject to a service level agreement or SLA. User Experience Under Load test In the example above, while the device under test (DUT) is under production load - 100 VUsers, run the target application. The performance of the target application here would be the User Experience Under Load. It describes how fast or slow the DUT responds, and how satisfied or how the user actually perceives performance. Many performance testers are running this test, but they call it different names. This name was selected by the Panelists and many Performance Testers in 2011 Online Performance Summit by STP. There are already many tools and frameworks available to do the load testing from both commercial and open source.

What is Retesting?

- Retesting is testing the same functionality on same build with config changes or different build or version of the application with code changes or defect fixes. - Retesting is usually done to verify defect fixes.

How do you decide on the Defect Severity? Explain with examples.

...

Defect Leakage?

A memory leak, in computer science (or leakage, in this context), occurs when a computer program acquires memory but is unable to release it back to the operating system. In object-oriented programming, a memory leak happens when an object is stored in memory but cannot be accessed by the running code.[1] A memory leak has symptoms similar to a number of other problems (see below) and generally can only be diagnosed by a programmer with access to the program source code; however, people unaware of the relevant fundamentals of memory management commonly refer to any unwanted increase in memory usage as a memory leak, though this is not strictly accurate from a technical perspective. Because they can exhaust available system memory as an application runs, memory leaks are often the cause of or a contributing factor to software aging.

What is a Software Test Plan? What are the components of a Test Plan?

A test plan is a document detailing a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be. A test plan documents the strategy that will be used to verify and ensure that a product or system meets its design specifications and other requirements. A test plan is usually prepared by or with significant input from Test Engineers. Depending on the product and the responsibility of the organization to which the test plan applies, a test plan may include one or more of the following: - Design Verification or Compliance test - to be performed during the development or approval stages of the product, typically on a small sample of units. - Manufacturing or Production test - to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control. - Acceptance or Commissioning test - to be performed at the time of delivery or installation of the product. - Service and Repair test - to be performed as required over the service life of the product. - Regression test - to be performed on an existing operational product, to verify that existing functionality didn't get broken when other aspects of the environment are changed (e.g., upgrading the platform on which an existing application runs). A complex system may have a high level test plan to address the overall requirements and supporting test plans to address the design details of subsystems and components. Test plan document formats can be as varied as the products and organizations to which they apply. There are three major elements that should be described in the test plan: Test Coverage, Test Methods, and Test Responsibilities. These are also used in a formal test strategy. Test coverage - Test coverage in the test plan states what requirements will be verified during what stages of the product life. Test Coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will have one or more corresponding means of verification. Test coverage for different product life stages may overlap, but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during Design Verification test, but not repeated during Acceptance test. Test coverage also feeds back into the design process, since the product may have to be designed to allow test access (see Design For Test). Test methods - Test methods in the test plan state how test coverage will be implemented. Test methods may be determined by standards, regulatory agencies, or contractual agreement, or may have to be created new. Test methods also specify test equipment to be used in the performance of the tests and establish pass/fail criteria. Test methods used to verify hardware design requirements can range from very simple steps, such as visual inspection, to elaborate test procedures that are documented separately. Test responsibilities - Test responsibilities include what organizations will perform the test methods and at each stage of the product life. This allows test organizations to plan, acquire or develop test equipment and other resources necessary to implement the test methods for which they are responsible. Test responsibilities also includes, what data will be collected, and how that data will be stored and reported (often referred to as "deliverables"). One outcome of a successful test plan should be a record or report of the verification of all design specifications and requirements as agreed upon by all parties. IEEE 829 test plan structure - IEEE 829-2008, also known as the 829 Standard for Software Test Documentation, is an IEEE standard that specifies the form of a set of documents for use in defined stages of software testing, each stage potentially producing its own separate type of document.[1] - Test plan identifier - Introduction - Test items - Features to be tested - Features not to be tested - Approach - Item pass/fail criteria - Suspension criteria and resumption requirements - Test deliverables - Testing tasks - Environmental needs - Responsibilities - Staffing and training needs - Schedule - Risks and contingencies - Approvals There are also other IEEE documents that suggest what should be contained in a test plan: - 829-1983 IEEE Standard for Software Test Documentation (superseded by 829-1998)[2] - 829-1998 IEEE Standard for Software Test Documentation (superseded by 829-2008)[3] - 1008-1987 IEEE Standard for Software Unit Testing[4] - 1012-2004 IEEE Standard for Software Verification & Validation Plans[5] - 1059-1993 IEEE Guide for Software Verification & Validation Plans (withdrawn)[6]

What is Alpha Testing?

Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.

What is Beta Testing?

Beta testing comes after alpha testing and can be considered a form of external user acceptance testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.

What is Black Box Testing?

Black-box testing is a method of software testing that tests the functionality of an application as opposed to its internal structures or workings (see white-box testing). This method of test can be applied to all levels of software testing: unit, integration, system and acceptance. It typically comprises most if not all testing at higher levels, but can also dominate unit testing as well. Test procedures Specific knowledge of the application's code/internal structure and programming knowledge in general is not required. The tester is only aware of what the software is supposed to do, but not how i.e. when a certain input is entered, a certain output is returned; without being aware of how the output was produced in the first place.[1] Test cases Test cases are built around specifications and requirements, i.e., what the application is supposed to do. It uses external descriptions of the software, including specifications, requirements, and designs to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object's internal structure. Test design techniques Typical black-box test design techniques include: Decision table testing All-pairs testing State transition tables Equivalence partitioning Boundary value analysis Hacking In penetration testing, black-box testing refers to a methodology where an ethical hacker has no knowledge of the system being attacked. The goal of a black-box penetration test is to simulate an external hacking or cyber warfare attack.

What is Pairwise Testing? When is Pairwise Testing used?

In computer science, all-pairs testing or pairwise testing is a combinatorial method of software testing that, for each pair of input parameters to a system (typically, a software algorithm), tests all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by "parallelizing" the tests of parameter pairs.

What is Software engineering?

Software engineering is a systematic approach to the analysis, design, implementation and maintenance of software.

What is STLC?

Software testing life cycle (STLC) identifies what test activities to carry out and when (what is the best time) to accomplish those test activities. Even though testing differs between organizations, there is a testing life cycle. Software Testing Test Planning, Test Analysis, Test Design, Construction and verification, Testing Cycles, Final Testing and Implementation and Post Implementation. Software testing has its own life cycle that intersects with every stage of the SDLC. The basic requirements in software testing life cycle is to control/deal with software testing - Manual, Automated and Performance. Test Planning This is the phase where Project Manager has to decide what things need to be tested,do I have the appropriate budget etc. Naturally proper planning at this stage would greatly reduce the risk of low quality software. This planning will be an ongoing process with no end point. Activities at this stage would include preparation of high level test plan-(according to IEEE test plan template The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.). Almost all of the activities done during this stage are included in this software test plan and revolve around a test plan. In Test Planning following are the major tasks: 1. Defining scope of testing 2. Identification of approaches 3. Defining risk 4. Identifying resources. 5. Defining Time Schedule simply planning the future activities are done in this phase. Test Analysis Once test plan is made and decided upon, next step is to delve a little more into the project and decide what types of testing should be carried out at different stages of SDLC(SoftwareDevalopmentLifeCycle), do we need or plan to automate, if yes then when the appropriate time to automate is, what type of specific documentation I need for testing,;, Proper and regular meetings should be held between testing teams, project managers, development teams, Business Analysts to check the progress of things which will give a fair idea of the movement of the project and ensure the completeness of the test plan created in the planning phase, which will further help in enhancing the right testing strategy created earlier. We will start creating test case formats and test cases itself. In this stage we need to develop Functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance Testing. Requirements are also analysed by BSA Test Design Test plans and cases which were developed in the analysis phase are revised. Functional validation matrix is also revised and finalized. In this stage risk assessment criteria is developed. If you have thought of automation then you have to select which test cases to automate and begin writing scripts for them. Test data is prepared. Standards for unit testing and pass / fail criteria are defined here. Schedule for testing is revised (if necessary) & finalized and test environment is prepared. Construction and verification In this phase we have to complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. We have to support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported. Testing Cycles In this phase we have to complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3....). In bug lifecycle the default state is "NEW" The final state of bug lifecycle is "CLOSE" The bug found at the first time in the system then it status is "NEW". Once the bug fix by the developer in the system developer change the status as "RESOLVE" After that tester will do regression or retest in the system whether the bug exists in the system means then its status will be "REOPEN" or the bug get resolve in the system means then its status "RESOLVE" changed in to "CLOSE". Final Testing and Implementation In this we have to execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions. The default state in bug lifecycle is "NEW" The final state of bug lifecycle is "CLOSE" Post Implementation In this phase, the testing process is evaluated and lessons learnt from that testing process are documented. Line of attack to prevent similar problems in future projects is identified. Create plans to improve the processes. The recording of new errors and enhancements is an ongoing process. Cleaning up of test environment is done and test machines are restored to base lines in this stage. Software Testing Life Cycle Phase Activities Outcome Planning Create high level test plan Test plan, Refined Specification Analysis Create detailed test plan, Functional Validation Matrix, test cases Revised Test Plan, Functional validation matrix, test cases Design test cases are revised; select which test cases to automate revised test cases, test data sets, sets, risk assessment sheet Construction scripting of test cases to automate, test procedures/Scripts, Drivers, test results, Bugreports. Testing cycles complete testing cycles Test results, Bug Reports Final testing execute remaining stress and performance tests, complete documentation Test results and different metrics on test efforts Post implementation Evaluate testing processes Plan for improvement of testing process Software testing lifecycle is a systematic approach towards the sequence of activities conducted during Testing phase. 1.Test Planning 2.Test Development 3.Test Execution 4.Result Analysis 5.Bug Tracking 6.Reporting.

What is the difference between SDLC and STLC?

...

What is the difference between Stress and Load Testing?

...

What is the difference between Top Down and Bottom Up Integration Testing?

...

What is Bug Tracking?

A bug tracking system is a software application that is designed to help quality assurance and programmers keep track of reported software bugs in their work. It may be regarded as a type of issue tracking system. Many bug tracking systems, such as those used by most open source software projects, allow users to enter bug reports directly. Other systems are used only internally in a company or organization doing software development. Typically bug tracking systems are integrated with other software project management applications. Having a bug tracking system is extremely valuable in software development, and they are used extensively by companies developing software products. Consistent use of a bug or issue tracking system is considered one of the "hallmarks of a good software team".[1]

What is Flow Chart?

A flowchart is a type of diagram that represents an algorithm or process, showing the steps as boxes of various kinds, and their order by connecting these with arrows. This diagrammatic representation can give a step-by-step solution to a given problem. Process operations are represented in these boxes, and arrows connecting them represent flow of control. Data flows are not typically represented in a flowchart, in contrast with data flow diagrams; rather, they are implied by the sequencing of operations. Flowcharts are used in analyzing, designing, documenting or managing a process or program in various fields.

What is the difference between Test Bed and Test Harness?

A testbed (also commonly spelled as test bed in research publications) is a platform for experimentation of large development projects. Testbeds allow for rigorous, transparent, and replicable testing of scientific theories, computational tools, and new technologies. In software testing, a test harness[note 1] or automated test framework is a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs. It has two main parts: the test execution engine and the test script repository. Test harnesses allow for the automation of tests. They can call functions with supplied parameters and print out and compare the results to the desired value. The test harness is a hook to the developed code, which can be tested using an automation framework. A test harness should allow specific tests to run (this helps in optimising), orchestrate a runtime environment, and provide a capability to analyse results.

Traceability Matrix

A traceability matrix is a document, usually in the form of a table, that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship. It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the product to the matching parts of high-level design, detailed design, test plan, and test cases. A requirements traceability matrix may be used to check to see if the current project requirements are being met, and to help in the creation of a Request for Proposal, various deliverable documents, and project plan tasks.[1] Common usage is to take the identifier for each of the items of one document and place them in the left column. The identifiers for the other document are placed across the top row. When an item in the left column is related to an item across the top, a mark is placed in the intersecting cell. The number of relationships are added up for each row and each column. This value indicates the mapping of the two items. Zero values indicate that no relationship exists. It must be determined if one must be made. Large values imply that the relationship is too complex and should be simplified. To ease the creation of traceability matrices, it is advisable to add the relationships to the source documents for both backward traceability and forward traceability. In other words, when an item is changed in one baselined document, it's easy to see what needs to be changed in the other.

What is BVA (Boundary Value Analysis) ? Explain with example

Boundary value analysis is a software testing(Black Box) technique in which tests are designed to include representatives of boundary values. The idea comes from the Boundary (topology). Given that we have a set of test vectors to test the system, a topology can be defined on that set. Those inputs which belong to the same equivalence class as defined by the equivalence partitioning theory would constitute the basis (topology).Given that the basis sets are neighbors as defined in neighbourhood (mathematics) , there would exist boundary between them. The test vectors on either side of the boundary are called boundary values. In practice this would require that the test vectors can be ordered, and that the individual parameters follows some kind of order ( either partial order or total order ). See Wikipedia article for Formal definition and Application

...

...

What is Sanity Testing?

Sanity testing determines whether it is reasonable to proceed with further testing. Long answer: In software development, the sanity test (a form of software testing which offers "quick, broad, and shallow testing"[1]) determines whether it is reasonable to proceed with further testing. Software sanity tests are commonly conflated with smoke tests.[2] A smoke test determines whether it is possible to continue testing, as opposed to whether it is reasonable[citation needed]. A software smoke test determines whether the program launches and whether its interfaces are accessible and responsive (for example, the responsiveness of a web page or an input button). If the smoke test fails, it is impossible to conduct a sanity test. In contrast, the ideal sanity test exercises the smallest subset of application functions needed to determine whether the application logic is generally functional and correct (for example, an interest rate calculation for a financial application). If the sanity test fails, it is not reasonable to attempt more rigorous testing. Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing. Many companies run sanity tests and unit tests on an automated build as part of their development process.[3] Sanity testing may be a tool used while manually debugging software. An overall piece of software likely involves multiple subsystems between the input and the output. When the overall system is not working as expected, a sanity test can be used to make the decision on what to test next. If one subsystem is not giving the expected result, the other subsystems can be eliminated from further investigation until the problem with this one is solved. The Hello world program is often used as a sanity test for a development environment. If Hello World fails to compile or execute, the supporting environment likely has a configuration problem. If it works, the problem being diagnosed likely lies in the real application being diagnosed. Another, possibly more common usage of 'sanity test' is to denote checks which are performed within program code, usually on arguments to functions or returns therefrom, to see if the answers can be assumed to be correct. The more complicated the routine, the more important that its response be checked. The trivial case is checking to see that a file opened, written to, or closed, did not fail on these activities - which is a sanity check often ignored by programmers.[citation needed] But more complex items can also be sanity-checked for various reasons. Examples of this include bank account management systems which check that withdrawals are sane in not requesting more than the account contains, and that deposits or purchases are sane in fitting in with patterns established by historical data - large deposits may be more closely scrutinized for accuracy, large purchase transactions may be double-checked with a card holder for validity against fraud, ATM withdrawals in foreign locations never before visited by the card holder might be cleared up with him, etc.; these are "runtime" sanity checks, as opposed to the "development" sanity checks mentioned above.

What is Build, Version and Release?

In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures, are tested to determine if they are fit for use.[1] Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming a unit could be an entire module but is more commonly an individual function or procedure. In object-oriented programming a unit is often an entire interface, such as a class, but could be an individual method. [2] Unit tests are created by programmers or occasionally by white box testers during the development process. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects,[3] fakes and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended. Its implementation can vary from being very manual (pencil and paper)[citation needed] to being formalized as part of build automation.

What is Regression Testing?

Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them. The intent of regression testing is to ensure that a change such as those mentioned above has not introduced new faults.[1] One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.[2] Common methods of regression testing include rerunning previously-completed tests and checking whether program behavior has changed and whether previously-fixed faults have re-emerged. Regression testing can be used to test a system efficiently by systematically selecting the appropriate minimum set of tests needed to adequately cover a particular change.

How do you manage Test Data required for Software Testing?

Test Data is data which has been specifically identified for use in tests, typically of a computer program. Some data may be used in a confirmatory way, typically to verify that a given set of input to a given function produces some expected result. Other data may be used in order to challenge the ability of the program to respond to unusual, extreme, exceptional, or unexpected input. Test data may be produced in a focused or systematic way (as is typically the case in domain testing), or by using other, less-focused approaches (as is typically the case in high-volume randomized automated tests). Test data may be produced by the tester, or by a program or function that aids the tester. Test data may be recorded for re-use, or used once and then forgotten. Domain testing is a family of test techniques that focus on the test data. This might include identifying common or critical inputs, representatives of a particular equivalence class model, values that might appear at the boundaries between one equivalence class and another, outrageous values that should be rejected by the program, combinations of inputs, or inputs that might drive the product towards a particular set of outputs.

9. What is the difference between Regression Testing and Retesting?

a) Retesting is carried out to verify defect fix / fixes. Regression testing is done to check if the defect fix / fixes have not impacted other functionality of the application that was working fine before applying the code changes. b) Retesting is planned based for the defect fixes listed in Build Notes. Regression testing is generic and may not be always specific to any defect fix or code change and can be planned as regional or full regression testing. c) Retesting involves executing test cases that were failed earlier and regression testing involves executing test cases that were passed earlier build i.e., functionality that was working in earlier builds. d) Retesting will involve rerunning failed test cases that are associated with defect(s) fixes being verified. Regression testing does not involve verifying defect fix but only executing regression test cases. e) Retesting always takes higher priority over Regression testing i.e., Regression testing is done after completing Retesting. In some projects where there are ample testing resources, Regression testing is carried out in parallel with retesting. f) Though Retesting and regression testing have different objectives and priorities, they equally important for project's success.

What is DFD (Data Flow Diagram)?

- DFD stands for Data flow diagram - DFDs are used during Analysis and design phase of SDLC (Software Development Life Cycle) - DFDs are used for visualization of data flow and data processing in a information system. - DFD will show inputs, outputs, processing and where data will be stored. - DFD will show communication or interaction between the system and external actors. - Context-level DFD or 0 Level DFD is a diagram which is a highest level of view of the system. - Context-level DFD indicates actors outside system interacting with the system.

What is test case?

- Test Case is a software engineering terminology - Test Cases are also referred to as Test Scripts - Collection of related test cases are referred to as Test Suite. e.g. regression test suite. - Test Case contains a set of test steps and expected results - Test Cases based on requirements. Test Cases can be written for Use cases also. - Test Cases are usually documented and can be documented in word or excel or Test management tools like HP Quality Center - Test Case template usually contains below information * Importance of the Test Case (High / Medium / Low) * Complexity of the Test Case (High / Medium / Low) * Test Case author * Test Case reviewer * Requirements covered by Test Case * Test Case ID * Test Case description * Test steps and expected result for each step * Actual result for each of the expected result * Automated or Manual Test Case * Test Case result (Pass or Fail) * Comments / Remarks

How is Software Testing different from Software Quality Assurance?

...

Performance Testing

...

What are the challenges you faced as a Software Test Engineer?

...

What are the responsibilities of a Software Test Architect?

...

What is Fish Pond Analysis?

...

What is Localisation Testing?

...

What is Unit Testing ? Who does Unit Testing?

...

What is a Cyclomatic Complexity?

...

What is a Fish Bone Chart?

...

What is a Latent Bug?

...

What is the difference between Bug Reporting and Bug Tracking?

...

What is the difference between Error, Bug and Defect ?

...

SDLC?

A software development process, also known as a software development life-cycle (SDLC), is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a life-cycle model a more general term and a software development process a more specific term. For example, there are many specific software development processes that 'fit' the spiral life-cycle model. ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software. Overview The large and growing body of software development organizations implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on 'process models' to obtain contracts. The international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO/IEC 12207. A decades-long goal has been to find repeatable, predictable processes that improve productivity and quality. Some try to systematize or formalize the seemingly unruly task of writing software. Others apply project management techniques to writing software. Without project management, software projects can easily be delivered late or over budget. With large numbers of software projects not meeting their expectations in terms of functionality, cost, or delivery schedule, effective project management appears to be lacking. Organizations may create a Software Engineering Process Group (SEPG), which is the focal point for process improvement. Composed of line practitioners who have varied skills, the group is at the center of the collaborative effort of everyone in the organization who is involved with software engineering process improvement. Software development models Several models exist to streamline the development process. Each one has its pros and cons, and it's up to the development team to adopt the most appropriate one for the project. Sometimes a combination of the models may be more suitable. Waterfall model Spiral model Iterative and incremental development Agile development Code and fix

What is SRS (Software Requirement Specification) document? How is it useful for Software Testing team?

A software requirements specification (SRS) — a requirements specification for a software system — is a complete description of the behavior of a system to be developed and may include a set of use cases that describe interactions the users will have with the software. In addition it also contains non-functional requirements. Non-functional requirements impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). The software requirements specification document enlists all necessary requirements for project development.[1] To derive the requirements we need to have clear and thorough understanding of the products to be developed. This is prepared after detailed communications with project team and the customer. A general organization of an SRS is as follows [2][3] - Introduction Purpose Definitions System overview References - Overall description Product perspective System Interfaces User Interfaces Hardware interfaces Software interfaces Communication Interfaces Memory Constraints Operations Site Adaptation Requirements Product functions User characteristics Constraints, assumptions and dependencies - Specific requirements External interface requirements Functional requirements Performance requirements Design constraints Standards Compliance Logical database requirement Software System attributes Reliability Availability Security Maintainability Portability Other requirements

What are the different types of software testing? Explain them briefly.

Below is an exhaustive list of "types of software testing" and a brief description about each type of software testing, like load testing, stress testing, unit testing, system testing, acceptance testing, certification testing, performance testing, user acceptance testing, penetration testing, automated testing, beta testing, compatibility testing, security testing, benchmark testing, functional testing, negative testing, destructive testing, integration testing, regression testing, alpha testing, end-to-end testing, path testing, smoke testing, black box testing, stability testing, usability testing etc., and many more, about 100 software testing types with descriptions are listed below. Why there are so many types of software testing? Quality of software is assessed in terms of 6 Quality factors (Functionality, Reliability, Efficiency, Usability, Maintainability and Portability). Each of below listed type of software testing is designed to validate software for one or more of the mentioned quality factors. More types of software testing have evolved to keep up with the pace with rapid increase in complexity of the software design, frameworks & Programming languages, increased number of users with popularity of internet, advent of new platforms and technologies. With increase in number of software testing types to be performed, need for software testing tools has increased as well. http://www.softwaretestingsoftware.com/all-types-of-software-testing/ Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects). Software testing can be stated as the process of validating and verifying that a computer program/application/product: meets the requirements that guided its design and development, works as expected, can be implemented with the same characteristics, and satisfies the needs of stakeholders. Software testing, depending on the testing method employed, can be implemented at any time in the development process. Traditionally most of the test effort occurs after the requirements have been defined and the coding process has been completed, but in the Agile approaches most of the test effort is on-going. As such, the methodology of the test is governed by the chosen software development methodology. Different software development models will focus the test effort at different points in the development process. Newer development models, such as Agile, often employ test-driven development and place an increased portion of the testing in the hands of the developer, before it reaches a formal team of testers. In a more traditional model, most of the test execution occurs after the requirements have been defined and the coding process has been completed.

What is Decision Table ? Explain with example.

Decision tables are a precise yet compact way to model complicated logic.[1] Decision tables, like flowcharts and if-then-else and switch-case statements, associate conditions with actions to perform, but in many cases do so in a more elegant way. In the 1960s and 1970s a range of "decision table based" languages such as Filetab were popular for business programming. The four quadrants Conditions Condition alternatives Actions Action entries Each decision corresponds to a variable, relation or predicate whose possible values are listed among the condition alternatives. Each action is a procedure or operation to perform, and the entries specify whether (or in what order) the action is to be performed for the set of condition alternatives the entry corresponds to. Many decision tables include in their condition alternatives the don't care symbol, a hyphen. Using don't cares can simplify decision tables, especially when a given condition has little influence on the actions to be performed. In some cases, entire conditions thought to be important initially are found to be irrelevant when none of the conditions influence which actions are performed. See Wikipedia Article for Quadrant Image Aside from the basic four quadrant structure, decision tables vary widely in the way the condition alternatives and action entries are represented.[2][3] Some decision tables use simple true/false values to represent the alternatives to a condition (akin to if-then-else), other tables may use numbered alternatives (akin to switch-case), and some tables even use fuzzy logic or probabilistic representations for condition alternatives.[4] In a similar way, action entries can simply represent whether an action is to be performed (check the actions to perform), or in more advanced decision tables, the sequencing of actions to perform (number the actions to perform). Example The limited-entry decision table is the simplest to describe. The condition alternatives are simple Boolean values, and the action entries are check-marks, representing which of the actions in a given column are to be performed. A technical support company writes a decision table to diagnose printer problems based upon symptoms described to them over the phone from their clients. The following is a balanced decision table (created by Systems Made Simple). See Wikipedia Article for Example Image - Printer Troubleshooter

What is Equivalence Partitioning? Explain with Example.

Equivalence partitioning (also called Equivalence Class Partitioning or ECP[1]) is a software testing technique that divides the input data of a software unit into partitions of data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once. This technique tries to define test cases that uncover classes of errors, thereby reducing the total number of test cases that must be developed.An advantage of this approach is reduction in the time required for testing a software due to lesser number of test cases. Equivalence partitioning is typically applied to the inputs of a tested component, but may be applied to the outputs in rare cases. The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object. The fundamental concept of ECP comes from equivalence class which in turn comes from equivalence relation. A software system is in effect a computable function implemented as an algorithm in some implementation programming language. Given an input test vector some instructions of that algorithm gets covered, ( see code coverage for details ) others do not. This gives the interesting relationship between input test vectors:- is an equivalence relation between test vectors if and only if the coverage foot print of the vectors are exactly the same, that is, they cover the same instructions, at same step. This would evidently mean that the relation cover would partition the input vector space of the test vector into multiple equivalence class. This partitioning is called equivalence class partitioning of test input. If there are equivalent classes, only vectors are sufficient to fully cover the system. The demonstration can be done using a function written in c language int safe_add( int a, int b ) { int c = a + b ; if ( a >= 0 && b >= 0 && c < 0 ) { fprintf ( stderr, "Overflow!\n"); } if ( a < 0 && b < 0 && c >= 0 ) { fprintf ( stderr, "Underflow!\n"); } return c; } On the basis of the code, the input vectors of are partitioned. The blocks we need to cover are the overflow statement and the underflow statement and neither of these 2. That gives rise to 3 equivalent classes, from the code review itself. To solve the input problem, we take refuge in the inequation we note that there is a fixed size of Integer (computer science) hence, the z can be replaced with:- and with and The values of the test vector at the strict condition of the equality that is and are called the boundary values, Boundary-value analysis has detailed information about it . Note that the graph only covers the overflow case, first quadrant for X and Y positive values. In general an input has certain ranges which are valid and other ranges which are invalid. Invalid data here does not mean that the data is incorrect, it means that this data lies outside of specific partition. This may be best explained by the example of a function which takes a parameter "month". The valid range for the month is 1 to 12, representing January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13. ... -2 -1 0 1 .............. 12 13 14 15 ..... --------------|-------------------|--------------------- invalid partition 1 valid partition invalid partition 2 The testing theory related to equivalence partitioning says that only one test case of each partition is needed to evaluate the behaviour of the program for the related partition. In other words it is sufficient to select one test case out of each partition to check the behaviour of the program. To use more or even all test cases of a partition will not find new faults in the program. The values within one partition are considered to be "equivalent". Thus the number of test cases can be reduced considerably. An additional effect of applying this technique is that you also find the so-called "dirty" test cases. An inexperienced tester may be tempted to use as test cases the input data 1 to 12 for the month and forget to select some out of the invalid partitions. This would lead to a huge number of unnecessary test cases on the one hand, and a lack of test cases for the dirty ranges on the other hand. The tendency is to relate equivalence partitioning to so called black box testing which is strictly checking a software component at its interface, without consideration of internal structures of the software. But having a closer look at the subject there are cases where it applies to grey box testing as well. Imagine an interface to a component which has a valid range between 1 and 12 like the example above. However internally the function may have a differentiation of values between 1 and 6 and the values between 7 and 12. Depending upon the input value the software internally will run through different paths to perform slightly different actions. Regarding the input and output interfaces to the component this difference will not be noticed, however in your grey-box testing you would like to make sure that both paths are examined. To achieve this it is necessary to introduce additional equivalence partitions which would not be needed for black-box testing. For this example this would be: ... -2 -1 0 1 ..... 6 7 ..... 12 13 14 15 ..... --------------|---------|----------|--------------------- invalid partition 1 P1 P2 invalid partition 2 valid partitions To check for the expected results you would need to evaluate some internal intermediate values rather than the output interface. It is not necessary that we should use multiple values from each partition. In the above scenario we can take -2 from invalid partition 1, 6 from valid partition P1, 7 from valid partition P2 and 15 from invalid partition 2. Equivalence partitioning is not a stand alone method to determine test cases. It has to be supplemented by boundary value analysis. Having determined the partitions of possible inputs the method of boundary value analysis has to be applied to select the most effective test cases out of these partitions.

What is Grey Box Testing?

Gray-box testing (International English spelling: grey-box testing) is a combination of white-box testing and black-box testing. The aim of this testing is to search for the defects if any due to improper structure or improper usage of applications. Gray-box testing is also known as translucent testing.[1][2] Overview A black-box tester is unaware of the internal structure of the application to be tested, while a white-box tester knows the internal structure of the application. A gray-box tester partially knows the internal structure, which includes access to the documentation of internal data structures as well as the algorithms used.[3] Gray-box testers require both highlevel and detailed documents describing the application, which they collect in order to define testcases.[4] Need for gray-box testing Gray-box testing is beneficial because it takes the straightforward technique of black-box testing and combines it with the code targeted systems in white-box testing.[5] Gray-box testing is based on requirement test case generation because it presets all the condition before program is tested by using assertion method. Requirement specification language is used to state the requirements which make easy to understand the requirements and verify its correctness too where input for requirement test case generation is the predicates and the verification discussed in requirement specification language.[6] Gray-box testing assumptions for object-oriented software Object-oriented software consists primarily of objects; where objects are single indivisible units having executable code and/or data. Some assumptions are stated below which are needed for the application of use gray-box testing. Activation of Methods[7] State Reporting in Class Under Test (CUT). Report Testing is inherent in Class Under Test.[6]

What is the difference between Verification and Validation?

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. Definitions Validation checks that the product design satisfies or fits the intended usage (high-level checking), i.e., the software meets the user requirement. This is done through dynamic testing and other forms of review. Verification and validation are not the same thing, although they are often confused. Boehm (Boehm, 1979) succinctly expressed the difference between them: Validation: Are we building the right product? Verification: Are we building the product right? According to the Capability Maturity Model (CMMI-SW v1.1), Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610]. Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610] In other words, validation ensures that the product actually meets the user's needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications. Validation ensures that "you built the right thing". Verification ensures that "you built it right". Validation confirms that the product, as provided, will fulfill its intended use. From testing perspective: Fault - wrong or missing function in the code. Failure - the manifestation of a fault during execution. Malfunction - according to its specification the system does not meet its specified functionality. Within the modeling and simulation community, the definitions of validation, verification and accreditation are similar: Validation is the process of determining the degree to which a model, simulation, or federation of models and simulations, and their associated data are accurate representations of the real world from the perspective of the intended use(s).[1] Accreditation is the formal certification that a model or simulation is acceptable to be used for a specific purpose.[1] Verification is the process of determining that a computer model, simulation, or federation of models and simulations implementations and their associated data accurately represents the developer's conceptual description and specifications.[1]

Stress Testing

In software testing, stress testing refers to tests that determine the robustness of software by testing beyond the limits of normal operation. Stress testing is particularly important for "mission critical" software, but is used for all types of software. Stress tests commonly put a greater emphasis on robustness, availability, and error handling under a heavy load, than on what would be considered correct behavior under normal circumstances. - Field experience Failures may be related to: - use of non production like environments, e.g. databases of smaller size - complete lack of load or stress testing Rationale - Reasons for stress testing include: - The software being tested is "mission critical", that is, failure of the software (such as a crash) would have disastrous consequences. - The amount of time and resources dedicated to testing is usually not sufficient, with traditional testing methods, to test all of the situations in which the software will be used when it is released. - Even with sufficient time and resources for writing tests, it may not be possible to determine before hand all of the different ways in which the software will be used. This is particularly true for operating systems and middleware, which will eventually be used by software that doesn't even exist at the time of the testing. - Customers may use the software on computers that have significantly fewer computational resources (such as memory or disk space) than the computers used for testing. - Concurrency is particularly difficult to test with traditional testing methods. Stress testing may be necessary to find race conditions and deadlocks. - Software such as web servers that will be accessible over the Internet may be subject to denial of service attacks. - Under normal conditions, certain types of bugs, such as memory leaks, can be fairly benign and difficult to detect over the short periods of time in which testing is performed. However, these bugs can still be potentially serious. In a sense, stress testing for a relatively short period of time can be seen as simulating normal operation for a longer period of time.

What are Non-Functional Requirements?

In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture. Broadly, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of "system shall do ", while non-functional requirements are "system shall be ". Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are "constraints", "quality attributes", "quality goals", "quality of service requirements" and "non-behavioral requirements".[1] Informally these are sometimes called the "ilities", from attributes like stability and portability. Qualities, that is non-functional requirements, can be divided into two main categories: Execution qualities, such as security and usability, which are observable at run time. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.[2][3]

Six Sigma

Six Sigma is a business management strategy, originally developed by Motorola in 1986.[1][2] Six Sigma became well known after Jack Welch made it a central focus of his business strategy at General Electric in 1995,[3] and today it is widely used in many sectors of industry.[4]. Six Sigma seeks to improve the quality of process outputs by identifying and removing the causes of defects (errors) and minimizing variability in manufacturing and business processes.[5] It uses a set of quality management methods, including statistical methods, and creates a special infrastructure of people within the organization ("Black Belts", "Green Belts", etc.) who are experts in these methods.[5] Each Six Sigma project carried out within an organization follows a defined sequence of steps and has quantified financial targets (cost reduction and/or profit increase).[5] The term Six Sigma originated from terminology associated with manufacturing, specifically terms associated with statistical modeling of manufacturing processes. The maturity of a manufacturing process can be described by a sigma rating indicating its yield or the percentage of defect-free products it creates. A six sigma process is one in which 99.99966% of the products manufactured are statistically expected to be free of defects (3.4 defects per million). Motorola set a goal of "six sigma" for all of its manufacturing operations, and this goal became a byword for the management and engineering practices used to achieve it.

What is Smoke Testing?

Smoke testing is used to determine whether there are serious problems with a piece of software, for example as a build verification test. Long answer: Smoke testing refers to physical tests made to closed systems of pipes to test for leaks. By metaphorical extension, the term is also used for the first test made after assembly or repairs to a system, to provide some assurance that the system under test will not catastrophically fail. After a smoke test proves that "the pipes will not leak, the keys seal properly, the circuit will not burn, or the software will not crash outright,"[citation needed] the system is ready for more stressful testing. The term smoke testing is used in several fields, including electronics, software development, plumbing, woodwind repair, infectious disease control, and the entertainment industry.

What is the difference between Performance Testing and Stress Testing?

Software performance testing Performance testing is in general executed to determine how a system or sub-system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage. Load testing is primarily concerned with testing that the system can continue to operate under a specific load, whether that be large quantities of data or a large number of users. This is generally referred to as software scalability. The related load testing activity of when performed as a non-functional activity is often referred to as endurance testing. Volume testing is a way to test software functions even when certain components (for example a file or database) increase radically in size. Stress testing is a way to test reliability under unexpected or rare workloads. Stability testing (often referred to as load or endurance testing) checks to see if the software can continuously function well in or above an acceptable period. There is little agreement on what the specific goals of performance testing are. The terms load testing, performance testing, reliability testing, and volume testing, are often used interchangeably. In software testing, stress testing refers to tests that determine the robustness of software by testing beyond the limits of normal operation. Stress testing is particularly important for "mission critical" software, but is used for all types of software. Stress tests commonly put a greater emphasis on robustness, availability, and error handling under a heavy load, than on what would be considered correct behavior under normal circumstances.

What are the disadvantages of Black Box Testing?

Specification-based testing may be necessary to assure correct functionality, but it is insufficient to guard against complex or high-risk situations.[24] One advantage of the black box technique is that no programming knowledge is required. Whatever biases the programmers may have had, the tester likely has a different set and may emphasize different areas of functionality. On the other hand, black-box testing has been said to be "like a walk in a dark labyrinth without a flashlight."[25] Because they do not examine the source code, there are situations when a tester writes many test cases to check something that could have been tested by only one test case, or leaves some parts of the program untested.

Why is V model called as V Model?

V Model is presented in V shape instead of being straight or linear like Waterfall model. Name of the model has come because of the V Shape, similarly there are other models that are named of their shape like Spiral model.

What is Volume Testing?

Volume Testing belongs to the group of non-functional tests, which are often misunderstood and/or used interchangeably. Volume testing refers to testing a software application with a certain amount of data. This amount can, in generic terms, be the database size or it could also be the size of an interface file that is the subject of volume testing. For example, if you want to volume test your application with a specific database size, you will expand your database to that size and then test the application's performance on it. Another example could be when there is a requirement for your application to interact with an interface file (could be any file such as .dat, .xml); this interaction could be reading and/or writing on to/from the file. You will create a sample file of the size you want and then test the application's functionality with that file in order to test the performance.