Showing posts with label STLC. Show all posts
Showing posts with label STLC. Show all posts

Sunday, July 12, 2009

SDLC & STLC

STLC – Software Testing Life Cycle
  • Preparation of Testing Project Plan which includes Test Strategy.
  • Preparation of Test Scripts which contains Test Scenarios.
  • Preparation of Testing Bed. i.e.: Setting up the Test Environment
  • Executing the Test Scripts (Automated as well as Manual Tests)..
  • Defect Tracking with any bug tracking tools.
  • Preparation of Test Completion Report and Test Incident Report.
  • Preparation of Test Metrics for Continuous Process Improvement.


Models of SDLC & STLC
There are a number of different models for software development life cycle. One thing which all
models have in common is that at some point in the life cycle, software has to be tested. This
paper outlines some of the more commonly used software development life cycle, with particular
emphasis on the testing activities in each model.

1. V-Model

The figure shows the brief description of the V-Model kind of testing. Every phase of the STLC in
this model corresponds to some activity in the SDLC. The Requirement Analysis would
correspondingly have an acceptance testing activity at the end. The design has Integration
Testing (IT) and the System Integration Testing (SIT) and so on.







  • V model is model in which testing is done parallel with development. Left side of v model, reflect development input for the corresponding testing activities.
  • V model is the classic software development model. It encapsulates the steps in Verification and Validation phases for each step in the SDLC. For each phase, the subsequent phase becomes the verification (QA) phase and the corresponding testing phase in the other arm of the V becomes the validating (Testing) phase
  • In the Software Development Life Cycle, both the Development activity and the testing activities start almost at the same time with the same information in their hands. The development team will apply "do-procedures" to achieve the goals and the testing team will apply "Check-procedures" to verify that. Its a parallel process and finally arrives to the product with almost no bugs or errors
  • V-model is one of the SDLC STLC; it includes testing from the unit level to business level. That is after completing the coding tester starts testing the code by keeping the design phase documents that all the modules had been integrated or not, after that he will verify for system is according to the requirements or not, and at last he will go for business scenarios where he can validate by the customer and he can do the alpha testing and beta testing. And at last he decides to have the complete stable product.
  • The V model shows the Development Cycle Stages and Maps it to Testing Cycles, but it fails to address how to start for all these test levels in parallel to development. It is a parallel activity which would give the tester the domain knowledge and perform more value added, high quality testing with greater efficiency. Also it reduces time since the test plans, test cases, test strategy are prepared during the development stage itself.
2.W-Model
From the view of testing, all of the models presented previously are deficient in various ways. The
test activities first start after the implementation:
  • The connection between the various test stages and the basis for the test is not clear
  • The tight link between test, debug and change tasks during the test phase is not clear
In the following, the W-model is presented. This is based on the general V-model and the
disadvantages previously mentioned are removed.
3.Waterfall Model
One of the first models for software development is the so-called waterfall-model by B.W.Boehm.
The individual phases i.e. activities that were defined here are to be found in nearly all models
proposed since. In this it was set out that each of the activities in the software development must
be completed before the next phase begins. A return in the development process was only
possible to an immediate previous phase.


In the waterfall-model, testing directly follows the implementation. By this model it was suggested that activities for testing could first be started after the implementation. Preparatory tasks for the testing were not clear. A further disadvantage is that testing, as the last activity before release, could be relatively easily shortened or omitted altogether. This, in practice, is unfortunately all too common. In this model, the expense of the removal of faults and defects found is only recognizable through a return to the implementation phase.


4.Extreme Programming Model




5.Spiral Model

In the spiral-model a cyclical and prototyping view of software development was shown. Tests
were explicitly mentioned (risk analysis, validation of requirements and of the development) and
the test phase was divided into stages. The test activities included module, integration and
acceptance tests. However, in this model the testing also follows the coding. The exception to this
is that the test plan should be constructed after the design of the system. The spiral model also
identifies no activities associated with the removal of defects

Saturday, March 7, 2009

Software Testing Life Cycle

Software testing life cycle identifies what test activities to carry out and when (what is the best time) to accomplish those test activities. Even though testing differs between organizations, there is a testing life cycle.

Software Testing Life Cycle consists of six (generic) phases:
  • Test Planning,
  • Test Analysis,
  • Test Design,
  • Construction and verification,
  • Testing Cycles,
  • Final Testing and Implementation and
  • Post Implementation.
Software testing has its own life cycle that intersects with every stage of the SDLC. The basic requirements in software testing life cycle is to control/deal with software testing – Manual, Automated and Performance.


Test Planning

This is the phase where Project Manager has to decide what things need to be tested, do I have the appropriate budget etc. Naturally proper planning at this stage would greatly reduce the risk of low quality software. This planning will be an ongoing process with no end point.
Activities at this stage would include preparation of high level test plan-(according to IEEE test plan template The Software Test Plan (STP) is designed to prescribe the scope, approach, resources, and schedule of all testing activities. The plan must identify the items to be tested, the features to be tested, the types of testing to be performed, the personnel responsible for testing, the resources and schedule required to complete testing, and the risks associated with the plan.). Almost all of the activities done during this stage are included in this software test plan and revolve around a test plan.


Test Analysis

Once test plan is made and decided upon, next step is to delve little more into the project and decide what types of testing should be carried out at different stages of SDLC, do we need or plan to automate, if yes then when the appropriate time to automate is, what type of specific documentation I need for testing.
Proper and regular meetings should be held between testing teams, project managers, development teams, Business Analysts to check the progress of things which will give a fair idea of the movement of the project and ensure the completeness of the test plan created in the planning phase, which will further help in enhancing the right testing strategy created earlier. We will start creating test case formats and test cases itself. In this stage we need to develop Functional validation matrix based on Business Requirements to ensure that all system requirements are covered by one or more test cases, identify which test cases to automate, begin review of documentation, i.e. Functional Design, Business Requirements, Product Specifications, Product Externals etc. We also have to define areas for Stress and Performance testing.


Test Design

Test plans and cases which were developed in the analysis phase are revised. Functional validation matrix is also revised and finalized. In this stage risk assessment criteria is developed. If you have thought of automation then you have to select which test cases to automate and begin writing scripts for them. Test data is prepared. Standards for unit testing and pass / fail criteria are defined here. Schedule for testing is revised (if necessary) & finalized and test environment is prepared.


Construction and verification

In this phase we have to complete all the test plans, test cases, complete the scripting of the automated test cases, Stress and Performance testing plans needs to be completed. We have to support the development team in their unit testing phase. And obviously bug reporting would be done as when the bugs are found. Integration tests are performed and errors (if any) are reported.


Testing Cycles

In this phase we have to complete testing cycles until test cases are executed without errors or a predefined condition is reached. Run test cases --> Report Bugs --> revise test cases (if needed) --> add new test cases (if needed) --> bug fixing --> retesting (test cycle 2, test cycle 3….).


Final Testing and Implementation

In this we have to execute remaining stress and performance test cases, documentation for testing is completed / updated, provide and complete different matrices for testing. Acceptance, load and recovery testing will also be conducted and the application needs to be verified under production conditions.


Post Implementation

In this phase, the testing process is evaluated and lessons learnt from that testing process are documented. Line of attack to prevent similar problems in future projects is identified. Create plans to improve the processes. The recording of new errors and enhancements is an ongoing process. Cleaning up of test environment is done and test machines are restored to base lines in this stage.








Software Testing Life Cycle
Phase
Activities
Outcome
Planning
Create high level test plan
Test plan, Refined Specification
Analysis

Create detailed test plan, Functional Validation Matrix, test cases
Revised Test Plan, Functional validation matrix, test cases
Design

test cases are revised; select which test cases to automate
revised test cases, test data sets, sets, risk assessment sheet
Construction

scripting of test cases to automate,
test procedures/Scripts, Drivers, test results, Bugreports.
Testing cycles
complete testing cycles
Test results, Bug Reports
Final testing
execute remaining stress and performance tests, complete documentation
Test results and different metrics on test efforts
Post implementation
Evaluate testing processes
Plan for improvement of testing process