Continue in 2 seconds

I am new to data warehousing.

Published
  • February 03 2003, 1:00am EST

Q:

I am new to data warehousing. I am working on a DW project. The role of my team is to do system testing for the project. I would like to know how can we estimate the system testing effort for the project. Is there any standard method for estimating the effort required for system testing?

A:

Clay Rehm’s Answer: Testing always seems to be the most misunderstood task of any software project. Many project teams even disagree on the scope, semantics and components of testing and how much testing really needs to be accomplished.

Figure 1: Terminology
Testing Technique Test Objective Description
Concurrency Test To test whether multiple users can create system deadlocks or damage each other’s work.
Configuration Test To verify that the product can be installed and operated in different hardware and software environments.
Conversion Test To determine whether old data files and record balances are carried forward accurately and properly.
Function Test To verify that each required capability is implemented correctly.
Integration Test To test a group of programs to see that a transaction or data passes between programs.
Interface Test To demonstrate that all systems work in concert.
Load/Volume Test To test whether simultaneous users can overload the system.
Parallel Test To verify that each test results from the two systems are compared with each other.
Performance Test To measure resources required such as memory, disk and to determine system response time.
Pilot Test To test a new system in one department or division at a time until enough experience is gained prior to launching an all-out implementation throughout the organization.
Production Acceptance Test To test operational preparedness of a new system prior to move from test to production environment.
Quality Assurance Test To make the software product fail.
Recovery Test To determine whether the system can function normally after a system failure, error or other malfunction.
Regression Test To verify that changes do not introduce new errors.
Security Test To determine whether unauthorized people can use computer resources.
Stress Test To verify boundary conditions of a program.
System Test To test the entire system to prove the validity of the software requirements definition and design specifications including its interfaces.
Unit Test To test individual programs, modules, subroutines or subprograms to verify their functionality.
User Acceptance Test To test software functions and features; to determine if the system meets business needs; and to see if the system was developed according to user requirements.

As you can see, there is more to testing than just "system testing!" The only real way to estimate how long testing will take is to involve the business users, the test team and the developers very early on in the project to develop a test strategy. Out of the test strategy will come a test plan – more specifically you will get test cases and scenarios. Each scenario must be documented along with the expected result. Does this sound time-consuming? You bet! But how will you guarantee to your customers that your system does what it is supposed to do if you have not followed a detailed test plan?

A detailed test plan and test cases will really identify if the programming that was completed was done accurately and thoughtfully. Think of it this way – the testing will prove or disprove the competence of your programmers, and how well the requirements were identified and followed.

Keep in mind that your users are identifying what the system will do. These are requirements, and IT has a terrible track record in properly identifying requirements. Each requirement should be achievable and testable. If a requirement is to make someone happy, how do you test that? You can’t! Your requirements must be at a more finite level.

If you think of testing as an extension of programming, and following a very detailed and thorough test plan, the time it takes to do it correctly would be easily double your programming effort.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access