Cste Model Questions

Subjective paper: 1 Your client has not done acceptance testing in the past, but is fully aware of the benefits of the same. He is asking you about the contents that should go into the acceptance test plan. What would you suggest? - 10 points 2.Give examples and define the following: (1) Equivalence partioning (2) Boundary values and (3) Error guessing - 15 points 3. You are developing an e-commerce application for the first time. Knowing well that the same cannot be validated on all the browsers and operation system versions, what will be measure taken by you in the test plan to provide adequate confidence that the application would work satisfactorily. -10 points 4. Define the standards for the following: a. Test plan b. Test scripts and c.Test Report -15 points 5.You have estimated a testing phase of 4 weeks in your test plan. Due to changing requirements, the development team delays the handoff to you (the testing team) by a week. But your final shipment date is the same. Without change in any of the other resources (man power, or any other resource), what would you do in order to cater to the situation (one week less for testing). - 15 points. 6. Why should you test the application? - 15 points 7. Testing is costly for any organisation. You feel that the organistation is emphasising on testing more and infact all the applications are overtested. What are the symptoms/consequences that makes you sure that the application is overtested? - 15 points 8. You are working on a project, where the requirements change dynamically. The data in the project comes from various ends (from various platforms) and are interdependent.You see this as a big risk in the project. How would you plan accordingly ? - 35 points 9. a. What would be the Test objective for unit testing b. What would be the quality measurements to assure that unit testing is complete? c. (Not sure)- One more aspect of Unit testing. -15 points 10. Define and explain any three aspects of Code review? - 15 points 11 How would you measure the following? a. Test Effectiveness b. Test Efficiency

- 10 points 12. You are given two scenarios to test. Scenario 1 has only one terminal for entry and processing whereas scnerio 2 has several terminals where the data input can be made. Assuming that the processing work is the same, what would be the specific tests in Scenario2 that you would do, which you would not carry on scenario 1. - 15 points. -------------------------------------------------------------------Objective questions: There were 48 objective questions in the first paper and 50 questions in the second paper . All of them were from the CBOK guide. Read the book throughly and you can be able to answer them: Some of them releates to these: 1. Testing is least costly in the REQUIREMENTS phase. 2. Black box testing - Functional requiremnts (Match the following) 3. White box testing - Logical testing(Match the following) 4. Test plan- Match the following (with appropriate definition) 5. Test objective- Match the following (with appropriate definition) 6. Test data - Match the following (with appropriate definition) 7. COQ comprises of ------8. Training forms ------- phase of COQ. 9. Testing accounts for ------ percent of the system development cost. 10. A requirement defect found at production is ------- times costly to correct (The choices are 5, 10,50 and 500 times) 11. Which is not a testing risk - 4 choices were given. 12. Which is not a sofware risk - 4 choices were given. 13. Integration testing occurs when - 4 choices were given. 14. Which should not be done during Constructive criticism - 4 choices were given. 15. The objective of closing the proposal should be ----------16. Critical listening is ----- (four choices were given) 17. If there was a conflict, what would you do (All the subheadings in the CBOK for conflict resolution were given as choices and there was choice named "All the above"). 18. Juran was famous for what ----- (four choices ) 19. Pareto analysis is also called ----- (one of the choices was 20-80 rule) 20. The enitity to improve the testing process methodologicies - four choices (Quality Assurance) 21. The responsibilty of testing lies on ---22. Which is not a Tool ( the choices were checklist, test plan, .....) 23. About 60% of the total defects origniate from Requiements phase (True/False) 24. Match the following: (For the follwing definitions): 1. Incremental Testing 2. Thread Testing 3. Test Data... 25. Out of the 5 perceptives of Quality, What is the perceptive which acounts for "Fitness for use" 26.Incremental testing can be done in two ways. a. Top down and b. Bottom Up (True/False) 27. Which of the following about testing is True (The choices were like Testing is easy. Testing does not require any skill) etc. 28. Which of the following is NOT the seconday item for a tester ( 4 choices were given) 29. Three questions on In process reviews

30. One question of phase end review. 31. Which is the important Test objective for Unit testing? 32. Which of the following is a Structural Tesing? 33. Configuartion management includes ---- (The choices were like done only after development, only after coding , through out all the phases etc) Courtesy : R Anand (quoted from his memory after writing the exam)

Testing related Q&A What makes a good test engineer? •

A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail.

•

Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful.

•

Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers' point of view, and reduce the learning curve in automated test tool programming.

•

Judgement skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.

What makes a good software QA engineer? •

The same qualities a good tester has are useful for a QA engineer.

•

Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization.

•

Communication skills and the ability to understand various sides of issues are important.

•

In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed.

•

An ability to find problems as well as to see 'what's missing' is important for inspections and reviews.

What makes a good QA or Test manager? •

A good QA, test, or QA/Test (combined) manager should:

•

be familiar with the software development process

•

be able to maintain enthusiasm of their team and promote a positive atmosphere, despite what is a somewhat 'negative' process (e.g., looking for or preventing problems)

•

be able to promote teamwork to increase productivity

•

be able to promote cooperation between software, test, and QA engineers

•

have the diplomatic skills needed to promote improvements in QA processes

•

have the ability to withstand pressures and say 'no' to other managers when quality is insufficient or QA processes are not being adhered to

•

have people judgement skills for hiring and keeping skilled personnel

•

be able to communicate with technical and non-technical people, engineers, managers, and customers.

•

be able to run meetings and keep them focused

What's the role of documentation in QA? • Critical. (Note that documentation can be electronic, not necessarily paper.) • QA practices should be documented such that they are repeatable. • Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented. • There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. • Change management for documentation should be used if possible. What's the big deal about 'requirements'? • One of the most reliable methods of insuring problems, or failure, in a complex software project is to have poorly documented requirements specifications. • Requirements are the details describing an application's externally-perceived functionality and properties. • Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). • A testable requirement would be something like 'the user must enter their previously-assigned password to access the application'. • Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project. • Many books are available that describe various approaches to this task. • Care should be taken to involve ALL of a project's significant 'customers' in the requirements process. • 'Customers' could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. • Anyone who could later derail the project if their expectations aren't met should be included if possible. • Organizations vary considerably in their handling of requirements specifications. • Ideally, the requirements are spelled out in a document with statements such as 'The product shall.'. • 'Design' specifications should not be confused with 'requirements'; design specifications should be traceable back to the requirements. • In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. • No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. • Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly. What steps are needed to develop and run software tests? The following are some of the steps to consider: •

Obtain requirements, functional design, and internal design specifications and other necessary documents

•

Obtain budget and schedule requirements

•

Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)

•

Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests

•

Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc. •

Determine test environment requirements (hardware, software, communications, etc.)

•

Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)

•

Determine test input data requirements

•

Identify tasks, those responsible for tasks, and labor requirements

•

Set schedule estimates, timelines, milestones

•

Determine input equivalence classes, boundary value analyses, error classes

•

Prepare test plan document and have needed reviews/approvals

•

Write test cases

•

Have needed reviews/inspections/approvals of test cases

•

Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data

•

Obtain and install software releases

•

Perform tests

•

Evaluate and report results

•

Track problems/bugs and fixes

•

Retest as needed

•

Maintain and update test plans, test cases, test environment, and testware through life cycle

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 process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project: •

Title

•

Identification of software including version/release numbers

•

Revision history of document including authors, dates, approvals

•

Table of Contents

•

Purpose of document, intended audience

•

Objective of testing effort

•

Software product overview

•

Relevant related document list, such as requirements, design documents, other test plans, etc.

•

Relevant standards or legal requirements

•

Traceability requirements

•

Relevant naming conventions and identifier conventions

•

Overall software project organization and personnel/contact-info/responsibilties

•

Test organization and personnel/contact-info/responsibilities

•

Assumptions and dependencies

•

Project risk analysis

•

Testing priorities and focus

•

Scope and limitations of testing

•

Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable

•

Outline of data input equivalence classes, boundary value analysis, error classes

•

Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems

•

Test environment setup and configuration issues

•

Test data setup requirements

•

Database setup requirements

•

Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs

•

Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs

•

Test automation - justification and overview

•

Test tools to be used, including versions, patches, etc.

•

Test script/test code maintenance processes and version control

•

Problem tracking and resolution - tools and processes

•

Project test metrics to be used

•

Reporting requirements and testing deliverables

•

Software entrance and exit criteria

•

Initial sanity testing period and 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.

What's a 'test case'? •

A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly.

•

A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.

•

Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it's useful to prepare test cases early in the development cycle if possible.

What should be done after a bug is found? The bug needs to be communicated and assigned to developers who can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available . The following are items to be considered in the tracking process: •

Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.

•

Bug identifier (number, ID, etc.)

•

Current bug status (e.g., 'Released for Retest', 'New', etc.)

•

The application name or identifier and version

•

The function, module, feature, object, screen, etc. where the bug occurred

•

Environment specifics, system, platform, relevant hardware specifics

•

Test case name/number/identifier

•

One-line bug description

•

Full bug description

•

Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool

•

Names and/or descriptions of file/data/messages/etc. used in test

•

File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem

•

Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)

•

Was the bug reproducible?

•

Tester name

•

Test date

•

Bug reporting date

•

Name of developer/group/organization the problem is assigned to

•

Description of problem cause

•

Description of fix

•

Code section/file/module/class/method that was fixed

•

Date of fix

•

Application version that contains the fix

•

Tester responsible for retest

•

Retest date

•

Retest results

•

Regression testing requirements

•

Tester responsible for regression tests

•

Regression testing results

A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers. What is 'configuration management'? Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes.

What if the software is so buggy it can't really be tested at all? The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules, and indicates deeper problems in the software development process (such as insufficient unit testing or insufficient integration testing, poor design, improper build or release procedures, etc.) managers should be notified, and provided with some documentation as evidence of the problem. How can it be known when to stop testing? This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are: •

Deadlines (release deadlines, testing deadlines, etc.)

•

Test cases completed with certain percentage passed

•

Test budget depleted

•

Coverage of code/functionality/requirements reaches a specified point

•

Bug rate falls below a certain level

•

Beta or alpha testing period ends

What if there isn't enough time for thorough testing? Use risk analysis to determine where testing should be focused. Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgement skills, common sense, and experience. (If warranted, formal methods are also available.) Considerations can include: •

Which functionality is most important to the project's intended purpose?

•

Which functionality is most visible to the user?

•

Which functionality has the largest safety impact?

•

Which functionality has the largest financial impact on users?

•

Which aspects of the application are most important to the customer?

•

Which aspects of the application can be tested early in the development cycle?

•

Which parts of the code are most complex, and thus most subject to errors?

•

Which parts of the application were developed in rush or panic mode?

•

Which aspects of similar/related previous projects caused problems?

•

Which aspects of similar/related previous projects had large maintenance expenses?

•

Which parts of the requirements and design are unclear or poorly thought out?

•

What do the developers think are the highest-risk aspects of the application?

•

What kinds of problems would cause the worst publicity?

•

What kinds of problems would cause the most customer service complaints?

•

What kinds of tests could easily cover multiple functionalities?

•

Which tests will have the best high-risk-coverage to time-required ratio?

What if the project isn't big enough to justify extensive testing? Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the same considerations as described previously in. The tester might then do ad hoc testing, or write up a limited test plan based on the risk analysis. What can be done if requirements are changing continuously? A common problem and a major headache. •

Work with the project's stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.

•

It's helpful if the application's initial design allows for some adaptability so that later changes do not require redoing the application from scratch.

•

If the code is well-commented and well-documented this makes changes easier for the developers.

•

Use rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes.

•

The project's initial schedule should allow for some extra time commensurate with the possibility of changes.

•

Try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the 'Phase 1' version.

•

Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application.

•

Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted - after all, that's their job.

•

Balance the effort put into setting up automated testing with the expected effort required to re-do them to deal with changes.

•

Try to design some flexibility into automated test scripts.

•

Focus initial automated testing on application aspects that are most likely to remain unchanged.

•

Devote appropriate effort to risk analysis of changes to minimize regression testing needs.

•

Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans)

•

Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this entails).

What if the application has functionality that wasn't in the requirements? It may take serious effort to determine if an application has significant unexpected or hidden functionality, and it would indicate deeper problems in the software development process. If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only effects areas such as minor improvements in the user interface, for example, it may not be a significant risk. How can Software QA processes be implemented without stifling productivity? By implementing QA processes slowly over time, using consensus to reach agreement on processes, and adjusting and experimenting as an organization grows and matures, productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection, panics and burn-out will decrease, and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings, and promote training as part of the QA process. However, no one especially talented technical types - likes rules or bureacracy, and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug-fixing and calming of irate customers. What if an organization is growing so fast that fixed QA processes are impossible? This is a common problem in the software industry, especially in new technology areas. There is no easy solution in this situation, other than: •

Hire good people

•

Management should 'ruthlessly prioritize' quality issues and maintain focus on the customer

•

Everyone in the organization should be clear on what 'quality' means to the customer

How does a client’server environment affect testing? Client/server applications can be quite complex due to the multiple dependencies among clients, data communications, hardware, and servers. Thus testing requirements can be extensive. When time is limited (as it usually is) the focus should be on integration and system testing.

Additionally, load/stress/performance testing may be useful in determining client/server application limitations and capabilities. There are commercial tools to assist with such testing. How can World Wide Web sites be tested? Web sites are essentially client/server applications - with web servers and 'browser' clients. Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.). Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort. Other considerations might include: • What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). • What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)? • Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)? • What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)? •

Will down time for server and content maintenance/upgrades be allowed? how much?

• What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested? • How reliable are the site's Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing? • What processes will be required to manage updates to the web site's content, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.? • Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers? • Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site?? •

How will internal and external links be validated and updated? how often?

• Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet 'traffic congestion' problems to be accounted for in testing? • How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?

• How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested? • Pages should be 3-5 screens max unless content is tightly focused on a single topic. If larger, provide internal links within the page. • The page layouts and design elements should be consistent throughout a site, so that it's clear to the user that they're still within a site. • Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type. •

All pages should have links external to the page; there should be no dead-end pages.

• The page owner, revision date, and a link to a contact person or organization should be included on each page. How is testing affected by object-oriented designs? Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well-designed this can simplify test design. What is Extreme Programming and what's it got to do with testing? Extreme Programming (XP) is a software development approach for small teams on risk-prone projects with unstable requirements. It was created by Kent Beck who described the approach in his book 'Extreme Programming Explained' . Testing ('extreme testing') is a core aspect of Extreme Programming. Programmers are expected to write unit and functional test code first - before the application is developed. Test code is under source control along with the rest of the code. Customers are expected to be an integral part of the project team and to help develop scenarios for acceptance/black box testing. Acceptance tests are preferably automated, and are modified and rerun for each of the frequent development iterations. QA and test personnel are also required to be an integral part of the project team. Detailed requirements documentation is not used, and frequent re-scheduling, re-estimating, and re-prioritizing is expected

1.

You are appointed Quality Assurance Manager. Your IT Director wants you to do the testing and Quality Control review. How would you tell/convince your IT Director that this is not your responsibility as a Quality Assurance Manager. ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________ 2.

Your operational department encounters production defect at the rate of 3 defects per 1000 lines of code. During a vendor meet you come across another company XYZ which is of the size of yours and in the same industry. This company’s production defect is 2 defects per 1000 lines of code. Can you conclude that the XYZ’s operational department is better than yours? Can you use this for benchmarking? Explain. ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________ 3.

List the measure/matrices you would use for the following: i. Software Reliability ii. Productivity iii. Process Improvement iv. Customer satisfaction

Note: Answer the following cases in not more than 5 lines. The answers can be bulleted with the stated assumptions: ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ __________________________________________________________________________ 4. Plan a test organization for testing mission critical, time critical software. ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________.

5. As a consultant to an organization involved in handling large software projects, how would you impress on the management on the need for structured testing? ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______.

6. You are project leader of a team working on software for customer with changing requirements. How would you plan the project? ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______.

7. You are heading Quality Control Team in testing a life critical software development project. What will be your approach to testing and when would you advice to stop testing? ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________ 8.

Your project is in a tight schedule and time available is very less. List major areas you will test in such a situation. The test team does not know when to stop testing. Please recommend suitable action. ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ______________________________________________________________________________________ ___________________. 9.

One of the customer called the help desk and told that there is a problem in the software and the system is not working. The help desk referred the problem to you. How will you go about handling it.

__________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________________________________________________________ __________________________________ 10. Give examples and define the following: (1) Equivalence partioning (2) Boundary values and (3) Error guessing

1.

Decision/branch coverage strategy : a) always satisfies statement coverage b) is used in black box testing c) means that every branch direction is traversed atleast once d) is the same as condition coverage

Match the following 2. Retesting modules connected to the changed program - Black box testing 3. Determines how well the user can interact with the system - White box Testing 4. Demonstrates key functional capabilities by testing a string - System Testing of units 5. Path or Logic in a unit or program is known - Regression Testing 6. Testing the functions of the program against the specifications - Thread Testing 7. Test all the integrated components of an information system - Usability Testing 8.

Explain with examples : Equivalence Partitioning, Boundary analysis, Error guessing

9.

Incremental testing can be done in two ways. a. Top down and b. Bottom Up (True/False)

10. Joe is performing a test to see that it complies with the user requirement that a certain field be populated, by using a dropdown containing a list of values. Joe is performing: a. White-box testing b. Black Box testing c. Load Testing d. Regression testing 11. Acceptance testing means a. Testing performed on a single stand-alone module or unit of code b. Testing after changes have been made to ensure that no unwanted changes were introduced c. Testing to ensure that the system meets the needs of the organization and the end user 12. The purpose of software testing is to : a. Demonstrate that the application works properly b. Detect the existence of defects c. Validate the logical design 13. Integration testing occurs when a. The system is ready to use b. Interfaces between unit-tested programs needs to be tested c. When testing client/server applications d. Testing the functions of the program against the specifications 14. In Management directive, IT management convenes a group of the more senior and respected individuals in the dept. to develop a policy jointly (T/F) 15. Boundary value testing : a. Is the same as equivalence partitioning tests b. Is used in white-box testing strategy c. Tests combination of input circumstances d. Test conditions on, above and below edges of input and output equivalence classes 16. Bottom-up testing requires the development of interim stubs for test input (T/F) 17. Defects and Issues are identified and corrected during reviews (T/F)

18. The primary responsibility of individuals accountable for testing activities is a. To find out defects b. To understand the system c. to ensure that quality is measured accurately d. to prove that developers are inefficient Match the following 19. Test Manager a. Prepares test Documentation b. Designs the Test strategy c. Test data planning, capture and conditioning d. All of the above 20. Test Engineer a. Manages the Test effort b. Tracks and reports Defects c. Design artifacts d. all of the above 21. 22. 23. 24.

Match the following Performed when application components near completion - In Process Review Coding begins at the close of this review - S/W requirements review Looks at identifying defects as work progresses - Critical design review CM Plan, Test plan and development plan are reviewed - Test readiness review

25. Formal reviews may be held at anytime (T/F) 26. Reviews provide training in and enforce the use of standards (T/F) 27. Verification and validation activities begin a. After development phase b. After Design phase c. At the start of the project d. Before closing the project 28. __________ activities define a specific implementation solution to solve the user’s needs a. Analysis b. Design c. Conceptualization d. Operation 29. System test plan generation and verification activity takes place during the a. Analysis Activity b. Design Activity c. Conceptualization Activity d. Operation Activity 30. Implementation activities support the use of software by the end user in an operational environment (T/F) 31. Answer in brief a. What would be the Test objective for unit testing b. What would be the quality measurements to assure that unit testing is complete? 32. S/W engineer is responsible for

a. b. c. d.

Identifying tool objectives Defining selection criteria Identifying candidate tools All of the above

33. Mention the exit criteria for Integration Test 34. Define and explain any three aspects of Code review? 35. Integration test exit criteria : a. 75-80% of total system functionality and 90% of major functionality delivered b. No open severity 1 or 2 defects c. Successful execution of integration test plan d. All of the above

Objective Test - Category III 1.

__________ is a probability that a loss will occur

2.

What are the 2 major components of risk a. b. c.

Event and Loss Probability and Loss Judgement and Instinct

Match the Following 3. Description of the condition or capability of the system 4. Document that defines the overall testing objectives 5. Identifies all steps required to exercise the test cases 6. Refines Test Approach and identifies the features to be covered by the design and its associated tests 7. Document containing the actual values for input, along with the anticipated outputs 8. Statement of what the tester is expected to accomplish during the testing activity 9.

-

Test Cases Test Objective Test Plan Test Procedures

-

Test Design

-

Requirement

Which is not a testing risk - 4 choices were given a. Budget b. Test Environment c. Portability of the system d. New Technology

10. Which is not a software risk - 4 choices were given a. Availability of Automated Tools b. System will be difficult to operate c. Programs will be unmaintainable d. Unreliable results from the system 11. ____________ % of system enhancements and repairs introduce new defects to the application a. 10-20 b. 20-40 c. 20-50 d. 50-70 12. Which of the following information will not be included in a Defect Tracking Tool a. Name of the tester who reported the defect b. Person to whom the defect is assigned c. Defect Number d. Description 13. Configuration management includes – Managing artifacts after development activity Managing artifacts after Testing activity Managing artifacts throughout all the phases 14. Requirements should include which of the following

Functionally what the program is to do b. c.

Form, format, data types and units How exceptions, errors, deviations are to be handled

d. e.

Technical architecture/target platform All of the Above

a) b) c) d)

Decision/branch coverage strategy : always satisfies statement coverage is used in black box testing means that every branch direction is traversed atleast once is the same as condition coverage

24.

25. The process used for documenting user’s requirements is known as validation (T/F) 26. Normally an efficient testing team should have atleast 10 or more objectives (T/F) 27. Testing objectives should restate the project objectives from the project plan (T/F) 28. What are the guidelines for writing a Test plan 29.

How would you measure the following? a) Test Effectiveness b) Test Efficiency

30. Environment competency is the ability to use the test environment established by test management (T/F) 31. Knowledge of the most common risks associated with software development and the platform you are working on is known as ___________ a. Testing Risk b. Software Risk c. Business Risk d. Premature Release Risk 32. Selecting the size and competency of staff needed to achieve the test plan objectives is known as _________ a. Estimating b. Scheduling c. Staffing 33. What would be the Test objective for unit testing? What would be the quality measurements to assure that unit testing is complete? Match the following 34. Stress Testing 35. Load Testing 36. Performance Testing

Testing the Response time for the transactions in an application Testing an application repeatedly over a specific time period Testing an application for n number of users

1.

If you observe one of your audience members not being able to concentrate, what would you do and why? a. Ignore him b. Ask what is troubling his mind, if you could help c. Ask him to concentrate d. Ask him to get out 2.

How can you influence someone to perform in a certain way?

3.

Give 3 reasons for why people are often not good listeners.

4.

__________ is the most common form of communication a. b. c. d.

Oral Communication Listening Verbal Communication Written Communication

5. What is the maximum amount of time you have with a complainer to begin offering solution to their complaint? a. 1minute b. 2 minutes c. 4 minutes d. 30 minutes 6. You see a programmer constantly under performing. You know he is a good worker but of late he has not been doing anything right. What would you do? a. Throw him out of the job b. Give him time, maybe he’ll turn around c. Talk to him privately and try and understand his problem, provide constructive feedback/criticism d. Scold him in front of all his co-workers; it will surely make an impression 7.

Which one of these is not a misconception about testing? a. Anyone can test and no particular skill set is required b. Testers delay a project c. Testing itself is error prone. d. Testing identifies errors and therefore puts the blame for those errors on the development organization e. Testers can test for quality at the end of the project

8.

What are the Components of Effective Listening?

9.

What is the Primary Objective of the system proposal from the Producer’s viewpoint a. To present the costs/benefits of the proposal b. To obtain an agreement for more work c. To standardize presentations

10. What type of change do u need before you can obtain a behavior change? a. Lifestyle b. Vocabulary c. Internal d. Management 11. Which one is the best tactic in constructive criticism

a. b. c. d.

Do it in public, while others are listening, so they too can learn from other peoples mistakes Be prepared to help your subordinate improve his/her performance Criticize the individual rather than the product, because the individual has created the product Explain what will happen to his career if the employee’s behavior doesn’t change

11. One of the key concepts of a task force is that the leader be an expert in leading groups as opposed to an expert in a topical area. (True/False) 12. Consensus means a. Majority rules b. You don’t have to like it, you just have to be able to accept it c. Whatever the boss says d. Compromise 13. It is normal for people to object to any new idea – (True/False) 14. Awareness training should be directed at selling benefits – (True/False) 15. Anyone who has vested interest in a topic should be invited to awareness training – (True/False) 16. The recommended course of action should be given immediately following awareness training – (True/False) 17. Awareness training is only associated with problem resolution – (True/False) 18. Change normally will not occur unless the customer’s objections are not overcome – (True/False) 19. Awareness training should not last over 2 hours – (True/False) 20. __________ is the most powerful Quality Control Tool a. Control Chart b. Pareto Analysis c. Checklist d. Histogram 21. Awareness training should follow the same general administrative procedures as any other training program conducted in the organization – (True/False 22. A business opportunity came your way when you were working with XYZ Ltd. This opportunity would result in a conflict of interest between you and your company. What would you do? a. Accept the opportunity as your own and inform the company b. Reject the opportunity completely c. Accept the opportunity and not inform the company d. Hand over the opportunity to the company 23. The current project you are working on is under a lot of fire. The project manager is looking for volunteers to take up more responsibilities. What would you do: a. Completely ignore. You have already finished your own work so why should you bother about others. b. Analyze your schedule and decide how many responsibilities you can take and then talk to your Pm to assign them to you c. Take up all the responsibilities. At least you will be able to finish some. d. Pick up one; after all it is your Project Manager asking 24. Which of these is the not an effective means of make a lasting impression in a presentation. a. Give out handouts at the beginning of the presentation

b. c. d.

Give out handouts at the end of the presentation Tell what you are going to tell them, tell them, Repeat what u have told them End the training with an action/assignment to take

25. Explain with example Vision, Goals, Principles and Values. 26. The conduct of inspection of source code is QA or QC? 27. Which of these is not a quality attribute? a) Reliability b) Transparency c) Usability d) Flexibility e) Correctness 28. The National Quality Awards provide a basis for successfully benchmarking against companies (True/False) 29. The cost of maintaining a helpdesk is which type of cost a) Prevention b) Appraisal c) Failure 30. Who is responsible for ensuring quality in the organization a) Employees b) Management c) Everybody involved in the working of the organization d) The Quality Assurance Department 31. The cost of poor quality is what percentage of cost of doing business. a) 15 - 50% b) 50 - 80% c) 80- 90% 32. Which of the following is not one of Deming’s Mgt Disease a) Excessive medical cost b) Mobility of Management c) Evaluation of performance, merit rating, or annual review of performance d) Breaking down barriers in work areas 33. Who propounded the theory “Quality is free”? a) Malcolm Baldrige b) Joseph M. Juran c) Philip Crosby d) Dr. Ishikawa e) Edward Deming 34. Who amongst these is an internal customer? a) The tester b) The client c) The final customer d) The ISO auditor 35. Which of these would constitute Management by fact? a) Collecting metrics on competitors business b) Forming a process to perform and control work

c) Relying on instinct without any data d) Picking the odd one out. 36. QA is the same as total QC (True/False) 37. _______ % of defects originate in the requirements stage a) 10-20 b) 30-50 c) 50-70 d) 40-70 38. The intent of Quality Control Checklist is to ask questions (True/False) 39. In Pareto Analysis, 80 % of the items would account to 20 % of the frequency (True/False) 40. From Customer’s point of view, Quality is “Meeting Requirements” (True/False) 41. Which of the following is not a Deming’s principle a) Eliminate Numerical goals b) Mobility of Management c) Breaking down barriers in work areas

Sample of a test policy. All test activities should be systematically planned and tracked by the Project Manager. • • • •

Testing should cover the system functionality in its entirety as documented in the functional specification. Test activities should be conducted based on the test cases. Test defects should be captured and closed. Root cause analysis on defects should be performed and preventive actions should be taken

Pl. find below the test objective which is written for a product.

1. To prepare the Test cases against the Functional requirement document and the Customization specific to the client. 2. To test the functionality of the product and the customization specific to the client against the approved Test cases by Test Lead. Test Strategy is nothing but what are all the types of testing that you are going to address and how you are going to achieve it. Two components of Test Strategy: Test Factor : What type of testing is required and how we are going to proceed with the testing. Testing Phase : What type of testing occur in which phase. Like unit testing will be done after construction phase, Integration testing will be done after integrating the modules. For example : we have planned for Unit Testing , Integration Testing, and then System Testing then define the scope for each type of testing. Unit Testing: objective of unit testing has to be defined like, it is functionality testing or we are going to test for the performance also. If we are going to use any testing techniques like branch and condition testing and Loop testing that also we need to mention in our testing strategy. For the application you said, plane takeoff can be written in module-A and Landing in Module-B. Test strategy for unit testing is that each and every line of code has to be tested since it is machine critical application. Following testing techniques will be used in the unit testing phase: 1. 2. 3.

Branch and condition testing. Loop testing. Performance testing.

Integration Testing: After the integration of Module-A and Module-B, we have to test for the functionality, performance. Following testing techniques will be used in Integration testing phase:

1. 2.

Top-down approach bottom-up approach

System Testing(Black Box testing) : System testing should be done mostly in end users environment. Following testing techniques will be used in system testing: 1. Boundary Value Analysis 2. Equivalence Partioning. 3. Any Flight simulation technique and how we are going to approach with that. Regression Testing : To test for the modules which are undergone changes and the impacted areas. Because of this changes existing functionality in the system should not get affected. All the above said points should be in the test strategy according to the need. By identifying the type of testing and their objective the risk will also be addressed. Courtesy: V Suresh

The list of fields in Test Director-Defects Grid are given below. Beside the field name, I've given a brief note as to what the field will have. Defect ID - Defect Number (Automatically generated field) Severity - Severity of the defect (fatal, medium, minor, severe, enhancement) (mandatory field) Module - Name of the module in which the defect was found(mandatory field) Status - Status of the defect (open, fixed, pending, reopen, retest successful) Assigned To - The person or team the defect is assigned to Priority - Priority of the defect (low, medium, high, very high, urgent) Detected By - the person who identified the defect (defaults to the login id) (mandatory field) Assign1 - The person or team the defect is assigned to (displays the list of login ids) Summary - Summary of the description(mandatory field) Detected on Date - Date on which the defect was identified(mandatory field) Closing Date - Date on which the defect was closed Category - Category in which the defect will fall into (Application Error, Environment, Database Error)(mandatory field) Description - Defect description (detail description of the defect) R&D Comments - Comments Actual Fix Time - Actual time taken for fixing the defect Attachments - Whether any files were attached to support the defect description or R&D comments etc(mandatory field) Closed in Version - Handoff Number Detected in Version - Handoff Number Estimated Fix Time - Estimated time for fixing the defect Modified - Last date on which the R & D comments were updated Planned Closing Version - Handoff number Project - Name of the project Reproducible - whether defect is reproducible (Y or N) Solution / Action - Whether solution is attached or not (Y or N) Subject - helpful if TD is used as a repository for Testcases Courtesy: Madhuri

How would you describe test design? Here is the IEEE/ANSI description. -----------------------------------------------------------------------------------------------------------IEEE/ANSI Std 829-1983 Purpose: To specify refinements of the test approach and to identify the features to be covered by the design and its associated tests. It also identifies the test cases and test procedures, if any, required to accomplish the testing and specifies the feature pass/fail procedure. Outline: -Test design specification identifier. -Features to be tested. -Approach refinements. -Test case identification. -Feature pass/fail criteria. -----------------------------------------------------------------------------------------------------------When does test design begin? It begins in the requirements stage. Most bugs are introduced in the requirements and design phase. What this means is the we need to be involved with the whole product life cycle from the beginning. The typical stage of test design starts with requirements generation. It is at this point that a high level test design is done, plus a determination can be made of the components that would need to be tested, as well as an overall integration. This continues with the design stage, where more detailed test plans and details can be created.

When designing tests, there are some things to keep in mind: the main objectives. Objective in test design: 1. Detect as many defects as possible. 2. Minimize test development costs. 3. Minimize test execution costs. 4. Minimize test maintenance costs.

Detailed design considerations: 1. Satisfying test development objectives. 2. Conforming to the test architecture. 3. Design of each test case. The steps to detailed design: 1. Identifying the items that should be tested. 2. Assigning priorities to those items based on risk. 3. Designing high level test designs for similar groups of items. 4. Designing individual test cases based on the high level designs.

The determination must be made which of the following are highest to lowest priority in the testing process to determine what is the critical path with regards to test design. Types of system test: 1. Volume 2. Usability 3. Performance 4. Configuration 5. Compatibility 6. Reliability 7. Load/Stress 8. Security 9. Resource Usage 10. Installability 11. Recovery 12. Serviceability The other things involved with test design involve determining the metrics that will be used to determine when the testing group will sign off on the software for release. Also, what type of physical resources will be necessary (lab space, hardware, other related tools, or any specific software and licenses).

1. 2.

Most QA groups infact practice QA – T/F False Between QA & QC latter is most important – T/F

3.

Quality is an attribute of a __product______. A product something_created_

4. 5.

6. 7.

8. 9. 10. 11. 12. 13. 14.

15. 16. 17. 18. 19. 20.

21.

(developed) Both QA and QC required to make quality happen – T/F False what are expected production costs? a. labor, material, equipment b. personnel, training, rollout c. training, testing, user acceptance. ANS: A What is involved in Total Product costs? all of the answers to #5 Appraisal costs are: a. costs associated with preventing errors b. costs associated with detecting errors c. costs associated with defective products delivered to customers. ANS:B Quality is _Everyone’s_ responsibility Types of measurement of performance are: a. strategic, statical, operational b. strategic, tactical, operational ANS: B Quality control is a _reactive_ function QA is a _proactive_ function. Validation means _testing_ of the final program with respect to _established criteria_ Certification means acceptance of software by an authorized agent after completion of development cycle _ T/F Verification generally means a. Consistency b. Completeness c. Correctness ANS:A Static analysis and dynamic analysis are only used during verification - T/F Debugging occurs before the program or module is fully executable and continues until the programmer feels the program is sound executable. – T/F False Verification activities during design stages are _Walkthroughs_, _Reviews_ and _Inspections_ Verification activities during operation and maintenance is _Rework_ Invalid inputs are elements within the functional domain - T/F Some typical techniques used during testing are a. Intuition b. Hand calculation c. Simulation d. Alternate solution to the same problem. ANS: C Exhaustive input set of expected correct responses is equivalent to writing the entire program itself – T/F False (guess)

22. A subset of the domain used in a testing process is called _Equivalence Partitioning_. (breaking down data ie testing a rule that edits data on range of 5000 to 10000, there are three partitions to test: under 5000, 5000-10000, and over 10000) 26 _Using a Checklist_ is the key to successful testing. 27 Having clear, concise statement of the problem to be solved will facilitate construction, communication, error analysis and test data generation. T/F 28. Error analysis can be done at implementation stage T/F 29. testing metrics are _____, ___________, __________ 30. Testing is used to exercise the code over a sufficient range of test data to verify its adherence to the design and requirements specification. T/F True 31. List some criteria for the selection of test data for test set. high-level requirements production extract available

32. 33. 34.

35.

version control of data base set of data ____________ testing helps to compensate for the inability to do exhaustive function testing Test coverage metrics are very useful for determining a ____________________ for the test data. The fraction of 'times per day' to 'number of days' of occurrence of event gives the likelihood of occurrence of risk. a) True b) False Data gathering while testing helps ______________ a) data analysis b) to determine test cases c) for conducting tests d) input for testing ANS: B

1. Which is not a testing risk? a. Budget b. Test Environment c. Portability of the system d. New Technology 2. Which is not a software risk? e. Availability of Automated Tools f. System will be difficult to operate g. Programs will be unmaintainable h. Unreliable results from the system 3. Decision/branch coverage strategy: a) always satisfies statement coverage b) is used in black box testing c) means that every branch direction is traversed atleast once d) is the same as condition coverage 4. Joe is performing a test to see that it complies with the user requirement that a certain field be populated, by using a dropdown containing a list of values. Joe is performing: a) White-box testing b) Black Box testing c) Load Testing d) Regression testing 5. Acceptance testing means d. Testing performed on a single stand-alone module or unit of code e. Testing after changes have been made to ensure that no unwanted changes were introduced f. Testing to ensure that the system meets the needs of the organization and the end user 6. The purpose of software testing is to: d. Demonstrate that the application works properly e. Detect the existence of defects f. Validate the logical design 7. Integration testing occurs when e. The system is ready to use f. Interfaces between unit-tested programs needs to be tested g. When testing client/server applications h. Testing the functions of the program against the specifications

8. Boundary value testing : a) Is the same as equivalence partitioning tests b) Is used in white-box testing strategy c) Tests combination of input circumstances d) Test conditions on, above and below edges of input and output equivalence classes 9. The primary responsibility of individuals accountable for testing activities is a) To find out defects b) To understand the system c) to ensure that quality is measured accurately d) to prove that developers are inefficient 10. Test Manager a) Prepares test Documentation b) Designs the Test strategy c) Test data planning, capture and conditioning d) All of the above 11. Test Engineer a) Manages the Test effort b) Tracks and reports Defects c) Design artifacts d) all of the above 12. Verification and validation activities begin a) After development phase b) After Design phase c) At the start of the project d) Before closing the project 13. System test plan generation and verification activity takes place during the a) Analysis Activity b) Design Activity c) Conceptualization Activity d) Operation Activity 14. S/W engineer is responsible for

a) b) c) d)

Identifying tool objectives Defining selection criteria Identifying candidate tools All of the above

15. Integration test exit criteria: a) 75-80% of total system functionality and 90% of major functionality delivered b) No open severity 1 or 2 defects c) Successful execution of integration test plan d) All of the above Match the following with the choices given below: (Ans. given below) 1. Performed when application components near completion. Test Readiness Review 2. Coding begins at the close of this review c. Critical Design Review 3. Looks at identifying defects as work progresses. In Process Review 4. CM Plan, Test plan and development plan are reviewed. S/W Requirements Review a. In Process Review b. S/W Requirements Review c. Critical Design Review d. Test Readiness Review Q5 - Bottom-up testing requires the development of interim stubs for test input a. True b. False Q6 - __________ is the most powerful Quality Control Tool a. Control Chart b. Pareto Analysis c. Checklist d. Histogram Q7 - Knowledge of the most common risks associated with software development and the platform you are working on is known as ___________ a. Testing Risk b. Software Risk c. Business Risk d. Premature Release Risk Q8 - ___________ % of system enhancements and repairs introduce new defects to the application a. 20 – 40 b. 20 – 50 c. 50 – 70 d. 40 Q9 - _______ % of defects originate in the requirements stage a. 10-20 b. 30-50

c. 50-70 d. 40-70 Q10 - _________ report can be prepared to show the status of testing a. Testing Action Report b. Final Test Report c. Functional testing status report d. Functions working Timeline Q11 - Name few Test Coverage Tools Q12 - ___________ % of system enhancements and repairs introduce new defects to the application a. 20 – 40 b. 20 – 50 c. 50 – 70 d. 40 Q13- Test Readiness review is conducted by a. Test Engineer b. Project Manager c. Test Manager d. Developer Q14 - Integration testing occurs when _________ is complete a. Unit testing b. System Testing c. Phase-end review d. In-process Review Q15- Match the following Stress Testing Testing the Response time for the transactions in an application Load Testing Testing an application repeatedly over a specific time period Performance Testing Testing an application for n number of users Q16 - Selecting the size and competency of staff needed to achieve the test plan objectives is known as _________ a. Estimating b. Scheduling c. Staffing Q17 - Decision/branch coverage strategy : a. always satisfies statement coverage b. is used in black box testing c. means that every branch direction is traversed atleast once d. is the same as condition coverage

Q18 - The process used for documenting user’s requirements is known as validation (True/False) Q19 - Normally an efficient testing team should have atleast 10 or more objectives (True/False) Q20 - Testing objectives should restate the project objectives from the project plan (True/False) Q21 - What are the guidelines for writing a Test plan Q22 - How would you measure the following? Test Effectiveness Test Efficiency Q23 - Environment competency is the ability to use the test environment established by test management (True/False) Q24 - Knowledge of the most common risks associated with software development and the platform you are working on is known as ___________ a. Testing Risk b. Software Risk c. Business Risk d. Premature Release Risk Q25 - Match the Following Description of the condition or capability of the system Document that defines the overall testing objectives Identifies all steps required to exercise the test cases Refines Test Approach and identifies the features to be covered by the design and its associated tests Document containing the actual values for input, along with the anticipated outputs Statement of what the tester is expected to accomplish during the testing activity

Test Cases Test Objective Test Plan Test Procedures Test Design Requirement

Q26 - __________ activities define a specific implementation solution to solve the user’s needs a. Analysis b. Design c. Conceptualization d. Operation Q27 - System test plan generation and verification activity takes place during the a. Analysis Activity

b. Design Activity c. Conceptualization Activity d. Operation Activity Q28 - Implementation activities support the use of software by the end user in an operational environment (True/False) Q29 - Answer in brief What would be the Test objective for unit testing What would be the quality measurements to assure that unit testing is complete? Q30 - S/W engineer is responsible for a. Identifying tool objectives b. Defining selection criteria c. Identifying candidate tools d. All of the above Q31 - Mention the exit criteria for Integration Test Q32 - Define and explain any three aspects of Code review? Q33 - Match the following Performed when application components near completion - In Process Review Coding begins at the close of this review - S/W requirements review Looks at identifying defects as work progresses - Critical design review CM Plan, Test plan and development plan are reviewed - Test readiness review Q34 - Match the following Retesting modules connected to the changed program- Black box testing Determines how well the user can interact with the system - White box Testing Demonstrates key functional capabilities by testing a string - System Testing of units Path or Logic in a unit or program is known - Regression Testing Testing the functions of the program against the specifications - Thread Testing Test all the integrated components of an information system Usability Testing Q35 - Explain with examples : Equivalence Partitioning, Boundary analysis, Error guessing

Q36 - The intent of Quality Control Checklist is to ask questions (True/False) Q37 - The National Quality Awards provide a basis for successfully benchmarking against companies (True/False) Q38 - The cost of maintaining a helpdesk is which type of cost a. Prevention b. Appraisal c. Failure Q39 - __________ is the most powerful Quality Control Tool a. Control Chart b. Pareto Analysis c. Checklist d. Histogram Q40 - What type of change do u need before you can obtain a behavior change? Lifestyle Vocabulary Internal Management

Answers to above 1 to 40: 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) 15)

16) 17) 18) 19) 20) 21) 22)

Correct. Correct Correct Correct True Checklist Software Risk 20-50 50-70 Functional Testing Status Report Mccabe, Jcover Repeat – Q8 Test Manager Unit Testing Stress Testing: Testing an application repeatedly over a specific time period Load Testing: Testing an application for n number of users Performance Testing: Testing the Response time for the transactions in an application

means that every branch direction is traversed atleast once False True True About Test Design, Test Environment, Test Strategy, Test Risk. (Total STRs-STRs not Mapped)/Total STRs*100 (Total Test Cases-STRs that cannot be mapped to test cases)/Total Test Cases 23) True 24) Repeat – Q7. 25) Description of the condition or capability of the system - Requirement Document that defines the overall testing objectives – Test Plan Identifies all steps required to exercise the test cases – Test Procedure Refines Test Approach and identifies the features to be covered by the design and its associated tests - Test Design Document containing the actual values for input, along Test Cases with the anticipated outputs Statement of what the tester is expected to accomplish Test Objective during the testing activity 26) We will discuss in the telecon. 27) We will discuss in the telecon. 28) We will discuss in the telecon. 29) All the lines of code belongs to a unit program has to be executed atleast once. All the Unit Test case has to be executed. 30) Test Coverage. 31) All the test cases belongs to that particular integration has to be executed and tracked to closure 32) Verify Coding Standards, to improve the performance, to verify how easy to maintain the code. 33) Repeat – Q3. 34) Retesting modules connected to the changed program – Regression Testing Determines how well the user can interact with the system – Usability Testing Demonstrates key functional capabilities by testing a string of units. - Thread Testing Path or Logic in a unit or program is known – White box testing Testing the functions of the program against the Specifications - Black Box testing

Test all the integrated components of an information system - System testing. 35) 36) The intent of Quality Control Checklist is to ask questions (True/False) – True 37) The National Quality Awards provide a basis for successfully benchmarking against companies (True/False) – False 38) Failure cost 39) Checklist 40) Vocabulary