Waterfall Software Model

The waterfall model is the oldest way to develop software. It is a sequential model, meaning that one product is developed and released to the customer with all agreed requirements in it. In this model another phase in the cycle commences after the previous one has finished. The largest drawback is that there is no flexibility available within this system. Each block is carved in stone before the process proceeds to the next phase.

Test Approach:

Requirements

Development

Release 1

Release 2

Release…

Final Version

Writing Test cases and Test Scripts

Full Functional Testing

Re-testing

Re-testing

User Acceptance Testing

Test Closure

Integration Testing

Regression Testing

Regression testing

System (integration) testing

Defect Handling

Defect Handling

Defect Logging

Test planning in a waterfall model is quite easy. After the requirements are approved and before coding has ended, there is time to write test cases and scripts. Due to the fact that requirements in this model are completely fixed and detailed, test cases can be derived very easily and detailed scripts can be set up.

When test execution starts, a complete version of the software is available (Release 1), so testing builds up from simple functionality testing to system integration testing. Defects found are logged and sent to development. When testing of the first release has completed, development can release the second version. In this testing phase testing activities are limited since no new functionality has been added or changed. Only solved defects have to be retested. Regression testing can be important, depending on the severity of the solved bugs, but forms no major part of the activities. The same can be said for all the subsequent releases that should be available sooner given the decrease of open defects. Testing stops upon decision of the test manager or when all exit criteria have been achieved.

V-Model

Software Model

The V- model is also a sequential and can be considered as an extension to the waterfall model. The V-Model offers more flexibility to software development. The phases are not fixed and each phase, including the testing phases, can influence past steps. During this process requirements can change, which can lead to added or changed functionality. Typical of the V-model is that each development phase has its corresponding phase on the testing side.

Test Approach:

Requirements

Development

Release 1

Release 2,3

Release…

Final version

Writing test cases and Test scripts

Full functional testing

Functional Testing new specs

Re-testing

User Acceptance Testing

Test Closure

Integration testing

Re-testing

Regression testing

System (integration) testing

Regression testing

Defect handling

Defect logging

Defect logging

Defect handling

Defect handling

Early on, during the user requirements definition phase, test activities start by deriving use cases, which are useful for acceptance and system testing. The same goes for all next phases. Test execution however only starts after a full functional release is available. The problem and risks that go with the V-Model are that requirements can change since there is feedback possible between test phases and the development phases. New functionalities can be added or changed toward future releases. This can cause problems in the area of testing since test scripts have to be updated or rewritten in line with the new specifications. When functionalities are added or changed, regression testing becomes more important because there is a large likelihood that the changes have affected untouched parts of the software. Even so, testing with the V-model is feasible to manage, monitor and control. Please note that defect is a slightly more difficult than in the Waterfall model due to the fact that new defects can be logged in each new release.
0 comments :: link
Database Testing…
Posted on 2008-Sep-30 at 03:20

Database testing is one of the most challenging tasks to be done by software testing team.

The database development lifecycle typically consists of several stages from planning to designing, testing and deployment. In the first phase of database development process, requirements are gathered; checklists can be used as part of the evaluation process for the database specification. After gathering requirement and understanding the need for the database, a preliminary list of the fields of data to be included in the database should be prepared. We should have complete information about what information is required by the client and what type of fields are required to produce that information. Next determine if the logical data model is complete and correct. Confirm the design with the business community in a design review process. Create a logical Entity Relationship Diagram (ERD) to graphically represent the data store. Determine if the data model is fully documented (entities, attributes, relationships) Attributes have correct data type, length, NULL status, default values. General discussion of business rules to be enforced by database level

Constraints should be carried out e.g.

• Not null constraints

• Check constraints

• Unique constraints

• Primary key constraints

• Foreign key constraints

Business rules to be enforced by triggers and procedures should be discussed along with the Business rules to be enforced by application code. After this the normal forms should be tested with the help of test data. Testing physical database design includes testing table definitions, constraints, triggers and procedures. Black Box testing techniques like Boundary value analysis can be used. We can test the table definition by testing the column definitions and constraints that have been imposed:

Database constraints can be checked as follows:

* Primary Key- Write Test Case to insert duplicate value in Primary Key column.
* Insert record to violate Referential Integrity Constraint.
* Delete record to violate Referential Integrity Constraint.
* Insert NULL value in NOT NULL column.
* Insert values to violate check constraints by inserting values outside input domains.

0 comments :: link
Successfull Performance Testing Principles /Approach
Posted on 2008-Sep-25 at 12:22

CCD IS EARI

* Context: Project context is central to successful performance testing.
* Criteria: Business, project, system, & user success criteria.
* Design: Identify system usage, and key metrics; plan and design tests.
* Install: Install and prepare environment, tools, & resource monitors.
* Script: Implement test design using tools.
* Execute: Run and monitor tests. Validate tests, test data, and results.
* Analyze: Analyze the data individually and as a cross-functional team.
* Report: Consolidate and share results, customized by audience.
* Iterate: “Lather, rinse, repeat” as necessary.

From Scott Barber
0 comments :: link
Test Strategy for v model process
Posted on 2008-Sep-23 at 01:36

Unit testing

Integration testing

System testing

User Acceptance testing

Objective

-Unit meets its design.

-Ensure low level quality

-System is ready for system test:

-Quick functional check

-System meets specification (FD)

-System meets specification (FD).

-System meets BR and expectations.

-System is fit for use in its business context.

Responsible

-Development

-Development

-Test team

-Acceptance testers in business units

Entry Criteria

-Developers are challenged to write unit tests by TLs and Seniors

-All unit tests pass

-FDs approved

All unit test pass.

-No open defects with severity major or higher

-Requirements system tested.

-No open defects with severity major or higher

Exit Criteria

-All unit tests pass (build does not fail)

-All unit tests pass.

-No open defects with severity major or higher

-100% tc executed.

-No open defects with severity major or higher

-System meets acceptance criteria.

-No regression

-Business approval for production deployment

Technique

Ad hoc testing

Ad hoc testing / error guessing

Black box techniques, error guessing

Error guessing

Some black box technique
0 comments :: link
Valu added of Testing
Posted on 2008-Sep-23 at 01:09

The added value of testing

* Provided testing is carried out well; it makes a positive contribution to the software development process. Testing leads to better software quality and a shorter time to market by:
* Contributing to the development of “fit-for-purpose” systems that work according to the requirements, quality attributes and expectations (implicit or other). It achieves the goal.
* Preventing damage while the system is live because errors will have been detected during testing and solved on time. This takes away the cause.
* Preventing damage while the system is live because the errors are known and their consequences have been anticipated. This reduces the impact.
* Providing insight into the quality of the test object, which instills confidence in the test object.
* Providing insight into the quality of the test object and its progress, making effective project coordination possible [Black, 2002].

Testing requires you to interpret the system’s reaction to the inputs. You compare the output with the expected output. But who tells you the expected output?

The test oracle!

It is defined as a mechanism that decides if a result is right or wrong. In principle, you look into the specification. But often, results are complicated and interpretation is difficult. It would be nice to have an automatic oracle. This would be another program, but it could be a spreadsheet implementation for the mathematics, or an older version of the program. If this is not available, you may test with “easy values”, where manual calculation is easy. Or you might deviate from full checking and just does plausibility check. In the worst case, the only thing you do is check that the program does not crash.
0 comments :: link
Tester’s Rights
Posted on 2008-Sep-18 at 11:16

1. Testers have the right to sample their process inputs, and reject poor quality work (no entry).
2. Testers have the right to unambiguous and clear requirements.
3. Testers have the right to test evolutionarily early as the system increments.
4. Testers have the right to integrate their test specifications into the other technical specifications.
5. Testers have the right to be a party to setting the quality levels they will test to.
6. Testers have the right to adequate resources to do their job professionally.
7. Testers have the right to an even workload, and to have a life.
8. Testers have the right to specify the consequences of products that they have not been allowed to test properly.
9. Testers have the right to review any specifications that might impact their work.
10. Testers have the right to focus on testing of agreed quality products, and to send poor work back to the source.
11. Testers should send bad work to the source

More and more organizations make efforts to improve their software development processes. The reference model that is most often used is the Capability Maturity Model Integration (CMMI). In this model practices that are related to verification and validation activities are described, but the level of detail is too limited from the viewpoint of the test professional. To fill this gap, the Test Maturity Model Integration (TMMi) has been developed by the TMMi Foundation [www.tmmifoundation.org], using the TMM framework as developed by the Illinois Institute of Technology as one of its major sources. The TMMi provides a structured approach for test process improvement. Testing as defined in the TMMi is applied in its broadest sense to encompass all software quality-related activities. Within Europe the number of companies using the TMMi is increasing.

Practical experiences are positive and show that the TMMi and its predecessor TMM support the process of establishing a more effective and efficient test process. Testing becomes a profession and a fully integrated part of the software development life cycle. Applying the TMMi maturity criteria will improve the testing process and has a positive impact on product quality, test engineering productivity, and test execution lead-time.

For a complete description of the TMMi and its guidelines we refer to the web pages of the TMMi Foundation.