What’s the Software Testing? A set of activities conducted with the intent of finding errors in software.

What’s the Test Plan? A high level of documents that define the software testing project. What’s the Test Case? A set of test inputs, execution, and expected result developed for a particular objective. What’s the Test Log? A chronological record of all relevant details about the execution of a test. What’s the Test Data? The actual values used in the test or that are necessary to execute the test. What’s the Database testing? In database testing, we can check the integrity of database field values. What’s the Defect? AnyMismatch in Software specification The difference between the functional specification and actual program text. What’s the Negative testing? That testing is designed for break the system. What’s the Test Bed? An environment that contain different types of hardware, software, simulator, testing tools, and other support elements that are necessary to conduct a test. What’s the Test Condition? A set of circumstances that a test invokes. What’s the Usability testing? Usability testing is for user friendliness. What’s the Volume Testing? We can perform the Volume testing, where the system is subjected to large volume of data. What’s the Black Box testing? Black Box testing is not based on any knowledge of internal logic. What’s the White Box testing? White Box testing is based on knowledge of internal logic.

What’s Coding? A generation of source code. What’s the Unit Testing? Testing of individual component of software. What’s the Test Driver? A program or test tool used to execute test. . What’s the Defect Tracking? Defect tracking is the process of finding bugs in software.What’s the Regression Testing? After every update we should test the system and check the effects on all venerable point of system What’s the System Testing? After integration of all module check the correctness of functional flow of system. What’s the Test Life Cycle? A Test Life Cycle is contains seven stepsPlan Test Design Test Case Run Test Analyze Result Documents Test Result Preparation of Validation report Regression Testing What’s the Validation? Validation refers to a set of activities that ensure that the software has been built is traceable to customer requirements. What’s the Test Tool? A computer program that used in testing the systems. What’s the End-To-End Testing? Testing a complete application environment in a situation that mimics a real world use. What’s the performance Testing? In performance testing we can check the system with valid entry data and minimize the blocker condition possibility.

What’s the Bottom-up Testing? An approach to integration testing where the lowest level component are tested first. What’s the Security Testing? A testing which confirms that the software can restrict the access of unauthorized personnel. What’s the Boundary Value Analysis? . What’s the Data Flow Diagram? A modeling notation that represent the functional composition of a system. What’s the Software Requirement Specification? A deliverable that describe all data. an ability to take the point of view of the customers. What’s the Positive Testing? In positive testing we can assume that software is working fine. What’s the Accessibility Testing? Testing that determines if software will be usable by people with disabilities.What’s the Verification? Verification refers to a set of activities that ensure that correctly implements a specific function. Who’s the good software engineer? A good software engineer has “test to break” attitude. What’s the Debugging? Debugging is the method of finding and rectifying the cause of software failures. and all validation requirements for software. functional and behavioral requirement. What’s Ad Hoc Testing? A testing where the tester tries to break the software by randomly trying functionality of software. What’s Compatibility Testing? In Compatibility testing we can test that software is compatible with other elements of system. What’s the Smoke Testing? A Smoke testing is a cursory examination of all of the basic components of the software to ensure that they will work correctly. What’s the Static Testing? In Static testing we can analyze the source code to expose potential defects. and strong quality desire.

What’s the Traceability Matrix? A document that showing the relationship between Test Requirements and Test Cases. What’s the Functional Testing? In Functional Testing. we can test combined parts of application to determine if they work together correctly. What’s the Acceptance Testing? A testing conducted to enable a user or customer to determine whether to accept a software project. typical values. and error values.Boundary Value Analysis is a test data selection technique in whice values are choosen maximum. just inside. just outside boundries. When we performed Integration Testing? Usually performed after unit and functional testing. What’s the Integration Testing? In Integration Testing. minimum. we can test features or operational behaviour of a product to ensure that they correspond to it’s requirements. What’s the Top-Down testing? An approach to integration testing where the top level component are tested first. What’s the Validation Strategies? A Validation Strategies areUnit Testing Integration Testing System testing End to End Testing User Acceptance Testing Installation Testing Beta Testing What’s the Verification Strategies? . What’s the Test Scenario? It defines a set of test cases or test scripts and the sequences in which they are to be executed. The hope is then if software work correctly for these values then it’s will works for all values in between.

bug fix) does not introduce any bugs in unchanged feature is called as regression testing.white Box Testing How many types of approaches are used in Integration Testing? There are two types of approaches usedBottom-Up Top-Down What’s the Alpha Testing? The Alpha Testing is conducted at the developer sites and in a controlled environment by the end user of the software Diff b/w Regression testing and retesting? Regression testing. 3. u go ahead and test the changes. fix the bug. requirements can be changed. .re-execution of test cases in different releases just to make sure that changes (addition.when dev team makes any changes.A Verification Strategies areRequirement Reviews Design Reviews Code Walkthrough Code Inspections What’s the Beta Testing? Testing the application after the installation at the client place. design is tested.Black Box Testing Structural. testing the impact areas is called regression testing retesting. to elaborate this. deletion or modification of a feature.testing only the changes is called as re-testing V-model. u are sure that the changes that u have made affects the other features in the application. hence downward flow of bugs is reduced. rework reduces. What’s the Installation Testing? Testing the computer system during the installation. requirements are tested.deliverable are parallel-means testing and the development team start of their work simultaneously. How many types of testing? There are two types of testingFunctional. 2.

and not a fault report. • The exact output values and changes of value of the internal system state that are expected. Defining the expected values is very important. The results are either the test passed. Test Case Specification The test cases are produced when the test design is completed. Running the Tests • Test Log: Record the details of tests in time order. However in some projects they are not defined which results in a very poor quality set of test cases. Test Case Specification: Create the tests to be run. or it failed and that there was a discrepancy. Thus the sequence of the tests enables the fault to be found. the order of their running. Test Item Transmittal Report: Specify the items released for testing. meaning that the actual and expected results were identical. 3. and their identities recorded on the Test Log. IEEE 829 -Test Incident Report This document is deliberately named as an incident report. Completion of Testing • Test Summary Report: Summarize and evaluate tests. the fault may have occurred not in the Test Case that failed but in one that was run previously. Test Log The Test Log records the details of what Test Cases have been run. for only by doing this can discrepancies be spotted. which can be used in three distinct phases of software testing: 1. 2. The reason is that a discrepancy between expected and actual results can occur for a number of reasons other . • And any special steps for setting up the tests. and the results of the test. as well as providing valuable information for finding out what caused an incident. Preparation Of Tests • • • • • Test Plan: Plan how the testing will proceed. If there is a discrepancy than one or more Test Incident Reports are raised or updated. If an incident is a coding fault. • Test Incident Report: Record details of events that need to be investigated. Test cases specify for each testing requirement: • The exact input values that will be input and the values of any standing data that is required. Test Design Specification: Decide what needs to be tested.Types of Document There are eight document types in the IEEE 829 standard. Test Procedure: Describe how the tests are run. The Test Log is important as it allows progress of the testing to be checked.

and any supporting evidence that will help in its resolution. The report will also include. each of it derived from the previous document. and crucially an assessment about the quality of the system. This should also portrays functionality that are technically feasible within the stipulated times frames for delivery of the application. or inconsistency in the requirements meaning that more than one interpretation could be made. This document would serve as a base for UAT test preparation. and how long it took. This document is important in deciding whether the quality of the system is good enough to allow it to proceed to another stage. These documents are written in sequence. including an assessment about how well the testing has been done. this document is used to understand the user requirements and find the gaps between the User Requirement and Functional Specification.than a fault in the system. Functional Specification This document describes the functional needs. and going through various levels of requirements. The report consists of all details of the incident such as actual and expected results. Business Requirement This document describes users needs for the application. if possible. User Acceptance Test is based on this document. User Acceptance Test team should break the business requirement document into modules depending on how the user will use the application. Test Summary The Test Summary brings together all pertinent information about the testing. the test being run wrongly. the number of incidents raised and outstanding. While reading the document. As this contains user perspective requirements. design of the flow and user maintained . Test Preparation Process Baseline Documents Construction of an application and testing are done using certain documents. test team should put themselves as end users of the application. How to read a Business Requirement? In case of the Integrated Test Process. when it failed. These include the expected results being wrong. an assessment of the impact upon testing of an incident. This is done over a period of time. Also recorded for use in future project planning is details of what was done.

How to read a Functional Specification? The testing process begins by first understanding the functional specifications. In order to achieve synchronisation between the software construction and testing process. Interaction with test lead at this juncture is crucial to draw a testing approach. is sometimes written assuming some level of knowledge of the Testers and constructors. Integrated System Testing (IST) or User Acceptance Testing (UAT). these modules should be split into segments like field level validations. The FS is normally divided into modules. which specifies the client’s business needs. The tester must also bear in mind. module rules. he should orient his testing approach. (Explained later in the document) Tester’s Reading Perspective Functional specification. We can categorize the explanations by Explicit Rules: Functionality expressed as conditions clearly in writing. In order to overcome these. These are primarily derived from Business Requirement document. the test type i. . seeking clarifications then and there until clarity is achieved. Functional Specification (FS) serves as the Base document. This is used henceforth to develop further documents for software construction and validation and verification of the software. in the document. like an end-to-end test coverage or individual test. In order to do the same module’s importance and precisely the tester should interpret its role within the application. Implicit Rules: Functionality that is implied based on what is expressed as a specification/condition or requirement of a user. it is advisable for the tester to read the document multiple times. business rules etc. It is natural for a tester at this point to get confused on the total flow and functionality. These modules then become the tester’s responsibility. A high level understanding of the data requirements for respective modules is also expected from the tester at this point. The Tester should then begin to acquire an in-depth knowledge of their respective modules. The proposed application should adhere to the specifications specified in this document. Testers are then given a module or multiple modules for validation and verification.parameters.e. Based on this. In the process. The tester should understand the entire functionality that is proposed in the document by reading it thoroughly.

•miscommunication . The Test Team should also have a detailed understanding of the design specification in order to understand the system architecture. •inadequate testing . •unrealistic schedule .I think u got it the above expl right! Validation explanation: Here we execute the prodct with some test data to find the bugs. or not testable.Design Specification This document is prepared based on the functional specification. This is ideally prepared and used by the construction team. What are 5 common problems in the software development process? •poor requirements . incomplete.Performance testing. table structures and program specifications. Verification & Validation Verification means whether we building the product right or not. .no one will know whether or not the program is any good until the customer complains or systems crash.Black box testing.if too much work is crammed in too little time. when to start and when to exit according the exit criteria of the particular company. It contains the system architecture. So Verification is just like Static activity on the product because they are not executing the PUT (Product Under Test). problems are guaranteed. System Specification This document is a combination of functional specification and design specification.This Validation comes under Actual testing types like White Box testing. too general. there will be problems. Validation means whether we building the right product or not. Verification explanation: Before starting a test we have Testing process docs which may contain the scope of the product.if developers don't know what's needed or customer's have erroneous expectations. The Qa people will keep on verifying the testing progress according to the Test process they have developed.requests to pile on new features after development is underway. •featuritis . extremely common. Under such situations it may not be advisable make two documents.if requirements are unclear.. This is used in case of small applications or an enhancement to an application. problems are inevitable.So this is dynamic activity as we are exercising the product with some inputs.

QA is an effective approach to producing a high quality product. and is the best deliverable that can be produced. and that the process is working. is error free. The above definition emphasizes three important points. and measurable. The end result is the assurance that the system and application is of high quality. and implicit characteristics that are expected of all professionally developed software. on the other hand. . From the client's perspective. to identify defects. Software requirements are the foundation from which quality is measured. The achievement of quality goals is well within reach when organizational strategies are used in the testing process. with respect to the context in which it is intended to operate. Testing provides information whether or not a certain product meets the requirements. an application's quality is high if it meets their expectations. is a review with a goal of improving the process as well as the deliverable. Quality.Quality Control is a process directed at validating that a specific deliverable meets standards. Testing is the process used to assess the quality of computer software. One aspect is the process of objectively reviewing project deliverables and the processes that produce them (including testing). basis. Quality is not based on a subjective assessment but rather on a clearly demonstrable. It is a responsibility internal to the team. QA is often an external process. 1. . and then making recommendations for improvement based on the reviews. (or) Quality assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. How do we define Quality? Conformance to explicitly state functional and performance requirements explicitly documented development standards. Relationship between QC and QA An application that meets its requirements totally can be said to exhibit quality. Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test. It also provides information where the product fails to meet the requirements. Lack of .QA.Diff between QA & Testing Quality Assurance is that set of activities that are carried out to set standards and to monitor and improve performance so that the care provided is as effective and as safe as possible.

lack of quality will almost surely result. There is a set of implicit requirements often goes unmentioned. Specified standards define a set of development criteria that guide the manner in which software is engineered. 2. . If software conforms to its explicit requirements but fails to meet implicit requirements. (E.g. 3.conformance to requirements is lack of quality. software quality is questionable. the desire of good maintainability). If the criteria are not followed.

Sign up to vote on this title
UsefulNot useful