Introduction Flashcards
(134 cards)
1
Q
What is Software Testing?
A
Software testing is an investigation conducted to provide stakeholders with information about the quality (the degree to which a product meets customer expectations) of the product or service under test.
Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation.
Software testing can be stated as the process of validating and verifying that a computer program/ application/ product: meets the requirements that guided its design and development works as expected can be implemented with the same characteristics satisfies the needs of stakeholders.
2
Q
What does Poppendieck’s theory tell us about the development cycle and the need for testing…
A
Poppendieck’s estimate that each handoff leaves
behind approximately 50% of the knowledge we intend to transfer
3
Q
What is Positive Testing?
A
Does the software meet the requirements ?
Do the requirements meet the users needs ?
4
Q
What is Negative Testing?
A
Finding defects in code and requirements
Trying to break the system
Demonstrating it does not do what its not supposed to do
5
Q
What two features of a product must be assessed by testing?
A
Quality
The degree to which a component, system or process meets the specified requirements and/or user/customer needs and expectations.
Risk
A factor that could give negative consequences; usually expressed as impact and likelihood
6
Q
What is the Test Basis?
A
All documents from which the requirements of a component or system can beinferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure, then the test basis is called a frozentest basis.
7
Q
What is a Test Condition?
A
An item or event of a component or system that could be verified by one or more test cases, e.g. a function, transaction, feature, quality attribute, or structural element.
8
Q
What is a Test Case?
A
A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement.
9
Q
What are the 5 Main activities in the Testing process?
A
Test Planning and Control Test Analysis and Design Test Implementation and Execution. Evaluating Exit Criteria and Reporting (can loop back to any previous stage and move down through again) Test Closure
10
Q
What is Test Planning?
A
The activity of defining the objectives of testing and the testing activities
11
Q
What is Test Control?
A
The on-going activity of comparing progress against the plan and reporting status
12
Q
What tasks are involved in the Test Analysis and Design
phase?
A
Reviewing the test basis
Evaluating the testability of the test basis
Identifying and prioritising test conditions
Designing and prioritising high level test cases
Identifying necessary test data
Designing the test environment set-up
Identifying any required infrastructure and tools
Creating bi-directional traceability
Test cases to test basis
Test basis to test cases
13
Q
What tasks are involved in the Test Implementation and Execution phase?
A
Finalising and prioritising test cases
Finalising the test data
Developing and prioritising test procedures
Creating the test data
Preparing test harnesses
Writing automated test scripts
Creating test suites from the test procedures for efficiency
Verifying the test environment has been set up correctly
Verifying traceability between test basis and test cases
Executing test procedures in planned sequence
Manually or using test execution tools
Logging the outcome of test execution
Comparing actual results with expected results
Recording discrepancies as incidents
Analysing incidents for causes
Repeating test activities (with any necessary regression)
14
Q
What tasks are involved in the Evaluating Exit Criteria and Reporting phase?
A
Checking logs against exit criteria specified in Test Planning
Assessing if more tests are required
Assessing if exit criteria need changing
Writing a test summary for stakeholders
15
Q
What tasks are involved in the Test Closure phase?
A
Checking planned deliverables have been delivered
Closing incident reports
Raising change records for remaining open incidents
Documenting the acceptance of the system
Finalising and archiving test-ware and test environment
Analysing lessons learned
Using information gathered to improve test maturity (retrospective)
16
Q
What are the Seven Principles of Testing?
A
Testing shows the presence of defects Exhaustive testing is impossible Early testing Defect Clustering Pesticide paradox Testing is context dependent Absence-of-errors fallacy
17
Q
Explain the principle: Testing shows the presence of defects?
A
Testing can show the defects are present, but cannot prove that there are no defects. Even after testing the application or product thoroughly we cannot say that the product is 100% defect free.
Testing always reduces the number of undiscovered defects remaining in the software but even if no defects are found, it is not a proof of correctness.
18
Q
Explain the principle: Exhaustive testing is impossible?
A
Testing everything including all combinations of inputs and preconditions is not possible. So, instead of doing exhaustive testing we can use risks and priorities to focus testing efforts.
For example: In an application in one screen there are 15 input fields, each having 5 possible values, then to test all the valid combinations you would need 30,517,578,125 (515) tests. This is very unlikely that the project timescales would allow for this number of tests. So, accessing and managing risk is one of the most important activities and reason for testing in any project.
19
Q
Explain the principle: Early testing?
A
In the software development life cycle testing activities should start as early as possible and should be focused on defined objectives.
20
Q
Explain the principle: Defect Clustering?
A
A small number of modules contains most of the defects discovered during pre-release testing or shows the most operational failures.
21
Q
Explain the principle: Pesticide paradox?
A
If the same kinds of tests are repeated again and again, eventually the same set of test cases will no longer be able to find any new bugs. To overcome this “Pesticide Paradox”, it is really very important to review the test cases regularly and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
22
Q
Explain the principle: Testing is context dependent?
A
Testing is basically context dependent. Different kinds of sites are tested differently. For example, safety – critical software is tested differently from a free mobile app.
23
Q
Explain the principle: Absence-of-errors fallacy?
A
If the system built is unusable and does not fulfil the user’s needs and expectations then finding and fixing defects does not help.
24
Q
What are the differences between the mindset of a Developer vs a Tester?
A
Developer:
The software is of acceptable quality and will work
Tend to look for what works
Thinks testers are too negative and pedantic
Tester:
The software contains defects and won’t work
Tend to look for what does not work
Thinks developers are too optimistic
25
What attributes are present in an effective Testing Team?
Promote collaboration not battles
Remind all of common goal
Communicate failures found in a neutral fact-focused way
Do not criticise the author
Understand how the other person feels
Try to understand why they react the way they do
Confirm the other person understands what you have said and vice-versa
26
What makes a good Tester?
```
Curiosity
Professional pessimism
A critical eye
Attention to detail
Good communicator
Experience on which to base error guessing
```
27
What is Verification
Confirmation by examination and through the provision of objective evidence that specified requirements have been fulfilled [ISO 9000]
"Are we building the product right?"
28
What is Validation (fit for purpose)
Confirmation by examination and through the provision of objective evidence that the requirements for a specific intended use or application have been fulfilled [ISO 9000]
"Are we building the right product?"
29
Define Component Testing...
Searches for defects in and verifies the functioning of software modules, programs, objects, classes etc. that are separately testable. Usually takes place during the coding phase.
30
What is TDD, Test Driven Design?
Test-driven design (TDD) is a development technique where you must first write a test that fails before you write new functional code. TDD is being quickly adopted by agile software developers for development of application source code
31
Define Integration Testing...
Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems
Component Integration Testing -
performed to expose defects in the interfaces and interaction between integrated components.
System Integration Testing -
Testing the integration of systems and packages; testing interfaces to external organisations.
32
Explain two Integration Testing Strategies
Incremental (recommended)
One interface at a time
Can be Top down, Bottom Up or Functional task
```
Big Bang (to be avoided)
All interfaces at the same time
```
33
What is a Driver?
A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system.
34
What is a Stub?
A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component.
35
What is a Test Harness?
A test environment comprised of stubs and drivers needed to execute a test.
36
What is System Testing?
Concerned with the behaviour of the whole system/product. The Test Environment should correspond to the final target environment.
System testing should investigate both Functional and Non Functional requirements of the system.
37
What is Functional System Testing?
Functional Testing – Testing of function, starts with appropriate specification-based (black box) techniques for the aspect of the system to be tested. E.g. Decision table.
Functional Testing also assess Security &Interoperability
(The ability of the software product to interact with one or more specified components or systems)
38
What s Non-Functional System Testing?
Non functional - Testing of non-functional software characteristics, Structure based techniques (white box) – may then be used to assess the thoroughness of the testing with respect to a structural element e.g. a menu structure or web page navigation.
39
What is Acceptance Testing?
Users testing the software
| Often the responsibility of the users or customers of the system. Builds confidence / assesses readiness.
40
Acceptance Testing: What is UAT (User Acceptance Testing)?
Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user, customers or other authorised entity to determine whether or not to accept the system.
41
Acceptance Testing: What is OAT : operational acceptance testing?
Operational testing in the acceptance test phase,
typically performed in a (simulated) operational environment by operations and/or systems administration staff focusing on operational aspects, e.g. recoverability, resource-behaviour, and technical compliance.
42
Acceptance Testing: What is CAT (Contract Acceptance Testing) and Regulation Acceptance Test?
In contract acceptance testing, a system is tested against acceptance criteria as documented in a contract, before the system is accepted.
In regulation acceptance testing, a system is tested to ensure it meets governmental, legal and safety standards.
43
Acceptance Testing: What is Alpha Testing?
Simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site, but outside the development organisation.
44
Acceptance Testing: What is Beta Testing?
Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing for off-the-shelf software in order to acquire feedback from the market.
45
What are the Four Types of Testing?
Functional - Testing of function
Non functional - Testing of non-functional software characteristics
Structure - Testing of Software Structure
Change related - Testing related to changes in software (Re-testing, Regression testing)
46
What is Black Box Testing?
Functional Testing concerns the external behaviour of the system (Black Box). This method is named because the software program or system, in the eyes of the tester, is like a black box; inside which one cannot see. Black Box Testing method is applicable to all levels of the software testing process:
47
Non-Functional Testing: Define Performance Testing?
Determine how fast some aspect of a system performs under a particular workload.
Purposes -
- demonstrate that the system meets performance
criteria.
- compare two systems to find which performs
better.
- measure what part of the system or workload
causes the system to perform badly.
48
Non-Functional Testing: Define Load Testing?
- Conducted to understand the behaviour of the application under a specific expected load.
- Performed to determine a system’s behaviour under both normal and at peak conditions. It helps to identify the maximum operating capacity of an application as well as any bottlenecks and determine which element is causing degradation.
- Involves simulating real-life user load for the
target application. It helps you determine how your application behaves when multiple users hit it simultaneously.
49
Non-Functional Testing: Define Stress Testing?
Involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results.
It is a form of software testing that is used to determine the stability of a given system.
50
Non-Functional Testing: Define Usability Testing?
– How easy it is to use the software.
– How easy it is to learn the software.
– How convenient is the software to end user.
Usability testing includes the following components:
Learnability, Efficiency, Memorability, Errors, Satisfaction
51
Non-Functional Testing: Define Maintainability Testing?
How easy it is to maintain the system. This means that how easy it is to analyse, change and test the application or product.
Specified in terms of the effort required to effect a change in :
Corrective maintenance
Perfective maintenance
Adaptive maintenance
Preventive maintenance
52
Non-Functional Testing: Define Reliability Testing?
Exercising an application so that failures are discovered and removed before the system is deployed.
Software Reliability is the probability of failure-free software operation for a specified period of time in a specified environment. Includes maturity (robustness), fault-tolerance, recoverability and compliance.
53
Non-Functional Testing: Define Portability Testing?
The ease to which a software product can be transferred from one hardware or software environment to another.
54
What us Structure/Architecture Testing?
Also known as ‘white-box’ or ‘glass-box’ testing technique, Structure Testing measures the extent to which a structure has been exercised by tests. Expressed as a percentage 100% is full coverage
Less indicates that more tests may be necessary
Usually measured by tools
Structure-based techniques can also be used at all levels of testing.
55
What is Re-testing testing
After a defect is detected and fixed, the software should be retested to confirm that the original defect as been successfully removed. Known as retesting or confirmation testing.
56
What is Debugging?
Locating and fixing a defect; a development activity, not a testing activity.
57
What is Regression Testing
Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made.
It is performed when the software or its environment is changed.
The extent of regression testing is based on the risk of not finding defects in software that was working previously.
58
What is Static Testing?
Unlike dynamic testing (which requires the execution of software) static testing relies on the manual examination (reviews) and automated analysis of the code or other project documentation without the execution of the code.
Much cheaper to detect (and remove) detects early in the lifecycle.
59
Static Tools: What are Reviews?
Reviews are a way of testing software work products (including code)
May be performed well in advance of dynamic testing execution.
A review may be entirely manual or use tool support.
The main activity is to examine a work product and make comments about it.
Includes automated execution of code or other project documentation
60
What are the benefits of Reviews as a Static Tool?
```
Early defect detection and correction
Development productivity improves
Reduced development timescales
Reduced testing time and cost
Lifetime cost reductions
Fewer defects
Improved communication
```
61
Review Types: What is a Inspection/Formal Review?
Formal reviews follow a very formal process. It is well structured and regulated.
62
What are the Stages involved in a formal Review Process?
```
A formal review process consists of six main steps:
Planning
Kick-off (optional)
Preparation
Review meeting
Rework
Follow-up
```
63
What are the types of Reviews that come under static testing?
```
Most Formal/Effective
=======================
Inspection / Formal Review
Technical review
Walkthrough
Informal review
=======================
Least Formal/Effective
```
64
What are the features of an informal Review?
```
Not based on a formal process
Could be :
Paired programming
Technical lead reviewing designs and code
Varies in usefulness
```
Inexpensive and quick
65
Formal Review Phases: Explain the Overview Planning Phase...
Request for a review by the author to the moderator
A moderator responsible for scheduling date, time, place and invitation of the review.
The moderator performs the entry check and also defines the formal exit criteria.
The entry check is done to ensure that the reviewer’s time is not wasted on a document that is not ready for review.
After doing the entry check if the document is found to have very little defects then it’s ready to go for the reviews.
66
Formal Review Phases: Explain the Preparation Phase...
The reviewers review the document individually using the related documents, procedures, rules and checklists provided.
Each participant while reviewing individually identifies the defects, questions and comments according to their understanding of the document and role.
All issues are recorded using a logging form.
The success factor for a thorough preparation is the number of pages checked per hour. This is called the checking rate. Usually the checking rate is in the range of 5 to 10 pages per hour.
67
Formal Review Phases: Explain the Meeting Phase...
All issues and the defects that have been identified during the preparation step are logged page by page.
The logging is basically done by the author or by a scribe.
Every defect and severity should be logged :
– Critical: The defects will cause downstream damage.
– Major : The defects could cause a downstream damage.
– Minor : The defects are highly unlikely to cause the downstream damage.
68
Formal Review Phases: Explain the Rework Phase...
Fixing defects found.
Not every defect that is found leads to rework. It is the author’s responsibility to judge whether the defect has to be fixed.
If nothing can be done about an issue then at least it should be indicated that the author has considered the issue.
Changes should be traceable (Track changes in word processing software).
69
Formal Review Phases: Explain the Follow-up Phase...
The moderator checks to make sure that the author has taken action on all known defects.
If it is decided that all participants will check the updated documents then the moderator takes care of the distribution and collects the feedback.
It is the responsibility of the moderator to ensure that the information is correct and stored for future analysis.
70
Review Types: What is a Technical Review?
It is a less formal review than an Inspection
It is led by the trained moderator but can also be led by a technical expert
It is often performed as a peer review without management participation
Defects are found by the experts (such as architects, designers, key users) who focus on the content of the document.
In practice, technical reviews vary from quite informal to very formal
71
Review Types: What is a Walkthrough?
May be formal or informal process
It is led by the authors
Author guides the participants through the document according to his or her thought process to achieve a common understanding and to gather feedback.
Useful for the people if they are not from the software discipline, who are not used to or cannot easily understand software development process.
Is especially useful for higher level documents like requirement specification, etc.
72
What are the Factors for a Successful Review?
Clear predefined objectives
Right People (skill levels) - Includes testers
Mindset -Defects welcomed, Trustful atmosphere
Support -Checklists, Training, Management support
73
In order to be considered a "good requirement", a requirement must be Unambiguous? Explain this concept...
There should be only one way to interpret the requirement. Sometimes ambiguity is introduced by undefined acronyms:
74
In order to be considered a "good requirement", a requirement must be Testable (verifiable)? Explain this concept...
Testers should be able to verify whether the requirement is implemented correctly. The test should either pass or fail. To be testable, requirements should be clear, precise, and unambiguous.
75
In order to be considered a "good requirement", a requirement must be Clear (concise, terse, simple, precise)? Explain this concept...
Requirements should not contain unnecessary verbiage or information. They should be stated clearly and simply.
76
In order to be considered a "good requirement", a requirement must be Correct? Explain this concept...
If a requirement contains facts, these facts should be true.
77
In order to be considered a "good requirement", a requirement must be Understandable? Explain this concept...
Requirements should be grammatically correct and written in a consistent style. Standard conventions should be used. The word “shall” should be used instead of “will,” “must,” or “may.”
78
In order to be considered a "good requirement", a requirement must be Feasible (realistic, possible)? Explain this concept...
The requirement should be doable within existing constraints such as time, money, and available resources.
79
In order to be considered a "good requirement", a requirement must be Independent? Explain this concept...
To understand the requirement, there should not be a need to know any other requirement.
80
In order to be considered a "good requirement", a requirement must be Atomic? Explain this concept...
The requirement should contain a single traceable element.
81
In order to be considered a "good requirement", a requirement must be consistent? Explain this concept...
Indirect conflict occurs when requirements do not describe the same functionality, but it is not possible to achieve both requirements at the same time:
82
In order to be considered a "good requirement", a requirement must be Implementation-free (abstract)? Explain this concept...
Requirements should not contain unnecessary design and implementation information.
83
In order to be considered a "good requirement", a requirement must be Traceable? Explain this concept...
If it is atomic and has a unique ID, it is usually traceable. Establishing traceability from test conditions to requirements:
- Enables effective impact analysis when requirements change
- Enables determination of requirements coverage for a set of tests.
84
What is Maintenance Testing?
Once a system is deployed it may be in service for years.
During this time the system and its operational environment is often corrected, changed or extended.
Testing that is provided during this phase is called maintenance testing.
Triggered by -
Modifications
Migration
Retirement of software
85
Explain the types of Modifications that can happen to a piece of software...
Planned enhancements (e.g. release based) e.g. new feature
Corrective and emergency changes
e.g. accumulated bug fixes, security issue
Changes in environment
Operating system or database updates
Patched to fix newly exposed vulnerabilities in the operating system
86
What is Migration?
Migration is moving from one platform to another
Also known as (conversion testing)
Requires operational tests of the new environment as well as the new software.
87
What is Retirement?
Maintenance testing for the retirement of a system may include the testing of the data migration or archiving if long term data- retention is required.
88
What is Impact Analysis?
Impact analysis is basically analysing the impact of the changes in the deployed application or product.
It tells us about the parts of the system that may be unintentionally affected because of changes in the application and therefore need careful regression testing.
This decision is taken together with the stakeholders.
89
What is a Compiler?
A Compiler can be considered as a static analysis tool because it builds a symbol table, points out incorrect usage and checks for non-compliance to coding language conventions or syntax.
90
What are Coding Standards?
Coding Standard consists of a set of programming rules, naming conventions.
There are many standards, usually a software development company will have their own version.
91
Why enforce Coding Standards?
Code conventions are important to programmers for a number of reasons:
- 80% of the lifetime cost of a piece of software goes to maintenance.
- Hardly any software is maintained for its whole life by the original author.
- Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
92
What is Cyclomatic Complexity?
The Cyclomatic complexity metrics is based on the number of decisions in a program.
Important for testing because it provides an indication of the amount of testing.
There are many ways to calculate cyclomatic complexity but the easiest way is to sum the number of binary decision statements (e.g. if, while, for, etc.) and add 1 to it.
93
What is Code Structure and what must be considered when dealing with it?
Information on the effort required to write the code in the first place, to understand the code while making the change, or to test the code using particular tools or techniques.
There are several aspects of code structure to consider:
Control flow structure: It addresses the sequence in which the instructions are executed.
Data flow structure: It follows the track of the data item as it is accessed and modified by the code.
Data structure: It refers to the organisation of the data itself, independent of the program.
94
What is the Test Analysis?
Test analysis is the process of looking at something that can be used to derive test information.
This basis for the tests is called the test basis.
95
Testing Phases: What is Design?
The act of creating and writing test suites for testing software.
Test analysis and identifying test conditions gives us a generic idea for testing which covers quite a large range of possibilities. But when we come to make a test case we need to be very specific...
96
Testing Phases: What is Implementation?
The document that describes the steps to be taken in running a set of tests and specifies the executable order of the tests is called a test procedure in IEEE 829, and is also known as a test script.
When the Test Procedure Specification is prepared and then implemented and is called Test implementation.
97
Testing Phases: What is Execution?
The combination of the data in the Test Cases (test data such as inputs, and expected outputs for each test case) combined with the Test Procedure Specification (the steps or instructions) …
98
What is Specification based Testing(BB)?
Also known as ‘black-box’ or input/output driven testing techniques because they view the software as a black-box with inputs and outputs.
The testers have no knowledge of how the system or component is structured inside the box.
In black-box testing the tester is concentrating on what the software does, not how it does it.
Both functional and non-functional testing
99
What is Equivalence Partitioning?
It can be applied at any level of testing and is often a good technique to use first.
The idea behind this technique is to divide (i.e. to partition) a set of test conditions into groups or sets that can be considered the same (i.e. the system should handle them equivalently), hence ‘equivalence partitioning’. Equivalence partitions are also known as equivalence classes – the two terms mean exactly the same thing.
100
Explain the concept of BVA Boundary Value Analysis...
Based on testing at the boundaries between partitions.
Here we have both valid boundaries (in the valid partitions) and invalid boundaries (in the invalid partitions).
Proves that the points at which the code changes have been encoded properly
For each boundary marker the 3 boundary values should be tested
101
Why use both EP(Equivalence Partitioning) and BVA(Boundary Value Analysis)?
Technically, because every boundary is in some partition, if you did only boundary value analysis you would also have tested every equivalence partition. However, this approach may cause problems if that value fails – was it only the boundary value that failed or did the whole partition fail?
Also by testing only boundaries we would probably not give the users much confidence as we are using extreme values rather than normal values.
102
What is Decision Table Testing?
Input conditions are identified.
Actions are the processes that should be executed by the system depending on the combinations of input combinations.
We identify a unique combination of conditions – (rules) – that result in the execution of one or more actions.
103
What is State Transition Testing?
State transition testing is used where some aspect of the system exhibits a different response depending on current conditions or previous history (state).
This simply means that the system can be in a number of different states.
The transitions from one state to another are determined by the rules of the system.
Testing includes valid and invalid state transitions.
104
How does State Transition Testing Work?
Each state is represented by a circle containing the name / description of the state.
The movement from one state to another – line with an arrow indicating the direction of the change.
Each transition will have an event - the trigger that cause the transition
Each transition will have an Action – a system activity that occurs as part of the transition. (optional)
It Is possible to have a transition that goes nowhere – returns to the original state
105
What is Use Case Testing?
Use case testing is a technique that helps us identify test cases that exercise the whole system on a transaction by transaction basis from start to finish.
A use case is a description of a particular use of the system by an actor (a user of the system). Each use case describes the interactions the actor has with the system in order to achieve a specific task.
Use cases are a sequence of steps that describe the interactions between the actor and the system.
106
What is Structure Based Testing(WB)?
Structure-based testing technique is also known as ‘white-box’ or ‘glass-box’ testing technique because here the testers require knowledge of how the software is implemented, how it works.
In white-box testing the tester is concentrating on how the software does it. For example, a structural technique may be concerned with exercising loops in the software.
107
What is Statement Coverage?
The statement coverage is also known as line coverage or segment coverage.
In component testing, it is the assessment of the percentage of executable statements that have been exercised by a test suit.
It derives test cases to execute specific statements, normally to increase statement coverage.
108
What is Decision Coverage?
A decision is an IF statement, a loop control statement (e.g. DO-WHILE or REPEAT-UNTIL), or a CASE statement, where there are two or more outcomes from the statement. With an IF statement, the exit can either be TRUE or FALSE, depending on the value of the logical condition that comes after IF.
109
What is Experience Based Testing?
The experience of both technical and business people is required, as they bring different perspectives to the test analysis and design process.
Because of the previous experience with similar systems, they may have an idea as what could go wrong, which is very useful for testing.
110
What is Error Guessing?
The Error guessing technique is where experienced testers are encouraged to think of situations in which the software may not be able to cope.
A structured approach to error guessing is to enumerate a list of possible defects and to design tests that attack these defects. This approach is known as a fault attack.
111
What is Exploratory Testing?
About exploring, finding out about the software, what it does, what it doesn’t do, what works and what doesn’t work.
The tester is constantly making decisions about what to test next and where to spend the (limited) time.
Useful when there are no or poor specifications and when time is severely limited.
112
What is JUnit Testing?
JUnit is a unit testing framework for the Java programming language.
JUnit is important in the development of test-driven development (TDD) and is one of a family of unit testing frameworks collectively known as xUnit.
113
Explain the Assert Statement used in a JUnit Test...
```
JUnit provides static methods in the Assert class to test for certain conditions.
These assertion methods typically start with assert and allow you to specify the error message, the expected and the actual result.
An assertion method compares the actual value returned by a test to the expected value, and throws an AssertionException if the comparison test fails.
```
114
Which Annotation...
| identifies that a method is a test method.
@Test
115
Which Annotation...
| Will execute the method before each test.
@Before
116
Which Annotation...
| Will execute the method after each test.
@After
117
Which Annotation...
| Will execute the method once, before the test cases are ran.
@BeforeClass
118
Which Annotation...
| Will execute the method once, after all tests have finished.
@AfterClass
119
Which Annotation...
| Will ignore the test method.
@Ignore
120
Which Annotation...
| Fails, if the method takes longer than 100 milliseconds.
@Test(timeout=100)
121
Which Annotation...
| Fails, if the method does not throw the named exception.
@Test (expected = Exception.class)
122
Which Assert Statement...
| Lets the method fail.
fail(String)
123
Which Assert Statement...
| Will always be true / false.
assertTrue(true) / assertTrue(false)
124
Which Assert Statement...
| Checks that the boolean condition is true.
assertTrue([message], boolean condition)
125
Which Assert Statement...
| Tests that two values are the same.
assertsEquals(expected, actual)
126
Which Assert Statement...
| Test that float or double values match.
assertsEquals(expected, actual, tolerance)
127
Which Assert Statement...
| Checks that the object is null
assertNull([message], object)
128
Which Assert Statement...
| Checks that the object is not null.
assertNotNull([message], object)
129
Which Assert Statement...
| Checks that both variables refer to the same object.
assertSame([String], expected, actual)
130
Which Assert Statement...
| Checks that both variables refer to different objects.
assertNotSame([String], expected, actual)
131
What are the Characteristics of a Good JUnit Test Case?
- Runs fast.
- Separates or simulates environmental dependencies such as databases, file systems, networks, queues and so on.
- Is very limited in scope.
- Clearly reveals its intention.
132
What are the Objectives of Incident Reports?
Provide developers and other parties with feedback about the problem to enable identification, isolation and correction as necessary.
Provide test leaders with a means of tracking the quality of the system under test and progress of the testing.
Provide ideas for test improvement.
133
What are the benefits of using Tools for Testing?
```
Automation of repetitive tasks
Consistency of use
Objective assessment
Improve performance of testing process
Perform functions that require a tool
```
134
What is the Probe Effect?
Some test tools (Intrusive) affect the outcome results. E.g. performance testing in which the tool results in log file output for testing purposes only.
