You are on page 1of 15

Technical Review Walkthrough Review Inspection Review Informal Review

A Technical Review (also known as A walkthrough is a set of procedures An inspection is a formal type of An informal review is an extremely
a peer review), is considered to be a and techniques designed for a peer review. It requires preparation on popular choice early on in the
formal review type, even though no group, lead by the author to review the part the review team members development lifecycle of both
Managers are expected to attend. It software code. It is considered to be before the inspection meeting takes software and documentation. The
involves a structured encounter, in a fairly informal type of review. The place. A follow-up stage is also a review is commonly performed by
which a peer/s analyse the work walkthrough takes the form a requirement of the inspection. This peer or someone with relevant
with a view to improve the quality of meeting, normally between one and ensures that any re-working is experience, and should be informal
the original work. two hours in length. carried out correctly. and brief.

 Ideally led by the Moderator


 Led by the Author  Led by a Moderator  Low cost
 Attended by peers /
technical experts  Attended by a peer group  Attended by specified roles  No formal process
 Documentation is required  Varying level of formality  Metrics are included  No documentation required
 No Management presence  Knowledge gathering  Formal process  Widely used review
 Decision making  Defect finding  Entry and Exit Criteria
 Solving technical problems  Defect finding

V&V Validation Verification Waterfall Model

Software Validation and Verification Validation involves the actual Verification would normally involve
can involve analysis, reviewing, testing. This should take place after meetings and reviews and to The Waterfall model is also known
demonstrating or testing of all verification phase has been evaluate the documents, plans, as the ‘Sequential model’. Each
software developments. This will completed. requirements and specifications. stage follows on from the previous
include the development process This can be achieved by using one. The testing is performed in
and the development product itself. Validation: confirmation by reviews and meetings etc. ‘block’ as the last stage.
Verification and Validation is examination and provision of
normally carried out at the end of objective evidence that the Verification: confirmation by Planning or Test creation is not
the development lifecycle (after all particular requirements for a specific examination and provision of considered until the actual software
objective evidence that specified code has been written. This can
software developing is complete). intended use have been fulfilled.
result in problems being found much
But it can also be performed much requirements have been fulfilled.
later in the project lifecycle than is
earlier on in the development Validation: Are we building the right desirable.
lifecycle by simply using reviews. product? Verification: Are we building the
product right?
V - Model Spiral Model RAD DDSM

The Spiral model is an incremental RAD represents Rapid Application DSDM (Dynamic Systems
The V-Model is an industry standard testing approach to both Development, and is a software
framework that shows clearly the Development and Testing. This is development process that was Development Methodology) is
software development lifecycle in used most effectively when the developed in the mid 1980’s. It was basically a high level framework of
relation to testing. It also highlights users do not know all of the developed to overcome the rigidity already proven RAD techniques, and
the fact that the testing is just as requirements. From what is known, of such processes as ‘The Waterfall also management controls that are
initial requirements can be defined. Model’. used to increase the chances of
important as the software
Then from these the code and test
development itself. The relationships successful RAD projects.
cases are created. As time goes on, Elements:
between development and testing more details of the requirements are The high level framework allows for
are clearly defined. known and implemented in further  Prototyping a process that can be easily
iterations of design, coding and  Iterative Development modified for individual project’s
The V-Model improves the presence testing phases. The system is  Time-boxing specific needs. But, this quite simple
of the testing activities to display a considered to be complete, when  Team Members framework also results in poor
more balanced approach. enough of the iterations have taken  Management Approach
place. implementation due to lack of detail.
 RAD Tools

Component Integration Requirements Based


Process Interfaces Component Testing Testing Functional Testing

This type of Integration testing is Requirements-based Testing is


As a Tester, your focus will be fixed Component testing is also known as
concerned with ensuring the simply testing the functionality of the
on the test process. But we must Unit, Module, or Program Testing. In interactions between the software software/system based on the
consider other processes that exist, simple terms, this type of testing components at the module level requirements. The tests themselves
and also their interaction with the focuses simply on testing of the behave as expected. Component should be derived from the
test process. individual components themselves. Integration Testing is also often documented requirements and not
referred to as ‘Integration Testing in based on the software code itself.
the Small’. This method of functional testing
 Project Management It is common for component testing
 Change Management ensures that the users will be getting
to be carried out by the Developer of It is commonly performed after any
 Configuration Management what they want, as the requirements
the software. This however has a Component Testing has completed, document basically specifies what
 Software Development and the behaviour tested may cover
very low rating of testing the user has asked for.
 Technical Writing both functional and non-functional
independence.
 Technical Support aspects of the integrated system.
Business Process
Load Testing Performance Testing Stress Testing
Functional Testing

Testing the ability of the system to A program/system may have Stress Testing simply means putting
Different types of users may use the be able to bear loads. An example requirements to meet certain levels
developed software in different the system under stress. The testing
would be testing that a system could of performance. For a program, this is not normally carried out over a
ways. These ways are analysed and process a specified amount of could be the speed of which it can
business scenarios are then long period, as this would effectively
transactions within a specified time process a given task. For a be a form of duration testing.
created. User profiles are often used period. So you are effectively networking device, it could mean the
in Business Process Functional Imagine a system was designed to
loading the system up to a high throughput of network traffic rate. process a maximum of 1000
Testing. Remember that all of the level, then ensuring it can still Often, Performance Testing is
functionality should be tested for, transactions in an hour. A stress test
function correctly whilst under this designed to be negative, i.e. prove would be seeing if the systems could
not just the most commonly used heavy load. that the system does not meet its
areas. actually cope with that many
required level of performance. transactions in a given time period. A
useful test in this case would be to
see how the system copes when
asked to process more than 1000.

Security Testing Useability Testing Storage Testing Volume Testing

A major requirement in today’s This is where consideration is taken This type of testing may focus on Volume Testing is a form of Systems
software/systems is security, into account of how the user will use the actual memory used by a Testing. It primary focus is to
particularly with the internet the product. It is common for program or system under certain concentrate on testing the systems
revolution. Security testing is considerable resources to be spent conditions. Also disk space used by while subjected to heavy volumes of
focused at finding loopholes in the on defining exactly what the the program/system could also be a data. Testing should be approached
programs security checks. A customer requires and simple it is to factor. These factors may actually from a negative point of view to
common approach is to create test use the program to achieve there come from a requirement, and show that the program/system
cases based on known problems aims. For example; test cases could should be approached from a cannot operate correctly when using
from a similar program, and test be created based on the Graphical negative testing point of view. the volume of data specified in the
these against the program under User Interface, to see how easy it requirements.
test. would be to use in relation to a
typical customer scenario.
System Integration
Installability Testing Documentation Testing Recovery Testing
Testing

Documentation in today’s Recovery Testing is normally carried This type of Integration Testing is
A complicated program may also environment can take several forms, out by using test cases based on
have a complicated installation concerned with ensuring the
as the documentation could be a specific requirements. A system may interactions between systems
process. Consideration should be printed document, an integral help be designed to fail under a given
made as to whether the program will behave as expected. It is commonly
file or even a web page. Depending scenario, for example if attacked by performed after any Systems Testing
be installed by a customer or an of the documentation media type, a malicious user; the
installation engineer. Customer has completed. Typically not all
some example areas to focus on program/system may have been systems referenced in the testing are
installations commonly use some could be, spelling, usability, designed to shut down. Recovery
kind of automated installation controlled by the developing
technical accuracy etc. testing should focus on how the organization. Some systems maybe
program. This would obviously have system handles the failure and how
to under go significant testing in controlled by other organizations, but
it handles the recovery process. interface directly with the system
itself, as an incorrect installation
procedure could render the target under test.
machine/system useless.

Contract & Regulation Operational Acceptance


UAT Alpha Testing
Acceptance Testing Testing

User Acceptance Testing or ‘UAT’ is


commonly the last testing performed This type of Acceptance Testing is This form of acceptance testing is Alpha Testing should be performed
on the software product before its aimed at ensuring the acceptance commonly performed by a System at the developer’s site, and
actual release. It is common for the criteria within the original contract Administrator and would normally be predominantly performed by internal
customer to perform this type of have indeed been met by the concerned with ensuring that testers only. Often, other company
testing, or at least be partially developed software. Normally any functionality such as; department personnel can act as
involved. Often, the testing acceptance criteria is defined when backup/restore, maintenance, and testers. The marketing or sales
environment used to perform User the contract is agreed. Regulation security functionality is present and departments are often chosen for
Acceptance Testing is based on a Acceptance Testing is performed behaves as expected. this purpose.
model of the customer’s when there exists specific
environment. This is done to try and regulations that must be adhered to,
simulate as closely as possible the for example, there may be safety
way in which the software product regulations, or legal regulations.
will actually be used by the
customer.
Test Plan
Beta Testing Re-Test Regression Testing
Document

It is imperative that when a fault is When checking a fixed fault, you A Test Plan should be a single
Beta Testing is commonly performed fixed it is re-tested to ensure the can also consider checking that
at the customer’s site, and normally document that basically contains
fault has indeed been correctly other existing functionality has not what is going to be tested, why it is
carried out by the customers fixed. been adversely affected by the fix.
themselves. Potential customers are going to be tested, and how it is
This is called Regression Testing. going to be tested. It is also
often eager to trial a new product or
new software version. This allows important to clarify what is not going
Re-test: Regression Test: to be tested in the software product
the customer to see any “Whenever a fault is detected and “Regression testing attempts to
improvements at first hand and too. With regards to using a standard
fixed then the software should be verify that modifications have not Test Plan layout, then we can look to
ascertain whether or not it satisfies re-tested to ensure that the original caused unintended adverse side
their requirements. On the flip side, the advice given by the
fault has been successfully effects in the unchanged software IEEE(Institute of Electrical and
it gives invaluable feedback to the removed.” (regression faults) and that the
developer, often at little or no cost. Electronic Engineers) located in the
modified system still meets its International Standard IEEE Std
requirements.” 929-1998.

Generic Test Test Strategy Project Plan


Process Test Policy

A standard test process that is This should apply to both new Based on the test policy, the test Exactly how the test strategy for a
commonly used exists within the projects and maintenance work. strategy is designed to give an particular project will be
BS7925-2 Standard for Software overview of the test requirements for
Normally fairly short in length, the implemented is displayed in the
Component Testing:
test policy should be a high-level a programme or even organization. project plan. The project test plan will
document, and should contain the normally be referenced from the
 Test Planning following items: Information relating to risks should overall project plan. In relation to the
 Test Specification be documented here, specifically test strategy, the project plan should
 Test Execution  Definition of testing the risks that will be addressed by detail items from the test strategy
 Test Checking & Recording  The testing process the testing, and the specific tests that it is complying with, and also
 Checking for Test that will be used against each risk.
 Evaluation of testing items it is not complying with.
Completion
 Quality levels
 Improvement approach
Phase Test Plan Risk Management Risk Identification Risk Analysis

The following techniques can all be


The specific details of the approach Risk management comprises of the used to identify risks associated with So what does the term ‘Risk
taken by the testing for a specific following three components: products and projects. The list is by Analysis’ actually mean? It is simply
test phase is shown in this no means rigid, as many ‘studying the identified risks’. A
document. It can be thought of as  Risk Identification organisations will have there own simple formula can be used to
 Risk Analysis techniques. calculate risk:
being based on the project plan, but
 Risk Mitigation
with greater amounts of detail  Expert Interviews
included, such as testing activities Frequency (likelihood) X Severity
Risk management should be a  Independent Assessment
based on day to day plan, or consideration for everyone involved  Risk Templates (impact)
expected amounts of man hours to in the project.  Lessons Learned
complete individual tasks.  Risk Workshops By using the above formula we can
 Brainstorming and produce a figure, otherwise known
Checklists as the ‘exposure’.

Equivalence Boundary Value Classification Tree


Risk Mitigation Analysis Method
Partitioning

Risk mitigation is simply the


What this method allows you to do By the use of equivalence The classification tree method is also
response to the analysed risks. A
is effectively partition the possible partitioning, a tester can perform known as a decision tree method
choice must be made as what action effective testing without testing
program inputs. For each of the and the terms can be used
should be carried out once a risk above input fields, it should not every possible value. This method interchangeably as they mean the
has been identified. Some possible matter which values are entered as can be enhanced further by another same thing. A decision tree can be
choices could be: long as they are within the correct method called ‘Boundary Value learned by splitting the source set
range and of the correct type. Analysis’. After time, an experienced into subsets based on an attribute
Tester will be often realise that value test. This process is repeated
 Do nothing problems can occur at the
So the point of equivalence on each subset in a recursively. The
 Take preventative action portioning is to reduce the amount boundaries of the input and output recursion is completed when splitting
(test it) of testing by choosing a small spaces. When testing only a small is either not possible, or a single
 Contingency plan (what we selection of the possible values to amount of possible values, the classification can be applied to each
be tested, as the program will minimum and maximum possible element of the subset.
should do if the predicted
handle them in the same way. values should be amongst the first
fault actually occurs) items to be tested.
State Transition Branch Decision Branch Condition
Statement Testing
Testing Testing Testing

This testing method involves using This test method uses a model of
This type of Black-box testing is a model of the source code which the source code which identifies Branch Condition Testing uses a
based on the concept of ‘states’ and identifies statements. These individual decisions, and their model of the source code, and
‘finite-states’, and is based on the statements are the categorized as outcomes. A ‘decision’ is defined as identifies decisions based on
tester being able to view the being either ‘executable’ or ‘non- being an executable statement individual Boolean operands within
software’s states, transition between executable’. In order to use this containing its own logic.
states, and what will trigger a state each decision condition. A ‘decision’
method, the input to each
change. Test cases can then be is defined as being an executable
component must be identified. Also, This logic may also have the
designed to execute the state each test case must be able to capability to transfer control to statement containing its own logic.
changes. identify each individual statement. another statement. Each test case is
Lastly, the expected outcome of designed to exercise the decision An example of a decision would be a
each test case must be clearly outcomes. In order to use this ‘loop’ in a program.
defined method, the input to each
component must be identified.

Branch Condition Requirements Based Useability Testing Volume Testing


Combination Testing Functional Testing

Branch Condition Combination


Requirements-based Testing is This is where consideration is taken Volume Testing is a form of Systems
Testing uses a model of the source
simply testing the functionality of the into account of how the user will use Testing. It primary focus is to
code, and identifies decisions based the product. It is common for
software/system based on the concentrate on testing the systems
on combinations of Boolean requirements. The tests themselves considerable resources to be spent while subjected to heavy volumes of
operands within decision conditions. should be derived from the on defining exactly what the data. Testing should be approached
This logic may also have the documented requirements and not customer requires and how simple it from a negative point of view to
based on the software code itself. is to use the program to achieve show that the program/system
capability to transfer control to
This method of functional testing there aims. For example; test cases cannot operate correctly when using
another statement. The decision could be created based on the
ensures that the users will be the volume of data specified in the
condition is a Boolean expression getting what they want, as the Graphical User Interface, to see requirements.
which is evaluated to determine the requirements document basically how easy it would be to use in
outcome of the decision. specifies what the user has asked relation to a typical customer
for. scenario.
Performance Testing Stress Testing Dynamic Analysis Static Analysis

Stress Testing simply means putting Dynamic analysis is a testing Static Analysis is a set of methods
A program/system may have the system under stress. The testing method that can provide information
requirements to meet certain levels designed to analyse software code
is not normally carried out over a on the state of software. It can in an effort to establish it is correct,
of performance. For a program, this long period, as this would effectively achieve this dynamically i.e. it
could be the speed of which it can prior to actually running the software.
be a form of duration testing. provides information when the As we already know, the earlier we
process a given task. For a Imagine a system was designed to software is actually running. It is
networking device, it could mean the find a fault the cheaper it is to fix. So
process a maximum of 1000 commonly used to exercise parts of by using Static Analysis, we can
throughput of network traffic rate. transactions in an hour. A stress test the program that use memory
Often, Performance Testing is effectively test the program even
would be seeing if the systems resources e.g.: before it has been written. This
designed to be negative, i.e. prove could actually cope with that many
that the system does not meet its would obviously only find a limited
transactions in a given time period.  Memory allocation number of problems, but at least it is
required level of performance. A useful test in this case would be to  Memory usage something that can be done very
see how the system copes when  Memory de-allocation early on in the development lifecycle.
asked to process more than 1000.  Memory leaks
 Unassigned pointers

Control Flow Lines of Code Data Flow Analysis


Graphing Cyclomatic Complexity

Control flow graphs display the logic Cyclomatic Complexity is a software The most basic form of a complexity The idea behind Data-flow Analysis
structure of software. The flow of metric that is used to measure the metric is the ‘Lines of Code’ metric, is to work-out the dependencies
logic through the program is complexity of a software program. or ‘LOC’ metric. Its purpose like between items of data that are used
charted. It is normally used only by Once we know now how complex other complexity metrics is to by a program. When a program is
Developers as it is a very low level the program is, we then know how estimate the amount of effort that ran, it rarely runs in a sequential
form testing, often used in easy it will be to test. will be required not only to develop order i.e. starting at line 1 and
Component Testing. such a program, but also assist in finishing at line 100. What usually
C=E–N+P estimating how much effort will be happens is that the dependencies of
It can be used to determine the required to test it. the data within the program will
number of test cases required to determine the order. Data-flow
 C = Cyclomatic Complexity
test the programs logic. It can also Analysis can be used to find
 E = number of edges In its simplest form we could use the
provide confidence that the detail of ‘definitions’ that have no intervening
 N = number of nodes LOC metric by literally counting the ‘use’. Data-flow analysis is also used
the logic in the code has been  P = number of components number of lines of code in the
checked. to detect variables that are ‘used’
program. after it has effectively been ‘killed’.
Error Guessing Exploratory Testing Ad-hoc Testing Random Testing

This type of testing is normally This type of testing is considered to A Tester normally selects test input
Why can one Tester find more errors governed by time. It consists of be the most informal, and by many it
than another Tester in the same data from what is termed an ‘input
using tests based on a test chapter is considered to be the least domain’. Random Testing is simply
piece of software? More often than that contains test objectives. It is effective. Ad-hoc testing is simply
not this is down to a technique when the Tester selects data from
most effective when there are little making up the tests as you go the input domain ‘randomly’. As you
called ‘Error Guessing’. To be or no specifications available. It along. Often, it is used when there is
successful at Error Guessing, a can tell, there is little structure
should only really be used to assist only a very small amount of time to involved in ‘Random Testing’. In
certain level of knowledge and with, or compliment a more formal test something. A common mistake
experience is required. A Tester can order to avoid dealing with the above
approach. It can basically ensure to make with Ad-hoc testing is not questions, a more structured Black-
then make an educated guess at that major functionality is working as documenting the tests performed
where potential problems may arise. box Test Design could be
expected without fully testing it. and the test results. Even if this implemented instead. However,
This could be based on the Testers information is included, more often
experience with a previous iteration using a random approach could save
than not additional information is not valuable time and resources if used
of the software, or just a level of logged such as, software versions,
knowledge in that area of in the right circumstances.
dates, test environment details etc.
technology.

Quality Assurance Industry Specific Testing Standards Review Definition


Standards Standards

Review: A process or meeting during


A Quality Assurance (QA) standard An industry specific standard will Testing standards will detail how to which a work product, or set of work
simply specifies that testing should detail exactly what level of testing is perform the testing. Ideally, a products, is presented to project
be performed. to be performed. testing standard should be personnel, managers, users or other
referenced from a QA or Industry interested parties for comment or
Example: ISO 9000 Examples: specific standard. approval. [IEEE]

A review should be performed when


 Railway Signalling standard
Example: BS7925-1, BS7925-2 all of the supporting documentation
 DO-178B
is available. This can include design
 Nuclear Industry standard documents, requirements
 MISRA guidelines for motor documents, standards documents,
vehicle software basically any documentation that has
 Pharmaceutical standards either been influential or is
applicable to the document to be
reviewed.
Review Process
Review Roles Incident Management IEEE Std. 1044-1993
Structure

An example of a typical review We term an incident; any significant, This standard aims to provide a
Organisations will commonly have process is below. This is probably unplanned event that occurs during
different named roles than those standard approach to classification
the most documented review testing that requires subsequent of anomalies found in software. It
listed below, but this will give you an process you will find in the software investigation and/or correction. The
idea of a commonly used set of includes descriptions of the
development world, and is open to incident should be raised when the processes involved in a software life
roles used throughout the world. interpretation: actual result differs from the cycle, including details on how
expected result. After the inevitable anomalies should be recorded and
 Manager  Planning investigation of the incident, there
 Moderator subsequently processed. It consists
 Kick-off may be a reason other than a of four sequential steps;
 Author  Preparation software fault, for example: Recognition, Investigation, Action,
 Reviewer Meeting
 Disposition. Each of those steps has
 Scribe  Rework  Test environment incorrectly three administrative activities which
 Follow-up set up are; Recording, Classifying,
 Exit Criteria  Incorrect Test Data used Identifying Impact.
 Incorrect Test Specification

Maturity Model SEI Capability Maturity CMM Maturity Levels CMM Capability Levels
Definition Model (CMMI)

A maturity model is basically a The CMM defines five maturity


The Capability Maturity Model, levels which form the top-level The software process capability
collection of elements that are structure of the CMM itself. Each defines what can be achieved by
structured in such a way that they simply put, is a baseline of practices level is basically a foundation that undertaking a specific software
can describe characteristics of that should be implemented in order can be built upon to improve the process. It achieves this by
processes and their effectiveness. A to develop or maintain a product. process in sequence. Starting with describing the range of expected
maturity model can provide: The product can be completely basic management practices and results. There are six capability
software, or just partially software. progressing through successive levels.
proven levels.
 A starting point The SW-CMM focuses on the
 Incomplete
 A shared vision software practices whereas with the Initial
  Performed
 A structure for organising CMMI, you may find both software  Managed  Managed
actions and systems practices.  Defined  Defined
 Use of previous experience  Quantitatively Managed  Quantitatively Managed
 value of improvements  Optimising  Optimising
ISO/IEC 15504 (SPICE)
TMM Definition TMM Maturity Levels TPI Definition
Definition

Developed by Koomen and Pol in


The Illinois Institute of Technology The maturity levels are basically 1997, the Test Process Improvement
The ISO/IEC 15504 is also known (IIT) developed the Testing Maturity defined levels of maturity that can
as SPICE. Spice stands for Model or ‘TPI’ was created with the
Model (TMM) in 1996. The main be achieved by showing that goal of simplifying the sometimes
Software Process Improvement and reason for developing the TMM was specific practices have been carried
Capability dEtermination. It is over-complicated testing process.
that existing maturity models didn’t out. The TMM has five different The TPI model itself identifies the
essentially a framework for properly address real testing issues. achievable levels:
assessing software processes. good and bad parts of a testing
It was designed to complement the process. The maturity of the process
Rather than concerning itself with existing CMM. The main purpose of  Initial can also be assessed by using the
specific standards, ISO/ISEC 15504 the TMM is to support assessment  Phase Definition TPI. The TPI consists of the
concerns itself with is the and improvement drives within an
capabilities provided by an  Integration following four components:
organisation. The model comprises
organisations structure. These of a Maturity Model and an
 Management/Measurement
structures include its management  Optimisation/defect  A Maturity Model
Assessment Model.  A Test Maturity Matrix
structure and its process definition Prevention and Quality
structure. Control  A Checklist
 Improvement Suggestions

TPI Requirements Static Analysis


TPI Model Testing Tools Tools
Test Maturity Matrix

The TPI model consists of three The TPI takes into account the
maturity levels and fourteen scales. This type of tool is designed to By examining the code instead of
different aspects of a test process,
The individual levels contain several assist with verification and validation running test cases through the code,
including design techniques, test of requirements, for example; this type of tool can provide
different scales. The scales
themselves provide indication of tool usage and reporting. Structured consistency checking. information on the actual quality of
which key areas require evaluation of various key areas, the software. Cyclomatic complexity
improvement. highlights the test processes is one such characteristic that can
be obtained by using this type of
strengths and weaknesses. The
 Scales 1 to 5 focus on bring tool.
state of a key area is determined by
the testing process under
control assigning a level to it, commonly A
 Scales 6 to 10 focus on to B to C etc. The levels are
establishing test process increased based on time, cost and
efficiency quality.
 Scales 11 to 14 focus on
test process optimisation
Test Input Data
Test Design Tools Test Running Tools Test Harnesses
Preparation Tool

This type of tool can generate test Data can be selected from existing These are an extremely popular
test specific databases by using this type of tool. They provide capture If the software under test does not
cases from specifications, which are have a user interface, then test
normally stored in a CASE tool type of tool. Advanced types of this and replay facilities for WIMP
tool can utilise a range of database interface based applications. The harnesses and drivers can be used
repository. Some variations of this
type of tool can also generate test and file formats. tools can simulate mouse to execute the software. These types
cases from analysing the code itself. movement, mouse clicks and of tools can be bought off the shelf,
keyboard inputs. The tools can even
but more commonly they are built for
recognize windows and buttons,
thus making them extremely a specific purpose.
versatile. The test procedures are
normally written in a specific
scripting language. This tool is
another popular choice for
regression testing.

Performance Test Dynamic Analysis


Test Script Generators Debugging Tools
Tools Tools

Creates actual test scripts based on This type of tool comprises of two Run-time information on the state of Debugging tools are often used by
information held within a test components; Load Generation and the executing software is achieved programmers to try and reproduce
specification. Simulators are by using Dynamic Analysis Tools. code related errors in order to
Test Transaction Measurement.,
commonly used where it is investigate a problem. The debugger
Load Generation is commonly These tools are ideally suited for
impracticable to use them, for
performed by running the monitoring the use and allocation of allows the program to be run line by
example software to control a space
probes trajectory. application using its interface or by memory. Faults such as memory line. This enables halted the program
using drivers. The number of leaks, unassigned pointers can be on demand to examine and set
transactions performed this way are found, which would otherwise be program variables.
then logged. Performance test tools difficult to find manually.
will commonly be able to display
reports and graphs of load against
response time.
Test Management Coverage Measurement Hyperlink Testing
Comparison Tools
Tools Tools Tools

This type of tool is used to highlight Test Management Tools commonly This type of tool provides objective
differences between actual results have multiple features. Test measures of structural test coverage These tools are simply used to
and expected results. Off the shelf Management is mainly concerned when the actual tests are executed. check that no broken hyperlinks exist
Comparison Tools can normally deal on a web site.
with the management, creation and Before the programs are compiled,
with a range of file and database
control of test documentation. More they are first instrumented. Once
formats. This type of tool often has
filter capabilities to allow ‘ignoring’ of advanced tools have additional this has been completed they can
rows or columns of data or even capabilities such as test then be tested. The instrumentation
areas on a screen management features, for example; process allows the coverage data to
result logging and test scheduling. be logged whilst the program is
running. Once testing is complete,
the logs can provide statistics on the
details of the tests covered.

Security Testing Tool Selection


Monitoring Tools Test Oracles
Tools Process

These tools are typically used for These tools are commonly used for A Test Oracle is used to A suggested tool selection and
testing e-commerce and e-business testing e-commerce and e-business automatically generate expected evaluation process is:
applications. The main purpose of applications, and sometimes web results. They are commonly used in
this tool is to check web sites to sites. A security testing tool will situations where an old system is  Determine the actual problem or
ensure that they are available to check for any parts of a web based upgraded with a new system with requirement
customers and also to produce system that could cause potential the same functionality, so the old  Ensure that there are no obvious
warnings if problems are detected. security risks if attacked. system can be used as an Oracle. alternative solutions
 Prepare a business case
 Identify any constraints
 Identify any specific required tool
features or characteristics
 Prepare a short-list of possible
suitable tools
 Perform a detailed evaluation
 Perform a competitive trial, if
needed
Test Tool
Pilot Projects User Skill’s Developer Skill’s
Implementation Team

The last thing we want is to


introduce a tool into the An implementation team can be A ‘User’ is someone who has had A developer’s background may have
organisation, only to find a few formed to evaluate a new tool experience actually using the provided them with experience with
weeks down the line it fails resulting consisting of: software under test, or similar types code, design or requirements
in potentially disastrous scenarios. of software. This knowledge can be analysis. This knowledge can be
In order to avoid this situation, we  A Champion useful to determine the type of faults extremely useful, as the developer
can implement a pilot project. The  A Change Agent that a typical user may come would probably have some idea
benefits of using a pilot project are;  A Tool Custodian across, which to most developments when looking at the software of how
would also have the most impact. it was developed, and so would
 Gaining experience using The ‘User’ would probably not have probably know where to look for
the tool sufficient knowledge to test the weaknesses.
 Identify any test process software to extreme depths though.
changes
 Identify any shortcomings
suitability of the tool

Belbin’s Action Belbin’s People Belbin’s Thought


Tester Skill’s Oriented Roles Oriented Roles
Oriented Roles

Previous knowledge of testing has Shapers: Challenging, dynamic, Coordinator: Mature, confident, a Plant: Creative, imaginative,
its obvious advantages. They should thrives on pressure. The drive and good chairperson. Clarifies goals, unorthodox. Solves difficult
be able to analyse a specification, courage to overcome obstacles. promotes decision-making, problems. Ignores incidentals. Too
design test cases, execute test Prone to provocation. Offends delegates well. Can often be seen pre-occupied to communicate
cases, and produce results and people's feelings as manipulative. effectively.
reports. An individual with previous Implementer: Disciplined, reliable, Team Worker: Co-operative, mild, Monitor – Evaluator: Sober,
testing experience would also have conservative and efficient. perceptive and diplomatic. Listens, strategic and discerning. Sees all
the right mindset for testing, as they Somewhat inflexible. Slow to builds, averts friction. Indecisive in options. Judges accurately. Lacks
would already know the reasoning respond to new possibilities crunch situations. drive and ability to inspire others.
behind why testing is performed. Completer – Finisher: Painstaking, Resource Investigator: Extrovert, Specialist: Single-minded, self-
conscientious, anxious. Searches enthusiastic, communicative. starting, dedicated. Provides
out errors and omissions. Delivers Explores opportunities. Develops knowledge and skills in rare supply.
on time. Inclined to worry unduly. contacts. Over - optimistic. Loses Contributes only on a narrow front.
Reluctant to delegate. interest after short period. Dwells on technicalities.
The Test Leader The Tester The Client The Project Manager

The Test Leader will commonly


come from a testing background The Tester obviously provides the The client is effectively the project Management skills are provided by
and have a full understanding of skills necessary to perform the sponsor, and will provide the budget the Project Manager. The Project
how testing is performed. They will Testing itself. This role can include for the project. The Client can also Manager will be actively involved
also possess good managerial test design and test execution. be the business owner. throughout the project and will
expertise. They are also responsible Automated testing skills are also a provide feedback to the client.
for ensuring that test coverage is possible requirement of this role.
sufficient and will be required to
produce reports.  Preparation of test data
 Execute tests
 Review other peoples tests
 Review Test Plan
 Involvement in automation
of tests
 Create Test Specifications

The Developer The Business Analyst The Systems Analyst The Technical Designer

A Developer will provide the skills to The Business Analyst will provide Systems design will be provided by Technical detail and support to the
write the actual software code and knowledge of the business and the Systems Analyst. The Systems system design is the responsibility of
perform Unit Testing. They may also analysis skills. The Business Analyst Analyst will also be responsible for the Technical Designer. This role
be called upon at a later stage to will also be responsible for creating developing the Functional may include database
provide bug fixes and technical User Requirements based on talks Specification from the User administration.
advice. with the Users. Requirements.