How Important is the "Test to Break Attitude" for a tester.

Everybody spells the beans saying that "a tester should have Test to Break Attitude"... How much of it is required? Lets try to explore about it.

A tester, should assume that System Under Test is with lot of defects hidden in it. This will help us to have a mindset to go in depth in our testing covering the length and breadth of the System.

This attitude is very helpful Especially people who are invloved in EXPLORATORY testing/Adhoc testing. We always tend to try and break the part of the function and in the process we encounter defects which we might miss it during our scripted testing.

However, too much of this attitude will also put us into negative thought about a product.

This is again is debatable. Should a tester always think negatively when testing?? "Not always" is my answer, but most of the time a tester should feel that the "system under test has lot of issues, I am going to find a lot of showstopper".

Please be carefull, the negative thought, or test to break attitude should only be on the System under test and not on the person who has developed it.

We all know, attitude is such an important intrument of an individual to perform any work to completion. Similarly, test to break attitude is a very important aspect in tester life, However, more of it is also not very good.

Testers should be Situational, Analytical and more importantantly understand the Purpose/Aim of testing then with proper attitude we can make wonders.

Software Development Methodologies and Testing

Software Development Methodologies and Testing

Various generic software development life cycle methodologies are available for executing software development projects. Although each methodology is designed for a specific purpose and has its own advantages and disadvantages, most methodologies divide the life cycle into phases and share tasks across these phases. This section briefly summarizes common methodologies used for software development and describes their relationship to testing.

Waterfall Model

The waterfall model is one of the earliest structured models for software development. It consists of the following sequential phases through which the development life cycle progresses:

• System feasibility. In this phase, you consider the various aspects of the targeted business process, find out which aspects are worth incorporating into a system, and evaluate various approaches to building the required software.
• Requirement analysis. In this phase, you capture software requirements in such a way that they can be translated into actual use cases for the system. The requirements can derive from use cases, performance goals, target deployment, and so on.
• System design. In this phase, you identify the interacting components that make up the system. You define the exposed interfaces, the communication between the interfaces, key algorithms used, and the sequence of interaction. An architecture and design review is conducted at the end of this phase to ensure that the design conforms to the previously defined requirements.
• Coding and unit testing. In this phase, you write code for the modules that make up the system. You also review the code and individually test the functionality of each module.
• Integration and system testing. In this phase, you integrate all of the modules in the system and test them as a single system for all of the use cases, making sure that the modules meet the requirements.
• Deployment and maintenance. In this phase, you deploy the software system in the production environment. You then correct any errors that are identified in this phase, and add or modify functionality based on the updated requirements.

The waterfall model has the following advantages:

• It allows you to compartmentalize the life cycle into various phases, which allows you to plan the resources and effort required through the development process.
• It enforces testing in every stage in the form of reviews and unit testing. You conduct design reviews, code reviews, unit testing, and integration testing during the stages of the life cycle.
• It allows you to set expectations for deliverables after each phase.

The waterfall model has the following disadvantages:

• You do not see a working version of the software until late in the life cycle. For this reason, you can fail to detect problems until the system testing phase. Problems may be more costly to fix in this phase than they would have been earlier in the life cycle.
• When an application is in the system testing phase, it is difficult to change something that was not carefully considered in the system design phase. The emphasis on early planning tends to delay or restrict the amount of change that the testing effort can instigate, which is not the case when a working model is tested for immediate feedback.
• For a phase to begin, the preceding phase must be complete; for example, the system design phase cannot begin until the requirement analysis phase is complete and the requirements are frozen. As a result, the waterfall model is not able to accommodate uncertainties that may persist after a phase is completed. These uncertainties may lead to delays and extended project schedules.

Incremental or Iterative Development

The incremental, or iterative, development model breaks the project into small parts. Each part is subjected to multiple iterations of the waterfall model. At the end of each iteration, a new module is completed or an existing one is improved on, the module is integrated into the structure, and the structure is then tested as a whole.
For example, using the iterative development model, a project can be divided into 12 one- to four-week iterations. The system is tested at the end of each iteration, and the test feedback is immediately incorporated at the end of each test cycle. The time required for successive iterations can be reduced based on the experience gained from past iterations. The system grows by adding new functions during the development portion of each iteration. Each cycle tackles a relatively small set of requirements; therefore, testing evolves as the system evolves. In contrast, in a classic waterfall life cycle, each phase (requirement analysis, system design, and so on) occurs once in the development cycle for the entire set of system requirements.
The main advantage of the iterative development model is that corrective actions can be taken at the end of each iteration. The corrective actions can be changes to the specification because of incorrect interpretation of the requirements, changes to the requirements themselves, and other design or code-related changes based on the system testing conducted at the end of each cycle.
The main disadvantages of the iterative development model are as follows:

• The communication overhead for the project team is significant, because each iteration involves giving feedback about deliverables, effort, timelines, and so on.
• It is difficult to freeze requirements, and they may continue to change in later iterations because of increasing customer demands. As a result, more iterations may be added to the project, leading to project delays and cost overruns.
• The project requires a very efficient change control mechanism to manage changes made to the system during each iteration.

Prototyping Model

The prototyping model assumes that you do not have clear requirements at the beginning of the project. Often, customers have a vague idea of the requirements in the form of objectives that they want the system to address. With the prototyping model, you build a simplified version of the system and seek feedback from the parties who have a stake in the project. The next iteration incorporates the feedback and improves on the requirements specification. The prototypes that are built during the iterations can be any of the following:

• A simple user interface without any actual data processing logic
• A few subsystems with functionality that is partially or completely implemented
• Existing components that demonstrate the functionality that will be incorporated into the system

The prototyping model consists of the following steps.

1. Capture requirements. This step involves collecting the requirements over a period of time as they become available.
2. Design the system. After capturing the requirements, a new design is made or an existing one is modified to address the new requirements.
3. Create or modify the prototype. A prototype is created or an existing prototype is modified based on the design from the previous step.
4. Assess based on feedback. The prototype is sent to the stakeholders for review. Based on their feedback, an impact analysis is conducted for the requirements, the design, and the prototype. The role of testing at this step is to ensure that customer feedback is incorporated in the next version of the prototype.
5. Refine the prototype. The prototype is refined based on the impact analysis conducted in the previous step.
6. Implement the system. After the requirements are understood, the system is rewritten either from scratch or by reusing the prototypes. The testing effort consists of the following:
   • Ensuring that the system meets the refined requirements
   • Code review
   • Unit testing
   • System testing

The main advantage of the prototyping model is that it allows you to start with requirements that are not clearly defined.
The main disadvantage of the prototyping model is that it can lead to poorly designed systems. The prototypes are usually built without regard to how they might be used later, so attempts to reuse them may result in inefficient systems. This model emphasizes refining the requirements based on customer feedback, rather than ensuring a better product through quick change based on test feedback.

Agile Methodology

Most software development life cycle methodologies are either iterative or follow a sequential model (as the waterfall model does). As software development becomes more complex, these models cannot efficiently adapt to the continuous and numerous changes that occur. Agile methodology was developed to respond to changes quickly and smoothly. Although the iterative methodologies tend to remove the disadvantage of sequential models, they still are based on the traditional waterfall approach. Agile methodology is a collection of values, principles, and practices that incorporates iterative development, test, and feedback into a new style of development. For an overview of agile methodology, see the Agile Modeling site at http://www.agilemodeling.com/.
The key differences between agile and traditional methodologies are as follows:

• Development is incremental rather than sequential. Software is developed in incremental, rapid cycles. This results in small, incremental releases, with each release building on previous functionality. Each release is thoroughly tested, which ensures that all issues are addressed in the next iteration.
• People and interactions are emphasized, rather than processes and tools. Customers, developers, and testers constantly interact with each other. This interaction ensures that the tester is aware of the requirements for the features being developed during a particular iteration and can easily identify any discrepancy between the system and the requirements.
• Working software is the priority rather than detailed documentation. Agile methodologies rely on face-to-face communication and collaboration, with people working in pairs. Because of the extensive communication with customers and among team members, the project does not need a comprehensive requirements document.
• Customer collaboration is used, rather than contract negotiation. All agile projects include customers as a part of the team. When developers have questions about a requirement, they immediately get clarification from customers.
• Responding to change is emphasized, rather than extensive planning. Extreme Programming does not preclude planning your project. However, it suggests changing the plan to accommodate any changes in assumptions for the plan, rather than stubbornly trying to follow the original plan.

Agile methodology has various derivate approaches, such as Extreme Programming, Dynamic Systems Development Method (DSDM), and SCRUM. Extreme Programming is one of the most widely used approaches.

Extreme Programming

In Extreme Programming, rather than designing whole of the system at the start of the project, the preliminary design work is reduced to solving the simple tasks that have already been identified.
The developers communicate directly with customers and other developers to understand the initial requirements. They start with a very simple task and then get feedback by testing their software as soon as it is developed. The system is delivered to the customers as soon as possible, and the requirements are refined or added based on customer feedback. In this way, requirements evolve over a period of time, and developers are able to respond quickly to changes.
The real design effort occurs when the developers write the code to fulfill the specific engineering task. The engineering task is a part of a greater user story (which is similar to a use case). The user story concerns itself with how the overall system solves a particular problem. It represents a part of the functionality of the overall system. A group of user stories is capable of describing the system as a whole. The developers refactor the previous code iteration to establish the design needed to implement the functionality.
During the Extreme Programming development life cycle, developers usually work in pairs. One developer writes the code for a particular feature, and the second developer reviews the code to ensure that it uses simple solutions and adheres to best design principles and coding practices.
Discussion of the core practices of Extreme Programming is beyond the scope of this chapter. For more information, see the links referred to in "More Information" later in this section.
Test-driven development, which is one of the core practices in Extreme Programming, is discussed in greater detail later in this chapter.

When to Use Extreme Programming

Extreme Programming is useful in the following situations:

• When the customer does not have a clear understanding of the details of the new system. The developers interact continuously with the customer, delivering small pieces of the application to the customer for feedback, and taking corrective action as necessary.
• When the technology used to develop the system is new compared to other technologies. Frequent test cycles in Extreme Programming mitigate the risk of incompatibility with other existing systems.
• When you can afford to create automated unit and functional tests. In some situations, you may need to change the system design so that each module can be tested in isolation using automated unit tests.
• When the team size is not very large (usually 2 to 12 people). Extreme Programming is successful in part because it requires close team interaction and working in pairs. A large team would have difficulty in communicating efficiently at a fast pace. However, large teams have used Extreme Programming successfully.

More Information

For more information about the core practices in Extreme Programming, see the following resources:

• "What Is Extreme Programming?" at http://xprogramming.com/xpmag/whatisxp
• "Extreme Programming: A Gentle Introduction" at http://www.extremeprogramming.org/

Test-Driven Development

Test-driven development is one of the core practices of Extreme Programming. The practice extends the feedback approach, and requires that you develop test cases before you develop code. Developers develop functionality to pass the existing test cases. The test team then adds new test cases to test the existing functionality, and runs the entire test suite to ensure that the code fails (either because the existing functionality needs to be modified or because required functionality is not yet included). The developers then modify the functionality or create new functionality so that the code can withstand the failed test cases. This cycle continues until the test code passes all of the test cases that the team can create. The developers then refactor the functional code to remove any duplicate or dead code and make it more maintainable and extensible.
Test-driven development reverses the traditional development process. Instead of writing functional code first and then testing it, the team writes the test code before the functional code. The team does this in very small steps—one test and a small amount of corresponding functional code at a time. The developers do not write code for new functionality until a test fails because some functionality is not present. Only when a test is in place do developers do the work required to ensure that the test cases in the test suite pass. In subsequent iterations, when the team has the updated code and another set of test cases, the code may break several existing tests as well as the new tests. The developers continue to develop or modify the functionality to pass all of the test cases.
Test-driven development allows you to start with an unclear set of requirements and relies on the feedback loop between the developers and the customers for input on the requirements. The customer or a customer representative is the part of the core team and immediately provides feedback about the functionality. This practice ensures that the requirements evolve over the course of the project cycle. Testing before writing functional code ensures that the functional code addresses all of the requirements, without including unnecessary functionality.
With test-driven development, you do not need to have a well-defined architectural design before beginning the development phase, as you do with traditional development life cycle methodologies. Test-driven development allows you to tackle smaller problems first and then evolve the system as the requirements become more clear later in the project cycle.
Other advantages of test-driven development are as follows:

• Test-driven development promotes loosely coupled and highly cohesive code, because the functionality is evolved in small steps. Each piece of the functionality needs to be self-sufficient in terms of the helper classes and the data that it acts on so that it can be successfully tested in isolation.
• The test suite acts as documentation for the functional specification of the final system.
• The system uses automated tests, which significantly reduce the time taken to retest the existing functionality for each new build of the system.
• When a test fails, you have a clear idea of the tasks that you must perform to resolve the problem. You also have a clear measure of success when the test no longer fails. This increases your confidence that the system actually meets the customer requirements.

Test-driven development helps ensure that your source code is thoroughly unit tested. However, you still need to consider traditional testing techniques, such as functional testing, user acceptance testing, and system integration testing. Much of this testing can also be done early in your project. In fact, in Extreme Programming, the acceptance tests for a user story are specified by the project stakeholder(s) either before or in parallel to the code being written, giving stakeholders the confidence that the system meets their requirements.

Steps in Test-Driven Development

The test-driven development process consists of the steps shown in Figure 2.1.

Figure 2.1. Test-driven development process

The steps can be summarized as follows:

1. Create the test code. Use an automated test framework to create the test code. The test code drives the development of functionality.
2. Write/Modify the functional code. Write the functional code for the application block so that it can pass all test cases from the test code. The first iteration involves developing new functionality, and subsequent iterations involve modifying the functionality based on the failed test cases.
3. Create additional tests. Develop additional tests for testing of the functional code.
4. Test the functional code. Test the functional code based on the test cases developed in Step 3 and Step 1. Repeat steps 2 through 4 until the code is able to pass all of the test cases.
5. Refactor the code. Modify the code so that there is no dead code or duplication. The code should adhere to best practices for maintainability, performance, and security.

6. Agile Testing: Example

   Agile methodology with Extreme Programming and test-driven development was used to develop the Smart Client Offline Application Block. The following are highlights of the approach taken on the project:
   
   • The test team and the development team were not formally separated. The developers worked in pairs, with one person developing the test cases and the other writing the functionality for the module.
   • There was much more interaction among team members than there is when following a traditional development model. In addition to using the informal chat-and-develop mode, the team held a 30 minute daily standup meeting, which gave team members a forum for asking questions and resolving problems, and weekly iterative review meetings to track the progress for each iterative cycle.
   • Project development began without any formal design document. The specifications were in the form of user stories that were agreed upon by the team members. In the weekly iterative review meetings, team members planned how to complete these stories and how many iterations to assign for each story.
   • Each story was broken down into several tasks. All of the stories and corresponding tasks were written down on small cards that served as the only source of design documentation for the application block.
   • While developing each task or story, NUnit test suites were written to drive the development of features.
   • No formal test plans were developed. The testing was primarily based on the tasks or stories for feature development. The development team got immediate feedback from the test team. Having the test team create the quick start samples gave the development team a perspective on the real-life usage of the application block.
   • After the task or story passed all of the NUnit test cases and was complete, quick start samples were developed to showcase the functionality. The quick start samples demonstrated the usage of the application block and were useful for further testing the code in the traditional way (functional and integration tests). Any discrepancies found in this stage were reported immediately and were fixed on a case-by-case basis. The modified code was tested again with the automated test suites and then was handed over to be tested again with the quick start samples.

   Summary

   This chapter compared various software development life cycle approaches and described how testing fits into each approach. The chapter also presented a process for test-driven development, which is one of the core practices of Extreme Programming, an agile development methodology.
   By using test-driven development, you can ensure that each feature of an application block is rigorously tested early in the project life cycle. Early testing significantly reduces the risk of costly fixes and delays later in the life cycle and ensures a robust application block that meets all of the feature requirements.

Software Testing Myths

There are lot of Myths about Testing. I am trying to uncover some of them.

Quality Control = Testing, Sorry testing alone does not comply quality. Quality terminolgy is more than that of testing activity. Quality is the term that mangement speaks and not only tester. Its the process/best practices followed by different teams which will lead to quality product. Tester are Quality gate keepers to only check for quality complaince and give inputs.

By testing 100% defects are/Should be found, sorry this is again a wrong interpretation. We are hear to uncover maximum defects at the early stage. Due cource of time if we use Best Practices and Better strategy we can minimise the issues in the later stage but cannot garuntee 100% defect free. So when you have questions that why was this not found previously. Explain them in a good way about this myth.

Testing is Simple and straight forward, cannot agree, every work has its own difficulty and importance. Anybody and everybody cannot not do everything. If we are destined to do testing, we are good at it. First belive this fact yourself, only then people will start beliving this. You will have to be really really good in your analytical skills to do testing. However, it your bad at it, Testing will help you to get better by your experience

Atomation tesing can replace Human resource, this is a very debateble statement. Again its not at all true. Automation is like to tool to help tester and not to replace him. It helps to do redundant work , where the testers can concentrate on more core issues then doing things which are repetative.

There are a lot such myths which are assumed by people and sometimes even the management. As a tester, we should explain and make them understand the reality. After all we are accontable for removing such myths and beliefs.

Testers should have patience, convincing capability and be a good team player

Today’s world, people expect lot of Qualities/Skills from testers- Domain knowledge, Technical Skills, Adaptability, Analytical thinking etc...

The most important qualities for testers is to be good team player with convincing capability and lot of patience to listen to the comments and Criticism.

The above said qualities are a very important aspect for any professional. However, for tester it’s the very very essential quality to be successful.

As the quality gate keepers, we are responsible in finding bugs, and showing others that there is fault in what they have implemented/developed. Trust me anybody who is pointed out will go nuts. Some time they show it to us. Most of the time they keep it to themselves. It’s the human tendency. In the process, we might encounter lot of opposition, aggression, debating situation etc.

We need act in patience in such situation. Listen to the comments, criticism and conversation. Analyze and try to convince the facts with statistical data and prove that you’re right. Retaliating to the comments will put us nowhere.

Also, we should also be ready to accept things first and then get back with proper data and prove ourselves correct.

Note: you need to be sure what your commenting and debating on. if not accepts the comments and make sure you don’t repeat such things again.

Being Good team player and having good rapport is very important to tester. As a tester, we will come across lot of agreements and lot more disagreements. We have to face it, correct us if we are wrong, and convince others if we are correct.

"Take things easy and cool end of the day we are working for the organization and not for anybody else. Don’t take things personally", if we have this motive, things will be simpler and lot more straight.

Caution, good rapport with the team members, doesn’t mean that u agree for everything others comment or they agree for everything you report.

"As a tester we should be good in debating".

Next time, you’re in a situation that people are not agreeing to you, "It’s simple that you’re not able to convince". Work on your convincing skills, have patience in what they say, collate the statistical data to convince your findings, and more of all, be a good team player. "Work only when you’re at work”. When you come out of it, forget everything and be a normal person. "Don't try to carry forward aggression", it will affect your mindset towards an individual or about the conversation he or she had. The moment we start implementing these things in our day to day activity, we will definitely see improvements in our way of working and co-ordination with others teams.

Try this it works. it has worked for me....

ISTQB Foundation level Sample papers 10

1. We split testing into distinct stages primarily because:
a) Each test stage has a different purpose.
b) It is easier to manage testing in stages.
c) We can run different tests in different environments.
d) The more stages we have, the better the testing.

2. Which of the following is likely to benefit most from the use of test tools providing test capture and replay facilities?
a) Regression testing
b) Integration testing
c) System testing
d) User acceptance testing

3. Which of the following statements is NOT correct?
a) A minimal test set that achieves 100% LCSAJ coverage will also achieve 100% branch coverage.
b) A minimal test set that achieves 100% path coverage will also achieve 100% statement coverage.
c) A minimal test set that achieves 100% path coverage will generally detect more faults than one that achieves 100% statement coverage.
d) A minimal test set that achieves 100% statement coverage will generally detect more faults than one that achieves 100% branch coverage.

4. Which of the following requirements is testable?
a) The system shall be user friendly.
b) The safety-critical parts of the system shall contain 0 faults.
c) The response time shall be less than one second for the specified design load.
d) The system shall be built to be portable.

5. Analyse the following highly simplified procedure:
Ask: “What type of ticket do you require, single or return?”
IF the customer wants ‘return’
Ask: “What rate, Standard or Cheap-day?”
IF the customer replies ‘Cheap-day’
Say: “That will be £11:20”
ELSE
Say: “That will be £19:50”
ENDIF
ELSE
Say: “That will be £9:75”
ENDIF
Now decide the minimum number of tests that are needed to ensure that all
the questions have been asked, all combinations have occurred and all
replies given.
a) 3
b) 4
c) 5d) 6
6 Error guessing:
a) supplements formal test design techniques.
b) can only be used in component, integration and system testing.
c) is only performed in user acceptance testing.
d) is not repeatable and should not be used.

7. Which of the following is NOT true of test coverage criteria?
a) Test coverage criteria can be measured in terms of items exercised by a test suite.
b) A measure of test coverage criteria is the percentage of user requirements covered.
c) A measure of test coverage criteria is the percentage of faults found.
d) Test coverage criteria are often used when specifying test completion criteria.

8. In prioritising what to test, the most important objective is to:
a) find as many faults as possible.
b) test high risk areas.
c) obtain good test coverage.
d) test whatever is easiest to test.

9. Given the following sets of test management terms (v-z), and activity descriptions (1-5), which one of the following best pairs the two sets?
v – test control
w – test monitoring
x - test estimation
y - incident management
z - configuration control

1 - calculation of required test resources
2 - maintenance of record of test results
3 - re-allocation of resources when tests overrun
4 - report on deviation from test plan
5 - tracking of anomalous test results

a) v-3,w-2,x-1,y-5,z-4
b) v-2,w-5,x-1,y-4,z-3
c) v-3,w-4,x-1,y-5,z-2
d) v-2,w-1,x-4,y-3,z-5

10. Which one of the following statements about system testing is NOT true?
a) System tests are often performed by independent teams.
b) Functional testing is used more than structural testing.
c) Faults found during system tests can be very expensive to fix.
d) End-users should be involved in system tests.

11. Which of the following is false?
a) Incidents should always be fixed.
b) An incident occurs when expected and actual results differ.
c) Incidents can be analysed to assist in test process improvement.
d) An incident can be raised against documentation.

12. Enough testing has been performed when:
a) time runs out.
b) the required level of confidence has been achieved.
c) no more faults are found.
d) the users won’t find any serious faults.

13. Which of the following is NOT true of incidents?
a) Incident resolution is the responsibility of the author of the software under test.
b) Incidents may be raised against user requirements.
c) Incidents require investigation and/or correction.
d) Incidents are raised when expected and actual results differ.

14. Which of the following is not described in a unit test standard?
a) syntax testing
b) equivalence partitioning
c) stress testing
d) modified condition/decision coverage

15. Which of the following is false?
a) In a system two different failures may have different severities.
b) A system is necessarily more reliable after debugging for the removal of a fault.
c) A fault need not affect the reliability of a system.
d) Undetected errors may lead to faults and eventually to incorrect behaviour.

16. Which one of the following statements, about capture-replay tools, is NOT correct?
a) They are used to support multi-user testing.
b) They are used to capture and animate user requirements.
c) They are the most frequently purchased types of CAST tool.
d) They capture aspects of user behaviour.

17. How would you estimate the amount of re-testing likely to be required?
a) Metrics from previous similar projects
b) Discussions with the development team
c) Time allocated for regression testing
d) a & b

18. Which of the following is true of the V-model?
a) It states that modules are tested against user requirements.
b) It only models the testing phase.
c) It specifies the test techniques to be used.
d) It includes the verification of designs.

19. The oracle assumption:
a) is that there is some existing system against which test output may be checked.
b) is that the tester can routinely identify the correct outcome of a test.
c) is that the tester knows everything about the software under test.
d) is that the tests are reviewed by experienced testers.

20. Which of the following characterises the cost of faults?
a) They are cheapest to find in the early development phases and the most expensive to fix in the latest test phases.
b) They are easiest to find during system testing but the most expensive to fix then.
c) Faults are cheapest to find in the early development phases but the most expensive to fix then.
d) Although faults are most expensive to find during early development phases, they are cheapest to fix then.

21. Which of the following should NOT normally be an objective for a test?
a) To find faults in the software.
b) To assess whether the software is ready for release.
c) To demonstrate that the software doesn’t work.
d) To prove that the software is correct.

22. Which of the following is a form of functional testing?
a) Boundary value analysis
b) Usability testing
c) Performance testing
d) Security testing

23. Which of the following would NOT normally form part of a test plan?
a) Features to be tested
b) Incident reports
c) Risks
d) Schedule

24. Which of these activities provides the biggest potential cost saving from the use of CAST?
a) Test management
b) Test design
c) Test execution
d) Test planning

25. Which of the following is NOT a white box technique?
a) Statement testing
b) Path testing
c) Data flow testing
d) State transition testing

26. Data flow analysis studies:
a) possible communications bottlenecks in a program.
b) the rate of change of data values as a program executes.
c) the use of data on paths through the code.
d) the intrinsic complexity of the code.

27. In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free. The next £1500 is taxed at 10%
The next £28000 is taxed at 22%
Any further amount is taxed at 40%
To the nearest whole pound, which of these is a valid Boundary Value Analysis test case?
a) £1500
b) £32001
c) £33501
d) £28000

28. An important benefit of code inspections is that they:
a) enable the code to be tested before the execution environment is ready.
b) can be performed by the person who wrote the code.
c) can be performed by inexperienced staff.
d) are cheap to perform.

29. Which of the following is the best source of Expected Outcomes for User Acceptance Test scripts?
a) Actual results
b) Program specification
c) User requirements
d) System specification

30. What is the main difference between a walkthrough and an inspection?
a) An inspection is lead by the author, whilst a walkthrough is lead by a trained moderator.
b) An inspection has a trained leader, whilst a walkthrough has no leader.
c) Authors are not present during inspections, whilst they are during walkthroughs.
d) A walkthrough is lead by the author, whilst an inspection is lead by a trained moderator.

31. Which one of the following describes the major benefit of verification early in the life cycle?
a) It allows the identification of changes in user requirements.
b) It facilitates timely set up of the test environment.
c) It reduces defect multiplication.
d) It allows testers to become involved early in the project.

32. Integration testing in the small:
a) tests the individual components that have been developed.
b) tests interactions between modules or subsystems.
c) only uses components that form part of the live system.
d) tests interfaces to other systems.

33. Static analysis is best described as:
a) the analysis of batch programs.
b) the reviewing of test plans.
c) the analysis of program code.
d) the use of black box testing.

34. Alpha testing is:
a) post-release testing by end user representatives at the developer’s site.
b) the first testing that is performed.
c) pre-release testing by end user representatives at the developer’s site.
d) pre-release testing by end user representatives at their sites.

35. A failure is:
a) found in the software; the result of an error.
b) departure from specified behaviour.
c) an incorrect step, process or data definition in a computer program.
d) a human action that produces an incorrect result.

36. In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free. The next £1500 is taxed at 10%
The next £28000 is taxed at 22%
Any further amount is taxed at 40%
Which of these groups of numbers would fall into the same equivalence class?
a) £4800; £14000; £28000
b) £5200; £5500; £28000
c) £28001; £32000; £35000
d) £5800; £28000; £32000

37. The most important thing about early test design is that it:
a) makes test preparation easier.
b) means inspections are not required.
c) can prevent fault multiplication.
d) will find all faults.

38. Which of the following statements about reviews is true?
a) Reviews cannot be performed on user requirements specifications.
b) Reviews are the least effective way of testing code.
c) Reviews are unlikely to find faults in test plans.
d) Reviews should be performed on specifications, code, and test plans.

39. Test cases are designed during:
a) test recording.
b) test planning.
c) test configuration.
d) test specification.

40. A configuration management system would NOT normally provide:
a) linkage of customer requirements to version numbers.
b) facilities to compare test results with expected results.
c) the precise differences in versions of software component source code.
d) restricted access to the source code library.


Answers:
1 A
2 A
3 D
4 C
5 A
6 A
7 C
8 B
9 C
10 D
11 A
12 B
13 A
14 C
15 B
16 B
17 D
18 D
19 B
20 A
21 D
22 A
23 B
24 C
25 D
26 C
27 C
28 A
29 C
30 D
31 C
32 B
33 C
34 C
35 B
36 D
37 C
38 D
39 D
40 B

ISTQB Foundation level Sample papers 8

1. When what is visible to end-users is a deviation from the specific or expected behavior, this is called:
a) an error
b) a fault
c) a failure
d) a defect
e) a mistake

2. Regression testing should be performed:
v) every week
w) after the software has changed
x) as often as possible
y) when the environment has changed
z) when the project manager says

a) v & w are true, x – z are false
b) w, x & y are true, v & z are false
c) w & y are true, v, x & z are false
d) w is true, v, x y and z are false
e) all of the above are true

3. IEEE 829 test plan documentation standard contains all of the following except:
a) test items
b) test deliverables
c) test tasks
d) test environment
e) test specification

4. Testing should be stopped when:
a) all the planned tests have been run
b) time has run out
c) all faults have been fixed correctly
d) both a) and c)
e) it depends on the risks for the system being tested

5. Order numbers on a stock control system can range between 10000 and 99999 inclusive. Which of the following inputs might be a result of designing tests for only valid equivalence classes and valid boundaries:
a) 1000, 5000, 99999
b) 9999, 50000, 100000
c) 10000, 50000, 99999
d) 10000, 99999
e) 9999, 10000, 50000, 99999, 10000

6. Consider the following statements about early test design:
i. early test design can prevent fault multiplication
ii. faults found during early test design are more expensive to fix
iii. early test design can find faults
iv. early test design can cause changes to the requirements
v. early test design takes more effort

a) i, iii & iv are true. Ii & v are false
b) iii is true, I, ii, iv & v are false
c) iii & iv are true. i, ii & v are false
d) i, iii, iv & v are true, ii us false
e) i & iii are true, ii, iv & v are false

7. Non-functional system testing includes:
a) testing to see where the system does not function properly
b) testing quality attributes of the system including performance and usability
c) testing a system feature using only the software required for that action
d) testing a system feature using only the software required for that function
e) testing for functions that should not exist

8. Which of the following is NOT part of configuration management:
a) status accounting of configuration items
b) auditing conformance to ISO9001
c) identification of test versions
d) record of changes to documentation over time
e) controlled library access

9. Which of the following is the main purpose of the integration strategy for integration testing in the small?
a) to ensure that all of the small modules are tested adequately
b) to ensure that the system interfaces to other systems and networks
c) to specify which modules to combine when and how many at once
d) to ensure that the integration testing can be performed by a small team
e) to specify how the software should be divided into modules

10. What is the purpose of test completion criteria in a test plan:
a) to know when a specific test has finished its execution
b) to ensure that the test case specification is complete
c) to set the criteria used in generating test inputs
d) to know when test planning is complete
e) to plan when to stop testing

11. Consider the following statements
i. an incident may be closed without being fixed
ii. incidents may not be raised against documentation
iii. the final stage of incident tracking is fixing
iv. the incident record does not include information on test environments
v. incidents should be raised when someone other than the author of the software performs the test

a) ii and v are true, I, iii and iv are false
b) i and v are true, ii, iii and iv are false
c) i, iv and v are true, ii and iii are false
d) i and ii are true, iii, iv and v are false
e) i is true, ii, iii, iv and v are false

12. Given the following code, which is true about the minimum number of test cases required for full statement and branch coverage:
Read P
Read Q
IF P+Q > 100 THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF

a) 1 test for statement coverage, 3 for branch coverage
b) 1 test for statement coverage, 2 for branch coverage
c) 1 test for statement coverage, 1 for branch coverage
d) 2 tests for statement coverage, 3 for branch coverage
e) 2 tests for statement coverage, 2 for branch coverage

13. Given the following:
Switch PC on
Start “outlook”
IF outlook appears THEN
Send an email
Close outlook

a) 1 test for statement coverage, 1 for branch coverage
b) 1 test for statement coverage, 2 for branch coverage
c) 1 test for statement coverage. 3 for branch coverage
d) 2 tests for statement coverage, 2 for branch coverage
e) 2 tests for statement coverage, 3 for branch coverage

14. Given the following code, which is true:
IF A > B THEN
C = A – B
ELSE
C = A + B
ENDIF
Read D
IF C = D Then
Print “Error”
ENDIF

a) 1 test for statement coverage, 3 for branch coverage
b) 2 tests for statement coverage, 2 for branch coverage
c) 2 tests for statement coverage. 3 for branch coverage
d) 3 tests for statement coverage, 3 for branch coverage
e) 3 tests for statement coverage, 2 for branch coverage

15. Consider the following:
Pick up and read the newspaper
Look at what is on television
If there is a program that you are interested in watching then switch the the television on and watch the program
Otherwise
Continue reading the newspaper
If there is a crossword in the newspaper then try and complete the crossword

a) SC = 1 and DC = 1
b) SC = 1 and DC = 2
c) SC = 1 and DC = 3
d) SC = 2 and DC = 2
e) SC = 2 and DC = 3

16. The place to start if you want a (new) test tool is:
a) Attend a tool exhibition
b) Invite a vendor to give a demo
c) Analyse your needs and requirements
d) Find out what your budget would be for the tool
e) Search the internet

17. When a new testing tool is purchased, it should be used first by:
a) A small team to establish the best way to use the tool
b) Everyone who may eventually have some use for the tool
c) The independent testing team
d) The managers to see what projects it should be used in
e) The vendor contractor to write the initial scripts

18. What can static analysis NOT find?
a) The use of a variable before it has been defined
b) Unreachable (“dead”) code
c) Whether the value stored in a variable is correct
d) The re-definition of a variable before it has been used
e) Array bound violations

19. Which of the following is NOT a black box technique:
a) Equivalence partitioning
b) State transition testing
c) LCSAJ
d) Syntax testing
e) Boundary value analysis



20. Beta testing is:
a) Performed by customers at their own site
b) Performed by customers at their software developer’s site
c) Performed by an independent test team
d) Useful to test bespoke software
e) Performed as early as possible in the lifecycle

21. Given the following types of tool, which tools would typically be used by developers and which by an independent test team:
i. static analysis
ii. performance testing
iii. test management
iv. dynamic analysis
v. test running
vi. test data preparation

a) developers would typically use i, iv and vi; test team ii, iii and v
b) developers would typically use i and iv; test team ii, iii, v and vi
c) developers would typically use i, ii, iii and iv; test team v and vi
d) developers would typically use ii, iv and vi; test team I, ii and v
e) developers would typically use i, iii, iv and v; test team ii and vi

22. The main focus of acceptance testing is:
a) finding faults in the system
b) ensuring that the system is acceptable to all users
c) testing the system with other systems
d) testing for a business perspective
e) testing by an independent test team

23. Which of the following statements about the component testing standard is false:
a) black box design techniques all have an associated measurement technique
b) white box design techniques all have an associated measurement technique
c) cyclomatic complexity is not a test measurement technique
d) black box measurement techniques all have an associated test design technique
e) white box measurement techniques all have an associated test design technique

24. Which of the following statements is NOT true:
a) inspection is the most formal review process
b) inspections should be led by a trained leader
c) managers can perform inspections on management documents
d) inspection is appropriate even when there are no written documents
e) inspection compares documents with predecessor (source) documents

25. A typical commercial test execution tool would be able to perform all of the following EXCEPT:
a) generating expected outputs
b) replaying inputs according to a programmed script
c) comparison of expected outcomes with actual outcomes
d) recording test inputs
e) reading test values from a data file

26. The difference between re-testing and regression testing is
a) re-testing is running a test again; regression testing looks for unexpected side effects
b) re-testing looks for unexpected side effects; regression testing is repeating those tests
c) re-testing is done after faults are fixed; regression testing is done earlier
d) re-testing uses different environments, regression testing uses the same environment
e) re-testing is done by developers, regression testing is done by independent testers

27. Expected results are:
a) only important in system testing
b) only used in component testing
c) never specified in advance
d) most useful when specified in advance
e) derived from the code

28. Test managers should not:
a) report on deviations from the project plan
b) sign the system off for release
c) re-allocate resource to meet original plans
d) raise incidents on faults that they have found
e) provide information for risk analysis and quality improvement

29. Unreachable code would best be found using:
a) code reviews
b) code inspections
c) a coverage tool
d) a test management tool
e) a static analysis tool

30. A tool that supports traceability, recording of incidents or scheduling of tests is called:
a) a dynamic analysis tool
b) a test execution tool
c) a debugging tool
d) a test management tool
e) a configuration management tool

31. What information need not be included in a test incident report:
a) how to fix the fault
b) how to reproduce the fault
c) test environment details
d) severity, priority
e) the actual and expected outcomes

32. Which expression best matches the following characteristics or review processes:1. led by author
2. undocumented
3. no management participation
4. led by a trained moderator or leader
5. uses entry exit criteria

s) inspection
t) peer review
u) informal review
v) walkthrough

a) s = 4, t = 3, u = 2 and 5, v = 1
b) s = 4 and 5, t = 3, u = 2, v = 1
c) s = 1 and 5, t = 3, u = 2, v = 4
d) s = 5, t = 4, u = 3, v = 1 and 2
e) s = 4 and 5, t = 1, u = 2, v = 3

33. Which of the following is NOT part of system testing:
a) business process-based testing
b) performance, load and stress testing
c) requirements-based testing
d) usability testing
e) top-down integration testing

34. What statement about expected outcomes is FALSE:
a) expected outcomes are defined by the software’s behaviour
b) expected outcomes are derived from a specification, not from the code
c) expected outcomes include outputs to a screen and changes to files and databases
d) expected outcomes should be predicted before a test is run
e) expected outcomes may include timing constraints such as response times

35. The standard that gives definitions of testing terms is:
a) ISO/IEC 12207
b) BS7925-1
c) BS7925-2
d) ANSI/IEEE 829
e) ANSI/IEEE 729

36. The cost of fixing a fault:
a) Is not important
b) Increases as we move the product towards live use
c) Decreases as we move the product towards live use
d) Is more expensive if found in requirements than functional design
e) Can never be determined

37. Which of the following is NOT included in the Test Plan document of the Test Documentation Standard:
a) Test items (i.e. software versions)
b) What is not to be tested
c) Test environments
d) Quality plans
e) Schedules and deadlines

38. Could reviews or inspections be considered part of testing:
a) No, because they apply to development documentation
b) No, because they are normally applied before testing
c) No, because they do not apply to the test documentation
d) Yes, because both help detect faults and improve quality
e) Yes, because testing includes all non-constructive activities

39. Which of the following is not part of performance testing:
a) Measuring response time
b) Measuring transaction rates
c) Recovery testing
d) Simulating many users
e) Generating many transactions

40. Error guessing is best used
a) As the first approach to deriving test cases
b) After more formal techniques have been applied
c) By inexperienced testers
d) After the system has gone live
e) Only by end users

Answers:
1 C
2 C
3 E
4 E
5 C
6 A
7 B
8 B
9 C
10 E
11 B
12 B
13 B
14 B
15 E
16 C
17 B
18 C
19 C
20 A
21 B
22 D
23 A
24 D
25 A
26 A
27 D
28 C
29 A
30 E
31 E
32 B
33 E
34 A
35 B
36 B
37 D
38 D
39 C
40 B

ISTQB Foundation Sample Question Paper No 7

1. Deciding How much testing is enough should take into account :-
i. Level of Risk including Technical and Business product and project risk
ii. Project constraints such as time and budget
iii. Size of Testing Team
iv. Size of the Development Team

a) i,ii,iii are true and iv is false
b) i,,iv are true and ii is false
c) i,ii are true and iii,iv are false
d) ii,iii,iv are true and i is false


2. Test planning has which of the following major tasks?
i. Determining the scope and risks, and identifying the objectives of testing.
ii. Determining the test approach (techniques,test items, coverage, identifying and interfacing the teams involved in testing , testware)
iii. Reviewing the Test Basis (such as requirements,architecture,design,interface)
iv. Determining the exit criteria.

a) i,ii,iv are true and iii is false
b) i,,iv are true and ii is false
c) i,ii are true and iii,iv are false
d) ii,iii,iv are true and i is false


3. Evaluating testability of the requirements and system are a part of which phase:-
a) Test Analysis and Design
b) Test Planning and control
c) Test Implementation and execution
d) Evaluating exit criteria and reporting


4. One of the fields on a form contains a text box which accepts alphabets in lower or upper case. Indentify the invalid Equivalance class value.
a. CLASS
b. cLASS
c. CLass
d. CLa01ss


5. In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free. The next £1500 is taxed at 10% The next £28000 is taxed at 22% Any further amount is taxed at 40% Which of these groups of numbers would fall into the same equivalence class?
a) £4800; £14000; £28000
b) £5200; £5500; £28000
c) £28001; £32000; £35000
d) £5800; £28000; £32000


6. Which of the following has highest level of independence in which test cases are :
a) Designed by persons who write the software under test
b) Designed by a person from a different section
c) Designed by a person from a different organization
d) Designed by another person


7. We use the output of the requirement analysis, the requirement specification as the input for writing :-
a) User Acceptance Test Cases
b) Integration Level Test Cases
c) Unit Level Test Cases
d) Program specifications


8. Validation involves which of the following
i. Helps to check the Quality of the Built Product
ii. Helps to check that we have built the right product.
iii. Helps in developing the product
iv. Monitoring tool wastage and obsoleteness.

a) Options i,ii,iii,iv are true.
b) ii is true and i,iii,iv are false
c) i,ii,iii are true and iv is false
d) iii is true and i,ii,iv are false.


9. Which of the following uses Impact Analysis most?
a) Component testing
b) Non-functional system testing
c) User acceptance testing
d) Maintenance testing


10. What is the expected result for each of the following test cases?

A. Citibank card member, holding a Silver room
B. Non Citibank-member, holding a Platinum room

a) A – Don’t offer any upgrade, B – Don’t offer any upgrade.
b) A – Don’t offer any upgrade, B – Offer upgrade to Gold.
c) A – Offer upgrade to Silver, B – Offer upgrade to Silver.
d) A – Offer upgrade to Gold, B – Don’t offer any upgrade.

11. Repeated Testing of an already tested program, after modification, to discover any defects introduced or uncovered as a result of the changes in the software being tested or in another related or unrelated software component:
a) Re Testing .
b) Confirmation Testing
c) Regression Testing
d) Negative Testing


12. Impact Analysis helps to decide :-a) How much regression testing should be done.
b) Exit Criteria
c) How many more test cases need to written.
d) Different Tools to perform Regression Testing


13. Functional system testing is:
a) testing that the system functions with other systems
b) testing that the components that comprise the system function together
c) testing the end to end functionality of the system as a whole
d) testing the system performs functions within specified response times

14. Consider the above state transition diagram of a switch.
Which of the following represents an invalid state transition?
a) OFF to ON
b) ON to OFF
c) FAULT to ON


15. Peer Reviews are also called as :-a) Inspection
b) Walkthrough
c) Technical Review
d) Formal Review


16. Consider the following statements:
i. 100% statement coverage guarantees 100% branch coverage.
ii. 100% branch coverage guarantees 100% statement coverage.
iii. 100% branch coverage guarantees 100% decision coverage.
iv. 100% decision coverage guarantees 100% branch coverage.
v. 100% statement coverage guarantees 100% decision coverage.

a) ii is True; i, iii, iv & v are False
b) i & v are True; ii, iii & iv are False
c) ii & iii are True; i, iv & v are False
d) ii, iii & iv are True; i & v are False

17. The Kick Off phase of a formal review includes the following :-
a) Explaining the objective
b) Fixing defects found typically done by author
c) Follow up
d) Individual Meeting preparations


18. Match every stage of the software Development Life cycle with the Testing Life cycle:i. Hi-level design a Unit tests
ii. Code b Acceptance tests
iii. Low-level design c System tests
iv. Business requirements d Integration tests

a) i-d , ii-a , iii-c , iv-b
b) i-c , ii-d , iii-a , iv-b
c) i-b , ii-a , iii-d , iv-c
d) i-c , ii-a , iii-d , iv-b


19. Which of the following is not phase of the Fundamental Test Process?a) Test Planning and Control
b) Test implementation and Execution
c) Requirement Analysis
d) Evaluating Exit criteria and reporting


20. Which of the following techniques is NOT a black box technique?
a) State transition testing
b) LCSAJ (Linear Code Sequence and Jump)
c) syntax testing
d) boundary value analysis


21. Success Factors for a review include :
i. Each Review does not have a predefined objective
ii. Defects found are welcomed and expressed objectively
iii. Management supports a good review process.
iv. There is an emphasis on learning and process improvement.

a) ii,iii,iv are correct and i is incorrect
b) iii , i , iv is correct and ii is incorrect
c) i , iii , iv , ii is in correct
d) ii is correct


22. Defects discovered by static analysis tools include :
i. Variables that are never used.
ii. Security vulnerabilities.
iii. Programming Standard Violations
iv. Uncalled functions and procedures

a) i , ii,iii,iv is correct
b) iii ,is correct I,ii,iv are incorrect.
c) i ,ii, iii and iv are incorrect
d) iv, ii is correct


23. Test Conditions are derived from :-
a) Specifications
b) Test Cases
c) Test Data
d) Test Design


24. Which of the following is true about White and Black Box Testing Technique:-
a) Equivalance partitioning, Decision Table and Control flow are White box Testing Techniques.
b) Equivalence partitioning , Boundary Value Analysis , Data Flow are Black Box Testing Techniques.
c) Equivalence partitioning , State Transition , Use Case Testing are black box Testing Techniques.
d) Equivalence Partioning , State Transition , Use Case Testing and Decision Table are White Box Testing Techniques.


25. Regression testing should be performed:
i. every week
ii. after the software has changed
iii. as often as possible
iv. when the environment has changed
v. when the project manager says

a) i & ii are true, iii, iv & v are false
b) ii, iii & iv are true, i & v are false
c) ii & iv are true, i, iii & v are false
d) ii is true, i, iii, iv & v are false


26. Benefits of Independent Testing
a) Independent testers are much more qualified than Developers
b) Independent testers see other and different defects and are unbiased.
c) Independent Testers cannot identify defects.
d) Independent Testers can test better than developers


27. Minimum Tests Required for Statement Coverage and Branch Coverage :-Read P
Read Q
If p+q > 100 then
Print “Large”
End if
If p > 50 then
Print “pLarge”
End if
a) Statement coverage is 2, Branch Coverage is 2
b) Statement coverage is 3 and branch coverage is 2
c) Statement coverage is 1 and branch coverage is 2
d) Statement Coverage is 4 and Branch coverage is 2


28. Minimum Test Required for Statement Coverage :-Disc = 0
Order-qty = 0
Read Order-qty
If Order-qty >=20 then
Disc = 0.05
If Order-qty >=100 then
Disc =0.1
End if
End if

a) Statement coverage is 4
b) Statement coverage is 1
c) Statement coverage is 3
d) Statement Coverage is 2


29. The structure of an incident report is covered in the Standard for Software Test Documentation IEEE 829 and is called as : -
a) Anomaly Report
b) Defect Report
c) Test Defect Report
d) Test Incident Report


30. Which of the following is the task of a Test Lead / Leader.
i. Interaction with the Test Tool Vendor to identify best ways to leverage test tool on the project.
ii. Write Test Summary Reports based on the information gathered during testing
iii. Decide what should be automated , to what degree and how.
iv. Create the Test Specifications

a) i, ii, iii is true and iv is false
b) ii,iii,iv is true and i is false
c) i is true and ii,iii,iv are false
d) iii and iv is correct and i and ii are incorrect


31. Features of White Box Testing Technique :-i. We use explicit knowledge of the internal workings of the item being tested to select the test data.
ii. Uses specific knowledge of programming code to examine outputs and assumes that the tester knows the path of logic in a unit or a program.
iii. Checking for the performance of the application
iv. Also checks for functionality.
a) i, ii are true and iii and iv are false
b) iii is true and i,ii, iv are false
c) ii ,iii is true and i,iv is false
d) iii and iv are true and i,ii are false


32. Which of the following is a part of Test Closure Activities?i. Checking which planned deliverables have been delivered
ii. Defect report analysis.
iii. Finalizing and archiving testware.
iv. Analyzing lessons.
a) i , ii , iv are true and iii is false
b) i , ii , iii are true and iv is false
c) i , iii , iv are true and ii is false
d) All of above are true


33. Which of the following will be the best definition for Testing :-a) The goal / purpose of testing is to demonstrate that the program works.
b) The purpose of testing is to demonstrate that the program is defect free.
c) The purpose of testing is to demonstrate that the program does what it is supposed to do.
d) Testing is executing Software for the purpose of finding defects.


34. Which of the following is not a type of incremental testing approach?a) Top down
b) Big-bang
c) Bottom up
d) Functional incrementation.


35. Drivers are also known as:
i. Spade
ii. Test harness
iii. Scaffoldinga) i , ii are true and iii is false
b) i , iii are true and ii is false
c) ii , iii are true and i is false
d) All of the above are true


36. Exit Criteria may consist of :-i. Thoroughness measures , such as coverage of code, functionality or risk
ii. Estimates of Defect density or reliability measures.
iii. Residual risk such as defects not fixed or lack of test coverage in certain areas
iv. Verifying the Test Environment.
a) iv is correct and i,ii,iii are incorrect.
b) i,ii,iii is correct and iv is incorrect
c) ii is correct and i,ii,iii are incorrect
d) iii and iv are correct and i,ii are incorrect


37. Which of the following helps in monitoring the Test Progress:-i. Percentage of Test Case Execution
ii. Percentage of work done in test environment preparation.
iii. Defect Information e.g. defect density, defects found and fixed
iv. The size of the testing Team and skills of the engineers

a) iv is correct and i,ii,iii are incorrect
b) i,ii,iii are correct and iv is incorrect
c) i,ii are correct and iii,iv are incorrect
d) i,iv are correct and ii , iii are incorrect


38. The selection of a test approach should consider the context :-i. Risk of Failure of the Project, hazards to the product and risks of product failure to humans
ii. Skills and experience of the people in the proposed technique, tools and methods
iii. The objective of the testing endeavor and the mission of the testing team.
iv. The size of the testing Team

a) i,ii,iii,iv are true
b) i,ii,iii are true and iv is false.
c) ii,iii,iv are true and i is false.
d) i,iv are true and ii, iii are false.


39. In case of Large Systems :-a) Only few tests should be run
b) Testing should be on the basis of Risk
c) Only Good Test Cases should be executed.
d) Test Cases written by good test engineers should be executed.


40. The Provision and Management of a controlled library containing all the configurations items is called asa) Configuration Control
b) Status Accounting
c) Configuration Identification
d) Configuration Identification


Answers :

1 c
2 a
3 a
4 d
5 d
6 c
7 a
8 b
9 d
10 d
11 c
12 a
13 c
14 c
15 c
16 d
17 a
18 d
19 c
20 b
21 a
22 a
23 a
24 c
25 c
26 b
27 c
28 b
29 a
30 a
31 a
32 c
33 d
34 b
35 c
36 b
37 b
38 b
39 b
40 a