Software Testing - Best Practice

Testing Checklist
The Testing Lifecycle
Plan Data Plan:
l Define scope of testing
A test plan should define the optimum process of validating that the software is fit for purpose and Data drives testing. Think about the following when defining data needs and your approach. Poor l Understand Business Objectives
meets the requirements. To help meet these objectives consider the following…… data will result in poor testing, wasted time and lower quality. l Define success criteria
l Assess resource requirements
Project Test Cases Design Data Needs Analyse current data - what is in use now?
Business objectives Data - background and scenario Scenarios - common ground Coverage - getting a good mix
l Agree timescales
Timescales - is this a constraint? Positive and negative cases - error handling Common scenarios and rare values
Market forces - competition and time to market? Scenarios - testing each requirement Data Sources Consistency - especially is subset, must be intact
Benefits - what will the business gain Process steps - depending on time & tester knowledge Existing production data? Positive and negative - separate good & invalid cases
User needs - the real user requirement
Resources
Detailed instructions?
User flexibility?
Conversion from prior system
Extraction of subset from production
Interface simulation - especially inbound interfaces
Data confidentiality and sensitivity - obscure or 'scramble'
Prepare:
Scope Expectation - the correct results Generation - enter from scratch sensitive ex-live data l Input data
Verification items - how to confirm the correct result Pair-wise/all pairs - testing combinations sensitive ex-live data l Processes
Functional Requirements Visible
Use cases - how will the software be used System - eg database Data Management
l Expectations
Features - an excellent building block for a test case Automation - can & should this be automated? Environments
Specifications Risk - how important is this test Back up strategy
Performance - in realistic business terms Checkpoint and roll-back approach
Apply to Business rule checking
Non Functional Requirements Unit testing Matching to scenarios
Usability
Environment - can you build the same in test?
System Testing
User Acceptance testing
Security
Sharing - across teams, inside the team
Define:
Data - underlying, source of, input l Environment
Correctly deployed software test automation solutions Compatibility - other systems and interfaces.
can empower all players in the development process by Designed with testing in mind
Hints. Data is an asset. Where possible develop an approach for l Test Data (data extraction)
intuitively providing the information they need. The Risk - which are key system functions Data Protection that enables data to be kept and reused, matching l Applications
background and input data with scenario results - this will save
benefits to development time scales, user confidence considerable time and effort.
and ongoing maintenance will be immense. Hints. Engage as early as possible in the requirements and Watch out for legislative factors - confidentially, security,
design process to capture key elements of test scenarios at improper use.
the source. Look beyond the obvious, include all outputs not
just the user-visible.
Perform Tests:
l Unit Testing
l QA Testing
l Load Testing
l User Acceptance Testing
The Quality Conundrum l Regression Testing

Check/Verify Results:
l Database
Report Execute l Visual Layer
l Reports
l Performance
Data from testing is the raw material for improvement. Get as Good testing is about knowing two things - what you are
much detail as possible in issue diagnosis, stand back from trying to achieve and what actions you actually performed.
the numbers to find ways to improve your processes. It is important to capture all the possible data to enable
development teams to understand and reproduce errors easily,
Diagnostics - more the better to aid reproduction
Screen capture The Team
saving everyone's time. Revise & Improve:
Process Set targets
Input Measure and report
l Build Knowledge
Results - for issue diagnosis package and audit l Increase Coverage
Data Make it fun and interesting
Visible
Deviance from requirement Share knowledge, share success
Database l Feedback to Developers
Database effects Share the problems
Interfaces
Environment
Performance
Management informed
Compliance - keep proof and evidence Agree 3-5 key facts
Steps: Regression - re-use passed tests?
Steps Report the key facts at least one a week
Actions and expectations - proving the requirement Add to regression pack
Pass and fail With any problem, present a solution
User/tester
Pass/Fail - track as progressing Automation - keep it simple, minimise maintenance
Data pack - build and keep this in parallel
Report:
Environment - under what conditions
Traceability - who, what, when
Verification - where to look for the answer Sequence and dependencies l Error – Diagnostics
User interface
Resources, risk and application time-to market are often Format of storage - method and access
Component structure Issues
l Management & Auditing
in conflict as IS team strive to deliver quality applications Tiers Track issues detected l Metrics
Metrics
with their budgetary constraints. This is the quality Test counts
Database Causes - categories for analysis l Compliance
conundrum. Interfaces Types of issue
Issue counts
Logs Severity - impact on testing and on the system
Defect counts
Affected objects
Rework
Capture - track what actually happened Track re-tests
Defect types
Process
Percentage completion
Time and effort
Input Store:
Actual
Failure frequency l
l For Re-use
The key to successful test management is like navigation - you need to know where you are now.
Audit ready
Distribute task and issue updating into the hands of the testing workforce so management does not Hints. Use tools if possible to capture what testers actually do, it will save time in diagnosing and
become a data entry exercise. for audit. Manage data to match the scenario. Review tests for regression suitability.

more information can be found at www.origsoft.com