You are on page 1of 7

Ravinder Puranam Testing related Document - Questions and Answers: Q: Why Testing / Quality is required?

A: Testing is the process to verify that the Software Application / Hardware Module has satisfied specified requirements or to identify differences between expected and actual results, where Test Engineers main intention is to find bugs / problems.

Q: What is the Goal of Testing? A: The main goal of testing is to check if the system meets the user requirements and check for the systems reliability. Many say that the Goal of testing is to find Bugs / errors

Q: What is Software testing? A: Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing also provides 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). 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.

Q: What are SDLC and STLC? A: SDLC is Software Development Life Cycle which has phases like Analysis, Design, Development / Coding, Testing and Maintenance. These again can be followed in different models like 1.Water fall model; 2.V-model; 3.Fish model; 4.Proto type model (Application developed without functionality); 5.spiral model; 6.Itterative model; 7.RAD model (Rapid application development) that means every company has its own model.; 8.Pett model: process experts tools and techniques HCL Chennai.; 9. Agile Model STLC is Software Test life cycle, this starts in the Testing Phase of SDLC, but the actual STLC starts from Analysis phase of SDLC. Testing in STLC can be performed in TopDown approach, Bottom-Up approach and Hybrid approach. * Each Software Development Life Cycle has its own Advantages and Disadvantages.

Ravinder Puranam Q: Difference between SDLC and STLC? A: STLC is the sub phase of the SDLC. SDLC takes care of all the phases of the project including STLC where as STLC only concentrates on the Testing phase of the project.

Q: What happens in the phases of SDLC and STLC? A: Below is a table which will describe the tasks performed and output Documents from each phase of SDLC and STLC, ** these can change depending on the SDLC Model that the project / company is using SDLC Requirement Analysis Phase (BR Docs / FRS / SRS / Use case Docs) Design Phase (HLD, LLD Docs) Development (or) Coding Phase Testing Phase Maintenance STLC Requirement Analysis Use the Docs from Requirement Phase of SDLC Prepare Test Strategy, Test Plan, Test Bed Use Docs from 2 phases of SDLC Prepare Test Environment Setup, Writing Test Scenarios and Test Cases Use Docs from 3 phases of SDLC Review Test cases, Execute Test cases and Bug Tracking Test metrics and any support to the concerned support team

Q: What is a Test Plan or Quality Plan?? A: A Test / Quality Plan is a Document which has all the information on how the Software / Hardware / Product needed to be tested, i.e., It says how the eventual Testing workflow will be. A Test Plan is usually prepared by a QC-Lead / Manager but with significant input from Test Engineers. Test Plan has information like: Project Introduction; Test Modules / Items; Features to be tested; Features not to be tested; Types of Testing / Approach to be followed; Entry and Exit criteria; Risks; Testing needs; Test deliverables & tasks; Staffing and training needs; Schedule; Approvals; Glossary; etc,.

Q: Who writes test cases and how do you verify all test cases are covered? A: Test Engineer writes test cases which are reviewed by Team Lead. Using Traceability Matrix, requirement change documents we can verify that all the test cases have been covered.

Ravinder Puranam Once the test cases are approved by the Team Lead, Test cases are executed depending on the Entry criteria in the Test Plan i.e. 1. After Sanity Testing from developer (Is the Basic Testing performed to assure that the system or methodology works as expected, often prior to a more exhaustive round of testing) or 2. Module wise testing or any other conditions etc

Q: Difference between Sanity testing and Smoke testing? A: Sanity testing: Is an Initial effort to check whether the new released application build from development team. The basic features of the application are tested to verify the stability of the application for further testing. Basic GUI functionality, connectivity to database, etc are concentrated here. Smoke Testing: Smoke testing is testing most crucial functions of the application to start with further testing / Regression testing and to approve the build for verification testing. Hence it is also called as Build verification test (BVT)

Q: Difference between Re-testing and Regression testing? A: Re-testing is testing ONLY executing the bugs/test cases which are raised in earlier builds and said to be fixed in the current released Build. Whereas Regression testing is executing all the test cases which are to be tested in any newly released build irrespective of pass/fail in earlier build so as to check if no new bugs are introduced due to the fixes done.

Q: What is INTEGRATION testing? A: Integration testing is any type of software testing. This is done by developing some scenarios which are most unlikely that seeks to verify the interfaces between components against a software design.

Q: What is System Testing? A: System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.

Q: What is a bug? A: A Bug is the common term used to describe an error, flaw, mistake, failure, or fault in the Hardware or an Application program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. We can call an error by any of the names.

Ravinder Puranam Q: Difference between Functional and non-functional testing? A: Functional testing refers to activities that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of "can the user do this" or "does this particular feature work". Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or other performance, behavior under certain constraints, or security. Non-functional requirements tend to be those that reflect the quality of the product, particularly in the context of the suitability perspective of its users Q: What are Testing methods?? A: Software testing methods are traditionally divided into white- and black-box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases. White box testing is when the tester has access to the internal data structures and algorithms including the code that implement these. Types of white box testing The following types of white box testing exist: * API testing (application programming interface) - testing of the application using public and private APIs * Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once) * Fault injection methods - improving the coverage of a test by introducing faults to test code paths * Mutation testing methods * Static testing - White box testing includes all static testing Black box testing Main article: Black box testing Black box testing treats the software as a "black box"without any knowledge of internal implementation. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, exploratory testing and specification-based testing. Specification-based testing: Specification-based testing aims to test the functionality of software according to the applicable requirements. Thus, the tester inputs data into, and only sees the output from, the test object. This level of testing usually requires thorough test cases to be provided to the tester, who then can simply verify that for a given input,

Ravinder Puranam the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case. Specification-based testing is necessary, but it is insufficient to guard against certain risks. Advantages and disadvantages: The black box tester has no "bonds" with the code, and a tester's perception is very simple: a code must have bugs. Using the principle, "Ask and you shall receive," black box testers find bugs where programmers do not. On the other hand, black box testing has been said to be "like a walk in a dark labyrinth without a flashlight," because the tester doesn't know how the software being tested was actually constructed. As a result, there are situations when (1) a tester writes many test cases to check something that could have been tested by only one test case, and/or (2) some parts of the back-end are not tested at all. Therefore, black box testing has the advantage of "an unaffiliated opinion", on the one hand, and the disadvantage of "blind exploring", on the other. Grey box testing Grey box testing (American spelling: gray box testing) involves having knowledge of internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey box, because the input and output are clearly outside of the "black-box" that we are calling the system under test. This distinction is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. However, modifying a data repository does qualify as grey box, as the user would not normally be able to change the data outside of the system under test. Grey box testing may also include reverse engineering to determine, for instance, boundary values or error messages. Q: What is Acceptance testing? A: Acceptance testing can mean one of two things: 1. A smoke test is used as an acceptance test prior to introducing a new build to the main testing process, i.e. before integration or regression. 2. Acceptance testing is performed by the customer, often in their lab environment on their own hardware, is known as user acceptance testing (UAT). Acceptance testing may be performed as part of the hand-off process between any two phases of development. Q: What is Alpha and Beta Testing? A: 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.

Ravinder Puranam 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 Q: What is Bug Life Cycle? A: A Bug Life Cycle is defined in the below picture:

Bug status description: These are various stages of bug life cycle. The status caption may vary depending on the bug tracking system you are using. 1) New: When Tester / QA files New bug. 2) Open: Once the Tester files a New bug and is opened by the project lead or manager or any authorized person of the project. Then the bug is in Open state 3) Assign: Assigned to field is set by project lead or manager and assigns bug to developer, then the bug is in Assigned state 4) Rejected/Invalid: Sometimes developer or team lead can mark the bug as Rejected or invalid if the system is working according to specifications and bug is just due to some misinterpretation. This can also arise when the bug is non reproducible, then it is stated as

Ravinder Puranam Could not reproduce: If developer is not able to reproduce the bug by the steps given in bug report by Tester / QA then developer can mark the bug as CNR. QA needs action to check if bug is reproduced and can assign to developer with detailed reproducing steps in case the bug is marked as Rejected by Developer and Bug is observed by the Tester / QA. 5) Deferred: If the bug is not related to current build or can not be fixed in this release or bug is not important to fix immediately then the project manager can set the bug status as deferred. 6) Resolved/Fixed/Verified: When developer makes necessary code changes and verifies the changes then he/she can make bug status as Fixed and the bug is passed to testing team. 7) Reopen: If QA is not satisfy with the fix and if bug is still reproducible even after fix then QA can mark it as Reopen so that developer can take appropriate action. 8) Closed: If bug is verified by the QA team and if the fix is ok and Bug / problem is solved then QA can mark bug as Closed. Sometimes developer can give information as Need more information: If developer is not clear about the bug reproduce steps provided by QA to reproduce the bug, then he/she can mark it as Need more information. In this case QA needs to add detailed reproducing steps and assign bug back to developer to fix.

** Most of the other questions if any in an interview will be related to project and project related testing.