Testing Interview Questions

What is a Test Plan?

A Test Plan is a document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks and who will do each task (roles and responsibilities) and any risks and its solutions.

What does test plan include

What does it include? A Test Plan includes Heading, Revision History, Table of Contents, Introduction, Scope, Approach, Overview, different types of testing that will be carried out, what software and hardware will be required, issues, risks, assumptions and sign off section

What is a Test Case? What does it include?

A Test Case is a document that describes step by step process how to test the application. A Test Case includes Test Case ID, Steps Description, Expected Output, Actual Output, Pass/Fail, Remarks

Did you have a situation where you did not have any documents (no requirement document, no Use Cases, or no Design Document) and you had to write the Test Cases? How did you write the Test Cases?

Yes. I have been to that kind of scenarios several times. There were companies where they had no documents at all. In that case, I had to discuss the application scenario and functionalities with the Business Analysts or developer. I kind of prepared a document in consultation with Business Analysts and Developers and then started writing Test Cases

Can you tell me what a Use Case is

A use case is a document that describes the user action and system response for a particular functionality. (you can also include, For example, in the Use Case given below, is a Use Case for login system for a company called Auto Parts One. This application is being developed by Digital Systems, Inc. The project name is Auto Parts One. However, the business owner (user) is a company called American Auto Parts of the North (imaginary name).

What is a Use Case and what does it include

A Use Case is a document that describes the user action and system response for a particular functionality. It includes cover page, Revision History, Table of Contents, Floe of Events (normal flow and alternative flow), Exceptions, Special Requirements, Pre-conditions and Post-conditions.

What is Software Development Life Cycle

The systems (or software) development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

It includes the following different stages:

1. Requirement phase
2. Design phase
3. Coding (programming)
4. Testing
5. Release (Production)
6. Maintenance (Support)

What is Business Requirement Document (BRD)?

It is a document that describes the details of the application functionalities which is required by the user. This document is written by the Business Analysts.

What is Software Testing Life Cycle (STLC)?

The testing of software has its own life cycle. It starts with study and analyzing the requirements. Here is the software testing life cycle:

1. Requirement Study
2. Test Planning
3. Writing Test Cases
4. Review the Test Cases
5. Executing the Test Cases
6. Bug logging and tracking
7. Close or Reopen bugs

What is meant by Walk-thru meeting?

Before start working in a module and/or after accomplishing the testing of a module, the tester calls a meeting to disseminate his findings or to share his queries to other tester or leads of the company working on the same application that is called the Walk-thru meeting.

What is Build?

When each of the different modules of software is prepared, they are put in a single folder by the Configuration Management Team (CMT) and it is called the 'Build'. In other word, the developers put their code in the shared location (folder) and all those code (modules) are combined together so that it is a complete application that works.

What is meant by the Build Deployment?

When the Build so prepared by the CMT is sent to different Test Environments, it is called the Build Deployment.

What is Test Strategy?

A test strategy is an outline that describes the testing portion of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.

Are Test Plan and Test Strategy same type of document?

No. They are different documents. Test Plan is a document that collects and organizes test cases by functional areas and/or types of testing in a form that can be presented to the other teams and/or customer where as the Test Strategy is the documented approach to testing. Test Plan is prepared by the tester whereas the Test Strategy is prepared by the QA Manager or QA lead.

What is Negative Testing?

Testing the system or application using negative data is called negative testing, for example, testing password entering 6 characters where it should be 8 characters should display a message.

When we test an application by putting negative values (instead of actual values), then the system should not allow the other values rather than the actual value. The system should give an message that the value is not correct. This is called negative testing.

What is the difference between Load Testing and Performance Testing

Basically Load, Stress and Performance Testing are the same. However, Load testing is the test to check the users' response time of number of users of any one scenario of the application whereas Performance Testing is the test to check the user response time for multiple scenario of the same application

What is SQL?

SQL stands for Structured Query Language. SQL is an ANSI (American National Standards Institute) standard computer language for accessing and manipulating database systems. SQL statements are used to retrieve and update data in a database. SQL works with database programs like MS Access, DB2, Informix, MS SQL Server, Oracle, Sybase, etc.

What is a Primary Key?

In a database table, the Primary Key is a column which has a unique value for each of the row within that column. It can't have NULL value.

What is a Unique Key?

In a database table, the Unique Key is a column which may or may not have null value of each of the row within that column.

What is Backend Testing

It is a test to check whether the data displayed in the GUI front end report format matches with the particular data in the original database.

What is XML?

-XML stands for EXtensible Markup Language.
-XML is a markup language much like HTML.
-XML was designed to describe data.

Where do you see yourself in another 5 years

Answer: I see myself a QA Lead in another 5 years.
(You can also say "QA Manager", but since the QA Manager is taking your interview most of the time, they some times feel challenged. Therefore, it might be a good idea to limit you to QA Lead)

Why are you in QA?

Answer: I like this job, because it is process oriented. Meaning that I get an opportunity to work from analyzing the requirement documents to writing test plans, test cases, testing the application, logging defects, retesting, preparing reports and finally testing in production as well. Therefore, I am involved from the very beginning to the end of the software development life cycle (SDLC) process. I like this.
Another reason is I like to find defects. I enjoy logging defects. The more defects I find, the happier I am

If you have no documentation about the product, how do you test an application? Describe the process.

Answer: Well, this is a situation where I have come across several times. Some of the companies in my previous projects did not have any documents. In this case, I went to the Business Analyst and some times to developers to find out how exactly the functionalities work, how to navigate from one page to another page and so on. After getting a clear vision, I write test cases based on the conversation (which is a step by step procedure to test an application) and get ready for testing.

How do you make sure that it is quality software?

Answer: There is a certain process how the quality of software is guaranteed (ensured). If is defined by the 'exit criteria'. (What it means is, a QA Manager writes a document called Test Strategy. This Test Strategy defines the 'exit criteria'.) Exit Criteria gives the measurement, for example, in order to confirm the quality, how many critical defects, high defects, medium defect and low defect are acceptable? These are all defined in the exit criteria. (Normally in practice, for a quality software, there should no critical defects (0 critical), no high defect (0 high), no medium defect (0 medium) and may be 1 low defect

Let us say you have a web application to test. How do you go about testing it? What is the process?

Answer: First of all, I will look at the requirement documents (or design document in some companies). The requirement document will tell us what the functionalities in the application (software) are. Once I analyze the requirement documents (one module=one requirement document). After that, I will write test plans for each module (one module =one test plan). Then after the test plan is complete, I will write test cases (One module can have hundreds, even thousands test cases). Once the test cases are ready and the application is ready (or once the build is ready), then I will start testing. Before I start testing, however, I will make sure the test environments, test data and defect logging tools are in place. This is how I will go about testing an application

How would you ensure that you have covered 100% testing

Answer: The testing coverage is defined by exit criteria (There is exit criteria and entry criteria in the Test Strategy). For example, if the exit criteria says "The software will be acceptable to the client only if there are no critical defects, no high defects, no medium defects and only two low defects", then all the critical, high, medium should be zero. Only 2 low defects are acceptable. Thus, 100% coverage is measured by the exit criteria. Also, 100% test cases must be executed in order to cover 100% of testing.

What are the different tests that can be done for Client Server Application and Web-based Application. Give details.

Answer: For both client server and web based applications, the testing is the same except one thing: We test web based applications in different browsers, for example, Internet Explorer (will test in different versions like IE 5.0, IE 6.0, IE 7.0), Firefox, Safari (for Mac) and so on where as for client server, we don't need to test in the browsers.

What are your strengths?

Answer: I am a very detailed oriented person. I have the sense of urgency. I can prioritize my job according to the deadline. I am very much dedicated towards my job. I am honest. I have the skills and expertise in QA process. These are some of my strengths

What is your weakness?

Answer: I think my weakness is that whenever I am given some responsibilities and there is a deadline for it, I work day and night, 7 days a week. This is probably bad for my family life, but I can't sleep unless I am done with my assignments.
(Note: You should think of your weakness where because of your weakness (like the one above), still the employer benefits. DON'T SAY anything negative thing, like "I cannot work long hours, it is hard for me pick up things, it is difficult for me to understand requirement documents etc)

What is an Exploratory Testing?

Exploratory testing often performed as a black box testing technique, the tester learns things that together with experience and creativity generate new good tests to run.

Benefits:

Following are the benefits of Exploratory Testing:

·        Exploratory testing takes less preparation.

·        Critical defects are found very quickly.

·        The testers can use reasoning based approach on the results of previous results to guide their future testing on the fly.

=>In test purpose test planning one of the important part. 
Here discuss about test planning.

Test Planning    

                                     

  Introduction     

      

Software testing is a formal process carried out by a committed testing team in which a piece of software, parts of software or even multiple pieces of software are examined to detect differences between existing and required conditions. Testing is the single biggest Software Quality Assurance task with most projects allocating just under a quarter of their budget to this section alone. If successful, testing should find and eradicate any problems that arise with the relevant software. There many different types of software testing including many contrasting methodologies. Therefore, each software development project requires a substantial investment in planning. Therefore, test planning is essential in ensuring testing identifies and reveals as many errors in the software as possible, brings software to an acceptable level of quality and is efficient regarding budgetary and scheduling limitations. ANSI/IEEE Standard for Software Test Documentation defines Test Planning as “a document describing the scope, approach, resources and schedule of intended testing activities”. In this report, I will define what is involved in test planning, following the IEEE 829 Test Plan Standard.

Test planning is an ongoing process throughout the project lifecycle with test plans being developed for each phase of software development. These plans include Acceptance, Integration and Unit test plans. A software test plan enables the mapping of tests to the software requirements and defines the entry and exit criteria for each phase of testing. Test planning is one of the most important factors in successful software testing, yet it’s frequently omitted. Pressure to begin coding, or scheduling problems are often the villains behind test planning absence. Without detailed planning, issues are certain to arise when testing proceeds. Issues such as ignorance of software problems, breaching financial and scheduling limits and contrasts in expected quality and end quality. Effective test planning is very important in the software development lifecycle, “The plan is nothing, the planning is everything” Dwight D. Eisenhower

     Level of Test Plan

The level of test plan defines what the test plan is being created for e.g. subsections of test planning. There are various levels of test planning that are specific to their own purposes. A Master Test Plan is an overall test plan document that is considered to be one the “major communication channels with all project participants” Mustafa Khan (2007). It is therefore written in a managerial style to define and explain the plan for the software testing. As there are many different types of software testing, such as Integration, Unit, Regression and Acceptance testing, the level of test plan is important to identify in terms of what the document will contain and hope to achieve. A specific test plan must exist for whatever level of testing is to proceed. The author(s) of a Test Plan differ depending on the level. For example, A Master Test plan may be co-written by all project participants, while a more technical test plan such as a Unit Test plan may be written by developers and testers only. The author(s) of test plans differ on the relevant knowledge needed for the specific content of that test plan.

 

  Test Plan Structure

All test plans follow the same structure defined by the IEEE 829 standard, and differ only in content and detail. In this section the report will state and specify the typical structure of a test plan document, detailing all the information that applies to each category.

Test Plan Identifier

A test plan document will commence with a unique test plan identifier. This will be a company generated number to identify the individual test plan, its test level and the level of software it is related to. This unique identifier may also identify whether the test plan is a Master test plan, an Integration test plan, etc. The aim of the identifier is to assist in coordinating software and test ware versions. As a test plan is a software document, revision numbers of the test plan are also stated in this section.

Identifying Test Items

Identifying the test items is a section that basically specifies the things that are to be tested within the scope of this test plan, i.e. functions of the software in question. It is essentially a list of what is to be tested developed from the software requirements stated in the design section of the SDLC. Software and hardware needed for testing will also be listed here, along with other test materials and participating organizations. 

Software Risk Issues

All risks associated with the software and its testing need to be identified in this section. This could include complex functions, new versions of cooperating software, etc. There are some inherit software risks such as complexity, that need to be identified.  These include such risks as safety, client impact and government regulations. Misunderstanding of the original requirements is also a risk that should be considered with test planners being aware of vague, unclear or non-testable requirements.

Features to be Tested

This section identifies the features to be tested from a user’s point of view. It differs significantly in comparison to “Identifying Test Items” (3.2.) in the fact it is not a technical description of the software but a user’s view of the functions. A test planner should identify the level of risk for each function in an understandable manner i.e. High, Medium and Low. The test planner should also discuss why this level was chosen. This section in effect is a basic description of features that will be included in testing.

Features not to be Tested

This section lists the features not to be included in the testing process, identifying the reason behind its exclusion. This section is directly related to previous and future sections (3.3. and 3.13.), with what will and will not be tested being directly affected by levels of acceptable risk within the project. If a feature does not get tested it affects the level of risk of the project.

        Reasons why a feature may be omitted from testing could be that it has been used before and deemed stable or that it may not be intended to be included in the release of the software.

Test Approach

This section identifies the strategy for this test plan, differing depending on the level of test plan. The approach stated should be appropriate and in agreement with all higher and lower levels of test plans. Overall rules and processes are identified here including such aspects as the use of automated testing tools. If this is the Master Test Plan, the overall testing approach and coverage requirements must also be identified. The level of detail of this section differs depending on the level of test plan. For example, a Unit test plan will go into much detail on individual unit tests and test data.

Test Pass/Fail Criteria

This section identifies the pass and fail criteria appropriate to this test plan. For a Unit test plan, this section would involve such criteria as:

-          All test cases completed

-          A specified percentage of cases completed with a percentage containing some number of minor defects.

-          Automated testing tools indicated all lines of code covered.

A Master test plan may include:

-          All lower level test plans completed

-          A specified number of test plans completed without errors and a percentage with minor defects.

A successful test plan should give a clear understanding of when the project can or cannot proceed.

Suspension Criteria

A suspension criterion involves identifying when pausing during a series of tests is necessary. For example, if the number of defects reaches a point where the follow on testing has no value, it makes no sense to continue the test and waste resources. A test planner should specify what constitutes stoppage for a test and what is an acceptable number of defects to allow testing to continue. This role of go/no go decisions should be specified to a member of the testing team later in the test plan.

Test Deliverables

This section is used to specify what is to be delivered as part of this test plan. This section would identify such features as test plan documentation, test cases, testing tools and their outputs, simulators, error logs, problem reports and their corresponding corrective actions. One thing that is not a test deliverable is the software itself. The software is listed under test items and is delivered by development.

 Environmental Requirements

Environmental requirements will state any special requirements for this test plan. This will include necessary hardware and software required for testing to proceed. Descriptions of how test data will be provided and the level of testing on each component should also be listed. Environmental requirements will describe everything needed for testing to proceed in some location. Documenting the physical components required for test execution helps to identify potential gaps in what is required and what actually exists. The test environment should be identified in detail including such as aspects as security and configurations.

 Staffing and Training Needs

This section identifies all personnel and hierarchies relevant to the test plan. This includes such questions as who is in charge. This includes all areas of the plan such as setting risks, selecting testing and non-testing features, scheduling and most importantly critical go/no go decisions.

If necessary, testing teams are organised and stated in this section. For example, three teams involving a team leader and four testers per team. All relevant training needs are also stated in this section e.g. training needed to operate testing tools or handle special test data. 

 Schedule of Test

Scheduling should be based on realistic and validated estimates for software testing. Milestones should be identified with schedules being specified for each milestone. Scheduling should provide management with an explicit representation of all test activities. Key phases and milestones should be discussed in relation to quality assurance, commenting on standards and testing goals. Depending on the level of test, the size of this section will differ, e.g. Master test plan will involve all the test plan schedules below it making it fairly large.

It is always best to tie all test dates directly to their related development activity dates. This prevents the test team from being blamed for delays if they occur. This is called dependant/relative dating. 

Planning for Risks and Contingencies

This section aims to identify the overall risks to the project with an emphasis on the testing process. This could be such problems as lack of personnel resources when testing is to begin. Another example could be the lack of availability of requirements, software, hardware, etc. The section should in turn identify how to plan for risks stated earlier in the test plan. This will involve procedures to counteract if possible problems to arise. For example, with regards to lack of personnel, a solution such as using a member of a test team as an administrative employee could solve this possible problem.

   Approvals

Approvals states who can consent a process as complete and allow the project to proceed to the next stage. This depends on the level of test plan and can differ from a test team leader to a more executive employee. At the Master test plan this may involve all parties connected to the project. When determining the approval process, a test planner must keep in mind who the audience is. The type of knowledge at each level of test plan differs significantly. For example, programmers may understand the technical side of software but not the managerial or business side.

 

   Conclusion

Test planning is an essential phase of the SDLC providing detailed information about how to approach and conclude the testing of software. Testing is one of the most important phases of the SDLC, accounting for a large portion of the software’s budget. Without a detailed test plan, an end product can be bug ridden and in turn unsuccessful. Detailed test planning will ensure problems are dealt with if they arise, be it software problems or test problems. With levels of test plan providing different levels of information, developers can ensure successful testing of a product. Such a systematic approach as specified by the IEEE 829-1998 Test Plan Structure, provides developers with software specific categories to guarantee a successful software testing stage.