R e q u i r e m e n t s

1.

What is white and black box testing ? White Box Testing Also known as glass box, structural, clear box and open box testing. A software testing technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. White box testing uses specific knowledge of programming code to examine outputs. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing is typically done by a programmer. Black Box Testing Also known as functional testing. A software testing technique whereby the internal workings of the item being tested are not known by the tester. For example, in a black box test on a software design the tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. The tester does not ever examine the programming code and does not need any further knowledge of the program other than its specifications. The advantages of this type of testing include: The test is unbiased because the designer and the tester are independent of each other. The tester does not need knowledge of any specific programming languages. The test is done from the point of view of the user, not the designer. Test cases can be designed as soon as the specifications are complete. The disadvantages of this type of testing include: The test can be redundant if the software designer has already run a test case. The test cases are difficult to design. Testing every possible input stream is unrealistic because it would take a inordinate amount of time; therefore, many program paths will go untested. For a complete software examination, both white box and black box tests are required.

2.

What is a test case & test procedure ? A test procedure is a detailed instructions document for the set-up, execution, and evaluation of results for a given test case. This document contains a set of associated instructions. Test procedure consists of detailed sequence of steps that has to be followed for executing a test, generally test procedure is written from a test case. A test case in software engineering is a set of conditions or ideas under which a tester will determine whether an application or software module is working correctly or not. It may take many test cases to determine that a software program or system is considered sufficiently scrutinized to be released. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites.

3.

Write the 'Fish model' & the 'V model'. Fish model
Analysis Design Coding Delivery Maintenance

BRS Doc

SRS Doc

Design Doc

System Testing

Verification Reviews in Analysys Reviews in Design

Validation White Box Testing Test Software Changes

Fish model defines the mapping between development stages and Testing stages. This is a process oriented companys development model. Eventhough it is a time consuming and expensive model, One can be rest assured that both verification and validation is done in parelell to the software development in each phase of the model. So there are two documents generated by the end of each phase , one for validation and one for verification. Because all the stages except the last delivery and maintenance phase is covered , by the two parallel processes, the structure of this model looks like a skeleton between two parallel lines, hence the name fish model. Advantages: This strict process results in products of exceptional quality. So one of the important objective is acheived. Disadvantages: Time consuming and expensive.
4.

Write about a. Software Test Life Cycle Software Testing is not a just a single activity. It consists of series of activities carried out methodologically to help certify a software product. These activities (stages) constitute the Software Testing Life Cycle (STLC).
1.

Requirement Analysis During this phase, test team studies the requirements from a testing point of view to identify the testable requirements. The QA team may interact with various stakeholders (Client, Business Analyst, Technical Leads, System Architects etc) to understand the requirements in detail. Requirements could be either Functional (defining what the software must do) or Non Functional (defining system performance /security availability ). Automation feasibility for the given testing project is also done in this stage. Activities Identify types of tests to be performed. Gather details about testing priorities and focus. Prepare Requirement Traceability Matrix (RTM). Identify test environment details where testing is supposed to be carried out. Automation feasibility analysis (if required). RTM Automation feasibility report. (if applicable)

Deliverables
2.

Test Planning This phase is also called Test Strategy phase. Typically , in this stage, a Senior QA manager will determine effort and cost estimates for the project and would prepare and finalize the Test Plan. Activities Preparation of test plan/strategy document for various types of testing

Test tool selection Test effort estimation Resource planning and determining roles and responsibilities. Training requirement Test plan /strategy document. Effort estimation document.

Deliverables
3.

Test Case Development This phase involves creation, verification and rework of test cases & test scripts. Test data , is identified/created and is reviewed and then reworked as well. Activities Create test cases, automation scripts (if applicable) Review and baseline test cases and scripts Create test data (If Test Environment is available) Test cases/scripts Test data

Deliverables
4.

Test Environment Setup Test environment decides the software and hardware conditions under which a work product is tested. Test environment set-up is one of the critical aspects of testing process and can be done in parallel with Test Case Development Stage. Test team may not be involved in this activity if the customer/development team provides the test environment in which case the test team is required to do a readiness check (smoke testing) of the given environment. Activities Understand the required architecture, environment set-up and prepare hardware and software requirement list for the Test Environment. Setup test Environment and test data Perform smoke test on the build Environment ready with test data set up Smoke Test Results.

Deliverables
5.

Test Execution During this phase test team will carry out the testing based on the test plans and the test cases prepared. Bugs will be reported back to the development team for correction and retesting will be performed. Activities Execute tests as per plan Document test results, and log defects for failed cases Map defects to test cases in RTM

Retest the defect fixes Track the defects to closure Completed RTM with execution status Test cases updated with results Defect reports

Deliverables
6.

Test Cycle Closure Testing team will meet , discuss and analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from the current test cycle. The idea is to remove the process bottlenecks for future test cycles and share best practices for any similar projects in future. Activities Evaluate cycle completion criteria based on coverage,Cost,Software,Critical Business Objectives , Quality Prepare test metrics based on the above parameters. Document the learning out of the project Prepare Test closure report Qualitative and quantitative reporting of quality of the work product to the customer. Test result analysis to find out the defect distribution by type and severity. Test Closure report Test metrics Time,Test

Deliverables
b.

Bug Life Cycle There are seven

different

life

cycles

that

bug

can

pass

through:

I.

Cycle I
i) A tester finds a bug and reports it to the Test Lead. ii) The test lead verifies if the bug is valid or not. iii) Test lead finds that the bug is not valid and the bug is 'Rejected'.

II. Cycle II i) ii) iii) iv) A tester finds a bug and reports it to the Test Lead. The test lead verifies if the bug is valid or not. The bug is verified and reported to the development team with status as 'New'. The development leader and team verify if it is a valid bug. The bug is invalid and is marked with a status of 'Pending Reject' before passing it back to the testing team. v) After getting a satisfactory reply from the development side, the test leader marks the bug as 'Rejected'. III. Cycle III i) ii) A tester finds a bug and reports it to the Test Lead. The test lead verifies if the bug is valid or not.

iii) The bug is verified and reported to the development team with status as 'New'. iv) The development leader and team verify if it is a valid bug. The bug is valid and the development leader assigns a developer to it, marking the status as 'Assigned'. v) The developer solves the problem and marks the bug as 'Fixed' and passes it back to the Development leader. vi) The development leader changes the status of the bug to 'Pending Retest' and passes it on to the testing team for retest. vii) The test leader changes the status of the bug to 'Retest' and passes it to a tester for retest. viii) The tester retests the bug and if it is working fine, the tester closes the bug and marks it as 'Closed'.

IV. Cycle IV i) ii) iii) iv) A tester finds a bug and reports it to the Test Lead. The test lead verifies if the bug is valid or not. The bug is verified and reported to the development team with status as 'New'. The development leader and team verify if it is a valid bug. If the bug is valid, the development leader assigns a developer for it, marking the status as 'Assigned'. v) The developer solves the problem and marks the bug as 'Fixed' and passes it back to the Development leader. vi) The development leader changes the status of the bug to 'Pending Retest' and passes it on to the testing team for retest. vii) The test leader changes the status of the bug to 'Retest' and passes it to a tester for retest.

viii) The tester retests the bug and the same problem persists, so the tester after confirmation from test leader reopens the bug and marks it with a 'Reopen' status. And then, the bug is passed back to the development team for fixing. V. Cycle V i) ii) iii) iv) A tester finds a bug and reports it to the Test Lead. The test lead verifies if the bug is valid or not. The bug is verified and reported to the development team with status as 'New'. The developer tries to verify if the bug is valid but fails to replicate the same scenario as it was at the time of testing, and asks for help from the testing team. v) The tester also fails to regenerate the scenario in which the bug was found. And finally, the developer rejects the bug marking it as 'Rejected'. VI. Cycle VI i) After confirmation that the data is unavailable or certain functionality is unavailable, the solution and retest of the bug is postponed for indefinite time and it is marked as 'Postponed'.

VII. Cycle VII i) If the bug does not stand importance and needs to be postponed, then it is given a status as 'Deferred'. c.

SDLC SDLC is an acronym for software development life cycle (SDLC) and also synonymous with software process as well as software engineering. It is a structured methodology used in the development of software products and packages. This methodology is used from the conception phase through to the delivery and end of life of a final software product. Following are the different phases of the SLDC: I. Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals. II. Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
III. Systems design: Describes desired features and operations in detail, including

screen layouts, business rules, process diagrams, pseudo code and other documentation. IV. Implementation (Development): The real code is written here. Integration and testing brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability. Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business. V. Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more.
d.

RUP The Rational Unified Process is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget. The Rational Unified Process activities create and maintain models. Rather than focusing on the production of large amount of paper documents, the Unified Process

emphasizes the development and maintenance of modelssemantically rich representations of the software system under development. The Rational Unified Process is a guide for how to effectively use the Unified Modeling Language (UML). The UML is an industry-standard language that allows us to clearly communicate requirements, architectures and designs. Phases Of RUP are: 1. Inception phase During the inception phase, you establish the business case for the system and delimit the project scope. To accomplish this you must identify all external entities with which the system will interact (actors) and define the nature of this interaction at a high-level. This involves identifying all use cases and describing a few significant ones. A initial use-case model (10% -20%) complete is a deliverable. 2. Elaboration phase The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project. A use-case model (at least 80% complete) is a deliverable all use cases and actors have been identified, and most usecas descriptions have been developed. 3. Construction phase During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are thoroughly tested. The construction phase is, in one sense, a manufacturing process where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. 4. Transition phase The purpose of the transition phase is to transition the software product to the user community. Once the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or finish the features that were postponed.
5. 6.

Write the test cases for a login page. What is Validating and Verifying ? Verification: Verification is a process of checking conducted on each and every role of an organization in order to check whether he is doing his tasks in a right manner according to the guidelines or not. Right from the starting of the process tiles the ending of the process. Usually the documents are verified in this process of checking. Validation Validation is a process of checking conducted on the developed product in order to check whether it is working according to the requirements or not.

Module 2
7.

What is Quality ? Quality is about meeting the needs and expectations of customers. Quality is about conformance to requirements rather than specifications.

8. 9.

Who are the stakeholders ? What is a Defect ? A defect is an error, in the application which is created. When any function does not work as it should work or does not meet as per the requirement, then its an defect. It is anything that makes the value of a product lower in the eyes of its stakeholder.

10. What are Dimensions of Quality ?

We can measuse quality using the following dimensions: Functionality - Feature set, Capabilities, Generality, Security Usability - Human factors, Aesthetics, Consistency, Documentation Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy Performance - Speed, Efficiency, Resource consumption, Throughput, Response time Supportability - Testability, Extensibility, Adaptability

11. Wha are Test Ideas ?

A test idea is a brief statement that identifys a test that may be useful. It has no specifications and are generators for test cases.
12. Where are Test Ideas useful ?

Test ideas a the building blocks for test cases. They also help in creating a test matrix.
13. Give examples of a Test Idea. 14. Explain how a catalog of Test Ideas could be applied to a Test Matrix.

A test idea catalog is a list of related test ideas that are usable under many circumstances. Each test idea from the catalog that we want to use can be formatted into a test matrix.

Module 4
15. What is a Test Mission ? 16. What is your Test Mission ? 17. What make a good Test Approach ? 18. What is a Test Documentation Mission 19. What is your Test Documentation Goal ?