USA: +1(669)289-8683 
Sign in
Objective
The objective of this activity is to apply the principles and techniques of exploratory testing to your software project. By performing exploratory testing, you will uncover potential defects, gain a deeper understanding of your software’s behavior, and provide valuable feedback to improve its overall quality. Here are the tasks you have to do:
- Identify specific areas or functionalities within your software project that you want to target for exploratory testing. These areas could include critical user workflows, complex modules, or recently implemented features.
- Plan Exploratory Testing Sessions. Divide your exploratory testing into multiple sessions, each with a defined duration (e.g., 1 hour per session). Determine the number of sessions based on the complexity and size of your project. Aim for a sufficient number of sessions to cover significant functionality.
- Test Charter Creation. For each testing session, create test charters that outline the high-level goals, adopted tour (theme), areas to be explored, and key aspects to focus on during the session. These charters will guide your testing and help structure your exploration.
- Execute Exploratory Testing. Begin each testing session by following the designated test charter. Actively explore different paths, inputs, edge cases, and error scenarios. Be attentive to unexpected behaviors, potential defects, and areas of the software that require further investigation.
Document Findings. Document your exploratory testing findings, including observed behaviors, unexpected results, potential defects, and suggestions for improvements. Include relevant artifacts such as screenshots, logs, or video recordings to support your observations. You may use the template provided in the lesson to document the findings.
Test Tour
Object to be tested /
Rough Guidance
JIRA Issue
(Link or Text)
Test Duration
(Execution)
Tester
Further Testing
Opportunities?
Protocol
Nr
1
2
3
4
5
6
7
8
What done?
Status
Comment
Progress Report: Testing Open-Source
Application
1. Progress from Input Domain Modeling Progress:
JSoup is an open source, HTML parsing library written in Java. It includes all
the tools necessary to make an HTTP(S) request, read and parse
the response, and make the elements available for easy access. It is
typically used in web scraping applications and scripts. JSoup makes it easy
to work with real-world HTML and XML. It provides a user-friendly API for
DOM API methods, CSS, and xpath selectors (for XML).
The primary features of JSOUP that will be tested include:
Fetching and parsing HTML pages from a given URL
Selecting elements using CSS selectors or HTML Tags
Extracting data from the selected elements
These functions were selected for testing as they simulate several situations and
routines that are most common for JSoup applications. The tests focus on web
scraping; use of valid and invalid selectors; the use of valid and invalid URL; and the
presence or absence of HTML properties.
Below is a list of the input variables for the testable features:
URL
◦ String; the URL to the HTML document to be fetched
◦ E.g. https://en.wikipedia.org
CSS Selector
◦ String; the CSS selector to search for in the document
◦ E.g. #mp-itn
Attribute Name
◦ String; attribute used to select HTML elements
◦ E.g. title, nonexistent-attr
Next are the characteristics of the input variables:
URL:
◦ Valid URL – https://en.wikipedia.org
◦ Invalid URL – http://invalid-url[/]home
CSS Selector
◦ Valid Selector – #mp-itn b a
◦ Invalid Selector – #129invalid
Attribute Name
◦ Valid Attributes are ones that exist
▪ E.g. , ,
◦ Invalid Attributes do not exist within the document
▪ E.g. ,
The characteristics were partitioned and defined as follows:
URL:
Valid URL: “https://en.wikipedia.org/”
Invalid URL: “http://invalid-url”
No HTML content: https://example.com/no-html /mockup html page
content.
Complex HTML: “https://www.nytimes.com/”
CSS Selector:
Valid: “#mp-itn b a”
Invalid: “#invalid-selector”
Matches multiple: “div”
Matches none: “.nonexistent-class”
Attribute Name:
Valid: “title”
Invalid: “invalid-attr”
Present: “href”
Not present: “nonexistent-attr”
For the input domain modeling, it was determined that Pairwise Coverage
would be the best criteria for testing. This ensures that each pair of input
characteristics is tested at least once.
Below is the test set based on Pairwise Coverage:
Test Case
URL
CSS Selector
Attribute Name
1
https://en.wikipedia.org/
#mp-itn b a
title
2
https://en.wikipedia.org/
#invalid-selector
href
3
http://invalid-url
div
title
4
https://example.com/nohtml
.nonexistent-class
invalid-attr
/mockup
content.
5
html
page
https://www.nytimes.com/ div
nonexistent-attr
Execute the test cases on the application and report the results.
[Provide the outcomes of the executed test cases, including any issues or
observations.]
2. Progress from Graph-Based Testing Progress:
There are two primary features that were selected for Graph-based testing.
These two features were the HttpConnection.connect() function that
connects to the URL, and then QueryParser.parse() function that parses the
HTML
document
returned
by
the
HTTP
endpoint.
The
HttpConnection.connect() function branches primarily to throw exceptions for
invalid protocols or invalid URLs. The QueryParser.parse() function tends to
branch based on the embedded nature of the HTML tree.
The below graph model is based on a test function that performs a basic
HTML fetch and parse:
1. Nodes:
a. Start (S)
b. Fetch HTML (F)
c. Valid URL (VU)
d. Invalid URL (IU)
e. Valid Selector (VS)
f. Invalid Selector (IS)
g. Extract Data (ED)
h. No Data Extracted (NDE)
i. End (E)
2. Edges:
a. S -> F
b. F -> VU
c. F -> IU
d. VU -> VS
e. VU -> IS
f. VS -> ED
The Structure of the Graph Model:
Structure:
o Decision Points:
Fetch HTML: Decide whether the URL is valid or invalid.
Parse HTML: Decide whether the CSS selector is valid or invalid.
Extract Data: Decide whether the data can be extracted or not.
o Branches:
Valid URL branches into parsing with valid or invalid CSS selectors.
Invalid URL leads directly to termination.
Valid selector leads to data extraction.
Invalid selector leads to no data extraction.
o Dependencies:
Validity of the URL determines the next step.
Validity of the CSS selector determines whether data extraction proceeds or not.
The testing coverage criteria that will be selected will be Edge Coverage.
This is to ensure that at a minimum, each path is tested one, and the states
of each node can be tested. This will ensure proper a decision-making
process.
Based on this rationale, the following test cases were determined:
Test Case 1:
Path: S -> F -> VU -> VS -> ED -> E
Description: This test ensures that the specified attribute is present on the
elements when valid URL and valid CSS validator are used.
Test Case 2:
Path: S -> F -> VU -> VS -> NDE -> E
Description: This test examines whether the elements including the invalid
attribute would be devoid of the invalid attribute using a valid URL and valid CSS
selector but not wrong attribute.
Test Case 3:
Path: S -> F -> VU -> IS -> NDE -> E
Description: This test verifies that should a valid URL come with an invalid CSS
selector, no elements will be selected.
Test Case 4:
Path: S -> F -> IU -> E
Description: This test assures that an IOException is thrown when someone tries
to access a file that doesn’t exist using the Web.
Test Case 5:
Path: S -> F -> VU -> VS -> NDE -> E
Description: This test thwarts the selection of any element if a valid URL
contains no meaningful HTML content, even for a valid CSS selector.
Test Case 6:
Path: S -> F -> VU -> VS -> ED -> E
Description: This test confirms that numerous elements are properly identified
with a valid URL and CSS selector.
Test Case 7:
Path: S -> F -> VU -> VS -> NDE -> E
Description: This test checks whether a valid URL with a valid CSS selector that
does not match any elements results in no elements selected.
Test Case 8:
Path: S -> F -> VU -> VS -> ED -> E
Description: This examination ensures that a valid URL edge a dissolve HTML
organization is contritely analyzed so that elements lack absent attributes.
Summery
Test Case
URL
CSS Selector
Attribute
Name
1
https://en.wikipedia.org/
#mp-itn b a
title
2
https://en.wikipedia.org/
#mp-itn b a
invalid-attr
3
https://en.wikipedia.org/
#invalid-selector
href
4
http://invalid-url
–
title
5
Mocked document with .nonexistentclass
.nonexistent-class invalid-attr
6
https://en.wikipedia.org/
div
7
https://en.wikipedia.org/
.nonexistent-class invalid-attr
8
https://www.nytimes.com/
div
title
nonexistent-attr
The test cases are available in the attached file “GraphBasedTest.java”.
3. Overall Progress Summary:
The first step taken after forming our group was determining a common
language and testing framework. Due to the nature of the course work, the team
landed on utilizing a Java program and the JUnit Testing Framework. The open
source project for testing ended with JSoup as it is a common web scraping library
for Java. It is a fairly mature open source project with countless uses, and JSoup is
very easy to pick up and start using.
During the first week, there was an initial focus on expanding code coverage
where possible. Some of these were simple test additions to ensure that certain
functions get tested. This can be seen with two test functions at the bottom of the
‘ValidateTest.java’ test class. One new test case ensures that the test function
returns the object passed to it. The other test ensures that given a null object, the
function throws a ValidationException.
Some of the tests that were already completed were testing test DataUtil
helper class rather than testing the DataUtil helper indirectly through the JSoup
class. Time was taken to trace the function calls and update the test to use the
JSoup.parse() function instead of the DataUtil.parseInputStream() function. This
allows for more code coverage, while testing a function call that is more likely to be
used by developers utilizing the JSoup project.
Finally, some custom tests were built from basic use cases of JSoup. These
use cases focused on testing the error capabilities within the project. These errors
include cases where the URL provided is invalid, document element selectors are
invalid, or the HTML content is invalid. The input variables for these tests include:
String: URL – an Http or Https URL that is the location for the document
String: CSS Selector – The selector within a document identified by being
preceded with an ‘#’
String: Attribute Name – The attribute in the document to extract. Typically
follows the “=” within HTML tags.
Next, the two functions, HttpConnection.connect() and QueryParser.parse()
were identified for graph coverage testing. The HttpConnection.connect() function
is a fairly straight forward function. It primarily creates embedded objects within
itself for HTTP connections. The only major branching that occurs is when it checks
if the url provided is null or empty. In this case, it throws an Error before ending.
The second function, QueryParser.parse(), is much more interesting. It starts
by consuming the whitespace of the QueryParser objects tokenQueue. It then
checks if it matches any Combinator to determine if it needs to create a structure
root for the HTML tree. If not, then it adds the evaluators to the array of evaluators
in the object. It then loops through the token queue, removing whitespace and
checking for any additional combinators to remove. Next, it adds the HTML
elements to the objects array of elements. Finally, it checks if there is only one item
in the array, and if so, returns that element of the array. Otherwise, it combines the
array items into a new object and returns that object.
4. Attachments (if applicable):
Attached are many of the files used to derive the test cases and graph
model above:
Input_Based_Technique.java – Java class used for testing with JUnit.
contains the test cases used to test the input domain model.
It
Query Parser Graph – This is the initial draft of a graph model for the
QueryParser.parse() function
GraphBasedTest.java – Java class to testing with JUnit. It contains the test
cases used to test the graph model.
Graph Tool Results – These are results of utilizing the Graph Coverage Web
Application for the HttpConnection.connect() function
InputBasedTechnique.java
1 package org.jsoup;
2
3 import static org.junit.jupiter.api.Assertions.*;
4 import org.jsoup.*;
5 import org.jsoup.nodes.*;
6 import org.jsoup.select.*;
7 import org.junit.jupiter.api.Test;
8 import static org.mockito.Mockito.*;
9
10 public class Input_based_technique {
11
12
@Test
13
public void testValidURLValidSelectorValidAttr() throws Exception {
14
Document doc = Jsoup.connect(“https://en.wikipedia.org/”).get();
15
Elements elements = doc.select(“#mp-itn b a”);
16
for (Element el : elements) {
17
assertNotNull(el.attr(“title”));
18
19
}
}
20
21
@Test
22
public void testValidURLInvalidSelectorValidAttr() throws Exception {
23
Document doc = Jsoup.connect(“https://en.wikipedia.org/”).get();
24
Elements elements = doc.select(“#invalid-selector”);
25
assertTrue(elements.isEmpty());
26
}
27
28
@Test
29
public void testInvalidURL() {
30
Exception exception = assertThrows(Exception.class, () -> {
31
Jsoup.connect(“http://invalid-url”).get();
32
});
33
assertTrue(exception instanceof java.io.IOException);
34
}
35
36
@Test
37
public void testNoHTMLContentInvalidAttr() throws Exception {
38
// Mock the Document class to simulate HTML content
39
Document mockDoc = mock(Document.class);
40
41
// Define behavior for select
42
when(mockDoc.select(“.nonexistent-class”)).thenReturn(new Elements());
43
44
// Use the mock document instead of fetching from a URL
45
Elements elements = mockDoc.select(“.nonexistent-class”);
46
47
// Verify that the result is an empty list of elements
48
assertTrue(elements.isEmpty());
49
}
50
51
@Test
52
public void testComplexHTMLNonexistentAttr() throws Exception {
53
// Fetch the document from the given URL
54
Document doc = Jsoup.connect(“https://www.nytimes.com/”).get();
55
// Select all ‘div’ elements
56
Elements elements = doc.select(“div”);
57
// Check that each ‘div’ element does not have a ‘nonexistent-attr’ attribute
58
for (Element el : elements) {
59
// Verify that the ‘nonexistent-attr’ attribute is either absent or empty
60
assertTrue(el.attr(“nonexistent-attr”).isEmpty());
61
62
63
64 }
65
}
}
Query Parser Graph
QueryParser::Evaluator parse()
1
2
5
3
4
6
7
8
1
0
9
1
1
1
1
1
4
1
1 Evaluator parse() {
2
tq.consumeWhitespace(); // 1
3
4
if (tq.matchesAny(Combinators)) { // if starts with a combinator, use root as
elements // 2
5
evals.add(new StructuralEvaluator.Root()); // 3
6
combinator(tq.consume()); // 4
7
} else {
8
9
evals.add(consumeEvaluator()); // 5
}
10
11
while (!tq.isEmpty()) { // 6
12
// hierarchy and extras
13
boolean seenWhite = tq.consumeWhitespace(); // 7
14
15
if (tq.matchesAny(Combinators)) { // 8
16
17
combinator(tq.consume()); // 9
} else if (seenWhite) { // 10
18
19
combinator(‘ ‘); // 11
} else { // E.class, E#id, E[attr] etc. AND
20
evals.add(consumeEvaluator()); // take next el, #. etc off queue // 12
21
}
22
} // 13
23
24
25
if (evals.size() == 1) // 14
return evals.get(0); // 15
26
27
28 }
return new CombiningEvaluator.And(evals); // 16
QueryBasedTest.java
1 import org.jsoup.GraphBased.*;
2 import org.jsoup.*;
3 import org.jsoup.nodes.Document;
4 import org.jsoup.nodes.Element;
5 import org.jsoup.select.Elements;
6 import org.junit.Test;
7 import static org.junit.Assert.*;
8
9 /**
10 *
11 * @author admin
12 */
13 public class GraphBasedTest {
14
15
public GraphBasedTest() {
16
}
17
18
@org.junit.BeforeClass
19
public static void setUpClass() throws Exception {
20
}
21
22
@org.junit.AfterClass
23
public static void tearDownClass() throws Exception {
24
}
25
26
@org.junit.Before
27
public void setUp() throws Exception {
28
}
29
30
@org.junit.After
31
public void tearDown() throws Exception {
32
}
33
34
/**
35
* Test Case 1:
36
*
37
* Path: S -> F -> VU -> VS -> ED -> E Description: This test verifies that
38
* when a valid URL and valid CSS selector are used, the elements have the
39
* specified attribute.
40
*/
41
// Test Case 1: Valid URL with Valid Selector and Valid Attribute
42
// Path: S -> F -> VU -> VS -> ED -> E
43
@Test
44
public void testValidURLValidSelectorValidAttr() throws Exception {
45
// Fetch the document from a valid URL
46
Document doc = Jsoup.connect(“https://en.wikipedia.org/”).get();
47
// Select elements using a valid CSS selector
48
Elements elements = doc.select(“#mp-itn b a”);
49
// Check that each element has the “title” attribute
50
for (Element el : elements) {
51
assertNotNull(el.attr(“title”));
52
53
}
}
54
55
/**
56
*
57
* Test Case 2:
58
*
59
* Path: S -> F -> VU -> VS -> NDE -> E Description: This test checks that
60
* with a valid URL and valid CSS selector, but an invalid attribute, the
61
* elements do not have the invalid attribute.
62
*/
63
// Test Case 2: Valid URL with Valid Selector and Invalid Attribute
64
// Path: S -> F -> VU -> VS -> NDE -> E
65
@Test
66
public void testValidURLValidSelectorInvalidAttr() throws Exception {
67
// Fetch the document from a valid URL
68
Document doc = Jsoup.connect(“https://en.wikipedia.org/”).get();
69
// Select elements using a valid CSS selector
70
Elements elements = doc.select(“#mp-itn b a”);
71
// Check that each element does not have the “invalid-attr” attribute
72
for (Element el : elements) {
73
assertTrue(el.attr(“invalid-attr”).isEmpty());
74
75
}
}
76
77
/**
78
* Test Case 3:
79
*
80
* Path: S -> F -> VU -> IS -> NDE -> E Description: This test ensures that
81
* using a valid URL with an invalid CSS selector results in no elements
82
* being selected.
83
*/
84
// Test Case 3: Valid URL with Invalid Selector
85
// Path: S -> F -> VU -> IS -> NDE -> E
86
@Test
87
public void testValidURLInvalidSelector() throws Exception {
88
// Fetch the document from a valid URL
89
Document doc = Jsoup.connect(“https://en.wikipedia.org/”).get();
90
// Attempt to select elements using an invalid CSS selector
91
Elements elements = doc.select(“#invalid-selector”);
92
// Verify that no elements are selected
93
assertTrue(elements.isEmpty());
94
}
95
96
/**
97
* Test Case 4:
98
*
99
* Path: S -> F -> IU -> E Description: This test verifies that attempting
100
* to fetch a document from an invalid URL throws an IOException.
101
*/
102
// Test Case 4: Invalid URL
103
// Path: S -> F -> IU -> E
104
@Test
105
public void testInvalidURL() {
106
// Attempt to fetch the document from an invalid URL
107
Exception exception = assertThrows(Exception.class, () -> {
108
Jsoup.connect(“http://invalid-url”).get();
109
});
110
// Verify that an IOException is thrown
111
assertTrue(exception instanceof java.io.IOException);
112
113
}
114
/**
115
* Test Case 5:
116
*
117
* Path: S -> F -> VU -> VS -> NDE -> E Description: This test checks that a
118
* valid URL with no meaningful HTML content results in no elements being
119
* selected, even with a valid CSS selector.
120
*
121
* @throws Exception
122
*/
123
// Test Case 5: Valid URL with Valid Selector but No HTML Content
124
// Path: S -> F -> VU -> VS -> NDE -> E
125
@Test
126
public void testValidURLValidSelectorNoHTMLContent() throws Exception {
127
// Fetch the document from a valid URL with no meaningful HTML content
128
Document doc = Jsoup.connect(“https://example.com/no-html”).get();
129
// Attempt to select elements using a valid CSS selector
130
Elements elements = doc.select(“#mp-itn b a”);
131
// Verify that no elements are selected
132
assertTrue(elements.isEmpty());
133
}
134
135
// Test Case 6: Valid URL with Valid Selector that Matches Multiple Elements
136
// Path: S -> F -> VU -> VS -> ED -> E
137
@Test
138
public void testValidURLValidSelectorMultipleMatches() throws Exception {
139
// Fetch the document from a valid URL
140
Document doc = Jsoup.connect(“https://en.wikipedia.org/”).get();
141
// Select elements using a valid CSS selector that matches multiple
elements
142
Elements elements = doc.select(“div”);
143
// Check that multiple elements are selected
144
assertTrue(elements.size() > 1);
145
}
146
147
// Test Case 7: Valid URL with Valid Selector that Matches No Elements
148
// Path: S -> F -> VU -> VS -> NDE -> E
149
@Test
150
public void testValidURLValidSelectorNoMatches() throws Exception {
151
// Fetch the document from a valid URL
152
Document doc = Jsoup.connect(“https://en.wikipedia.org/”).get();
153
// Attempt to select elements using a valid CSS selector that matches no
elements
154
Elements elements = doc.select(“.nonexistent-class”);
155
// Verify that no elements are selected
156
assertTrue(elements.isEmpty());
157
}
158
159
// Test Case 8: Valid URL with Complex HTML Structure
160
// Path: S -> F -> VU -> VS -> ED -> E
161
@Test
162
public void testValidURLComplexHTMLStructure() throws Exception {
163
// Fetch the document from a valid URL with a complex HTML structure
164
Document doc = Jsoup.connect(“https://www.nytimes.com/”).get();
165
// Select all ‘div’ elements
166
Elements elements = doc.select(“div”);
167
// Check that each ‘div’ element does not have a ‘nonexistent-attr’
attribute
168
169
for (Element el : elements) {
// Verify that the ‘nonexistent-attr’ attribute is either absent or empty
170
assertTrue(el.attr(“nonexistent-attr”).isEmpty());
171
172
}
}
173 }
174
Graph Tool Resulsts (next page)
1st graph covers control graph flow not considering the params in Url(context(null),
spec, handler (null))
Graph Edges:
12
9 10
15 16
23
10 11
16 17
34
11 12
15 17
35
12 13
17 4
56
12 11
17 18
67
13 14
18 4
74
13 15
18 19
78
14 15
19 4
89
11 15
19 20
Initial Nodes: 1
Final Nodes: 4 20
Prime Paths:
2nd Graph
Updates:
Params: Context == null and URLStreamHandler
Because URLStreamHandler IS NULL no need to check for permission
Because context is NULL no need to handle context inheritance
New nodes:
12
79
13 4
23
9 10
13 14
34
10 9
14 4
35
10 11
14 15
56
11 12
15 16
67
11 13
16 4
78
12 13
4 17
89
9 13
Initial Nodes: 1
Final Nodes: 4 17
Prime Paths
Business District
Guidebook Tour (F1 Tour)
Idea: Use the product documentation as a guide through the application. Re-use HowTo’s
and tutorials. Try use cases/details described in educational documents (BC400/401, …).
After the tests the documentation should not contain any mistakes and all features should
work exactly as documented.
Money Tour
Idea: The money tour tests the features which were the main reasons that the customer
bought the software in the first place. Usually, these are the features which salespersons
show when they try to sell the product. Let a salesperson do a product demo for you in
order to find out what “money” features your application has.
Landmark Tour
Idea: Pick the most important features of your application and execute them in different
orders. The landmark tour is not meant to be just testing the main functionality. This can
and should be done by automated test. What an automated test cannot do is to put many
features into all possible sequence orders. The goal of the landmark tour is thereby to test
that the main features of an application work together in different orders.
Intellectual Tour
Idea: The intellectual tour is used to ask the software really hard questions. James Whittaker
gives some questions as guidance for the intellectual tour: “How do we make the software
work as hard as possible? Which features will stretch it to its limits? What inp uts and data
will cause it to perform the most processing? Which inputs might fool its error-checking
routines? Which inputs and internal data will stress its capability to produce any specific
output?”
Fedex Tour
Idea: The FedEx tour is used to identify and follow specific pieces of data through the
various part of the software which you are testing. The testers check that all parts properly
interact with the data.
After-Hours Tour
Idea: Most applications perform tasks even when the user is not interacting with them.
Backup jobs are running, data gets archived, clients might poll a backend server. The idea of
the after-hours tour is to check the application for such tasks and make sure that these
pieces of code which might not be directly connected to a feature are also getting tested.
Garbage Collector’s Tour
Idea: Garbage men go street by street, house by house. They stay only a few moments but
they crisscross the neighborhood in a methodical manner. For software testing, this means
to spot-check each and every capability/feature/module/… within a defined scope.
Tourist District
Collector’s Tour
Idea: Similar to a tourist traveling across the country collecting postcards from each
state/large city, the idea behind the collectors tour is that a tester tests a specific feature by
collecting all outputs possible. The focus of this tour is completeness.
Test one get one free (TOGOF) Tour
Idea: The TOGOF tour focuses on testing what happens if two or more instances of the
same application are running simultaneously. Start multiple instances, put them through
the paces by causing each application to manipulate the memory and the disk. Come up
with scenarios were two or more instances try to manipulate the same resource or let them
all do the same thing at once.
Lonely Businessman Tour
Idea: Businessman travel a lot. The focus of this tour is to “travel” as far through the
application as possible. Choose long paths over short paths. Which paths through the
application need the most clicks, require the most screens?
Supermodel Tour
Idea: The supermodel tour tests only the UI and not the logic behind it. The tester picks a
feature and makes sure it follows the UI guidelines, all icons are correct, no texts contain
spelling mistakes, etc. In order to make it easier to check whether features follow the UI
guidelines, it is a good idea to create short checklists together with the responsible UX
person.
Scottish Pub Tour
Idea: Large cities have a large amount of pubs. Some are busy all the time some or not. In
order to find the busy, popular ones you usually need a guide to tell you where to look.
Transfer this idea to software products. Large and complex products have a lot of features.
However, testers usually have a hard time finding the ones which are used a lot. The idea
behind the tour is that the testers actively try to find these features by talking with single
user, user groups in order to find features which might have already not been tested.
Historic District
Bad-Neighborhood Tour
Idea: All software products have parts which contain a lot of bugs. Of course, you do not know
which parts this will be in advance. However, after testing for some time you should be able to
compile a list with locations were these “bad neighborhoods” are located. Now, you can
specifically focus on those areas and run tours such as the garbage collector tour to make it bug
free, again.
Museum Tour
Idea: Large long-running projects usually have tons of legacy code. The idea behind the museum
tour is to have a look at these pieces of code. First find out which code has not been changed
for a long time by running the necessary reports then use those information to test the features
which execute this code. Even if your project only contains brand new code, make sure to check
whether it interacts with older code via APIs etc. and make sure the interaction does not lead to
bugs.
Prior Version Tour
Idea: Before a new product version gets released make sure that the all test cases for the old
version also are getting run for the new version. Verify that no functionality got lost in the new
version.
Entertainment District
Supporting Actor Tour
Idea: DO NOT exactly exercise the features which are in scope of the test case. Instead test the
nearest neighbor. For example if the test case tells you to use the log in language German use
English instead. If you should create a user with a German Address create one with an English
address. This variation makes sure that test cases which have successfully been executed for a
long time suddenly might find bugs again. It is a cheap way to introduce variations into old test
cases.
Back Alley Tour
Idea: The back alley tour is run for features which users hardly use during their daily work. This
does not mean that these features are not important, quite the contrary, for example hopefully
users never have to use features like data recovery. However, if they need them they have to
work properly. Other examples for rarely used features are preference dialogs or features which
only appear when the user starts the application for the first time.
All-Nighter Tour
Idea: A lot of bugs only happen if the software has been running for a long time, for example
such bugs could be memory leaks. The task of the All-nighter tour is to simulate this scenario. In
order to simulate long-running applications, etc it is often necessary to build some sort of test
infrastructure and get computers which are not turned off overnight.
Hotel District
Rained-Out Tour
Idea: In this tour you use the cancel button A LOT! Execute every kind of long-running job,
process and make sure that it is possible to cancel it. Examples for such scen arios are file
transfers, batch jobs, complicated searches, etc. Start such features and use the cancel
button or hit the Escape key.
Couch Potato Tour
Idea: Persons who are sitting on the coach, watching TV, eating potato chips are usually
called coach potatoes. The idea behind this tour is to pick a feature and try to test it with as
little work as possible. Some examples: test a user form and only enter the data which is
absolutely necessary, navigate the application by only using the mouse. One idea of this tour
is to ensure that the default cases are getting tested.
Seedy District
Saboteur Tour
Idea: Test the software in the most destructive way possible: undermine the application
when/however possible while focusing on the resources which the application needs,
remove/restrict resources (block file access, restrict available memory/disk space), change
environmental conditions (disconnect network connections,…). Focus only on needed
resources.
Antisocial Tour
Idea: Always do the opposite of what the others are doing. Use invalid inputs instead of valid
ones. Execute features in the wrong order. Always think about the opposites e.g. if valid input is
a number enter a character, if valid input is a picture file use a word file and so on. Testers
should expect to see the a lot of error messages when they perform this tour.
Obsessive Compulsive Tour
Idea: Repeat every step of a scenario twice or as often as you want. Especially steps which
manipulate data usually contain bugs which appear after lots of repetition. Same for error
messages. Error-handling code usually does not get as much attention from developers than
other code. If you provoked an error message try to replicate the same error again and again.
