1. What is the differences between Retesting and Regression testing?..

RE-TESTING: Testing the specified bug once bug has been fixed. REGRESSION TESTING: Testing the modified build to find the impact issues 2. Types of test cases?... - Unit test cases - System test cases - User acceptance test cases 3. Types of testing?.. - Unit testing Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses. Incremental integration testing Bottom up approach for testing i.e continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately. done by programmers or by testers. Integration testing Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems. Functional testing This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application. System testing Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system. End-to-end testing Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate. Sanity testing - Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix. Regression testing Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types. Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application. Load testing Its a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a

range of loads to determine at what point the systems response time degrades or fails. Stress testing System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load. Performance testing Term often used interchangeably with stress and load testing. To check whether system meets performance requirements. Used different performance and load tools to do this. Usability testing User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing. Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment. Recovery testing Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems. Security testing Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks. Compatibility testing Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above. Comparison testing Comparison of product strengths and weaknesses with previous versions or other similar products. Alpha testing In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing. Beta testing Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.

4. Testing Methods?... Black box testing Internal system design is not considered in this type of testing. Tests are based on requirements and functionality. White box testing This testing is based on knowledge of the internal logic of an applications code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions. Grey box Testing Combination of White box and Black box testing.

5. Testing Levels?.. - unit testing - the most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers

Incremental Integration testing - continuous testing of an application as new functionality is added. integration testing - testing of combined parts of an application to determine if they function together correctly. system testing - black-box type testing that is based on overall requirements specifications; covers all combined parts of a system. User acceptance testing - acceptance testing - final testing based on specifications of the end-user or customer, or based on use by endusers/customers over some limited period of time.

6. Difference between Smoke and Sanity testing?..

2 3

Smoke Smoke testing originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch fire and smoke. In software industry, smoke testing is a shallow and wide approach whereby all areas of the application without getting into too deep, is tested. A smoke test is scripted--either using a written set of tests or an automated test A Smoke test is designed to touch every part of the application in a cursory way. It's is shallow and wide. Smoke testing will be conducted to ensure whether the most crucial functions of a program work, but not bothering with finer details. (Such as build verification).

Sanity A sanity test is a narrow regression test that focuses on one or a few areas of functionality. Sanity testing is usually narrow and deep.

A sanity test is usually unscripted. A Sanity test is used to determine a small section of the application is still working after a minor change. Sanity testing is a cursory testing; it is performed whenever a cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing. sanity testing is to verify whether requirements are met or not, checking all features breadth-first.

5 Smoke testing is normal health check up to a build of an application before taking it to testing in depth.

7. What is the differences between Verification and Validation?.. Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed.

8. What is 'Software Quality Assurance'? (QA) Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'. 9. What is 'Software Quality Control'?(QC) QC involves actual testing to ensure that the application is working fine as per requirements. 10. Software Development Life Cycle (SDLC)?.. Below are the SDLC Phases: Requirement gathering -> Analysis - >Designing - >Coding ->Testing -> Support and Maintenance. In requirement phase, Requirements will be gathered from the client.(i.e, FRD, SRS) Analysis: Requirements will be analyzed in this phase.(i.e, Risks, technologies to be used, e.t.c) Design: Based on requirements, low and high level designs will be prepared (i.e, Data Model, e.t.c..) Coding: In this phase, application will be developed. Testing: developed application will be tested with various types of testing. Maintenance and support: tested application will be deployed in client environment and provide support as per agreement. 11. Software Test Cycle? (STLC)

STLC means it starts from the preparation of test plan, test case and ends with product release. Meanwhile we'l b involved in some other types of testing. Major tasks will be done in STLC. 12. Bug/Defect Life Cycle? Defect Life Cycle is the Cycle thru which a defect goes starts when defect found & ends when defect is closed after ensuring its not reproduced. Defect Life cycle is

related to Bug found during testing so it doesnt depend on Manual & Automated Testing. Phases of Defect Life Cycle are 1. New: When Defect discovered. 2. Open: When defect is addressed to the developer. It may then be Rejected, said to be duplicate or deferred. 3. Release for testing: Developer will release bug once issue is fixed. 4. Reopened: If the Released issue is not fixed, Tester will change bug status to reopened. 5. Fix: when it is fixed or defect solved by developer. 6. Close: After defect addressed by developer it comes to Tester to Test, once assured its no more a defect its is Close phase. 13. What's a 'test plan'? A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The objectives of test plan are:

Title Table of Contents Objective of testing effort overview Traceability requirements Project risk analysis Features to be tested and not to be tested Software entrance and exit criteria Test suspension and restart criteria Personnel allocation Personnel pre-training needs Test site/location Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues Relevant proprietary, classified, security, and licensing issues. Open issues Appendix - glossary, acronyms, etc.

14. What is a test case?.. A testcases is a typical document which describes the Inputs and Outputs of functionality to determine that the functionality is working fine as per requirements.

Test Test Test Test Purp Crea Prerequi Case Environ Proce ose ted sites Id ment dure By Condition Software s that Serial or should no Nam Brief hardwar be assig e of idea e in fulfilled ned test about which before to creat case the test the test test or case is is case executed performe d

Expec Actu Verdi Test ted al ct: Comm Data Resul Res Pass/ ents t ult Fail

Steps to be perfor med in test

Input s, varia bles and data

What the progra m should do

Wha Notes t is Status on the actu of the proced ally test ure done

15. Requirement traceability matrix?..(RTM) RTM is used to ensure that all the requirements is tested, By mapping the Requirement ID and Test Case ID we will ensure that all the functionalities is tested/Developed 16. When will you Start or End the testing?.. Based on start and exit criteria in test plan we will start or stop testing of an application. 17. Authentication : Authentication check whether the user exist or not. 18. Authorization: authorization check, user has right to access specific data or not. 19. BUG: Deviation from the expected result. 20. Defect: Problem in algorithm leads to failure. 21. What is testing?.. Testing is the process to verify that the application is working fine as per requirements. 22. What if there is not enough time to thoroughly?.. Firstly I will test major/Key functionalities in the application, then I will try to complete testing remaining functionalities on time. 23. Priority v/s Severity?.. Priority associate with Schedule where as severity associate with standards. 24. Equivalence Partitioning: In this method the input domain data is divided into different equivalence data classes. This method is typically used to reduce the total number of test cases

25. Boundary Value Analysis: Boundary value analysis is a next part of Equivalence partitioning for designing test cases where test cases are selected at the edges of the equivalence classes. 26. Product V/S Project?... Project: 1. Specifications will be given by Client 2. Client views/ requirements will be considered 3. End user is one 4.Once developed it will be finished Product: 1. Company designs product 2. Company with own views (based on market) develops product 3.End users are more than one 4. Never ending process 5.Customization is possible. 27. Static V/s Dynamic testing: Static testing: Non-execution based testing is called static testing. Dynamic testing: Execution based Testing is called dynamic testing 28. Use case? Usecases are High Level requirements and it's describes all Functionalities as per user point of view.