Software Testing Trainning - Day2

  • Uploaded by: T.S.A.Zahir Hussain
  • 0
  • 0
  • May 2020
  • PDF

This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA


Overview

Download & View Software Testing Trainning - Day2 as PDF for free.

More details

  • Words: 859
  • Pages: 17
Software Development Life Cycle.

Day 2-Session 1 Lavanya.M

Software Process Coherent sets of activities for specifying, designing, implementing and testing software systems Objectives To introduce software lifecycle models To describe a number of different lifecycle models and when they may be used To describe outline process models for requirements engineering, software development, testing and evolution

SDLC Business Functional Req. Spec.

Requirements

Design Spec

Analysis

Code/Build

Development

Unit Testing

Testing

System Testing

Implementation

Performance

Maintenance

Life Cycle Models There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some are listed below. V- Model Water Falls Model Extreme Programming Spiral Model

V - Model User Requirements

Corrective

Acceptance testing

Preventive

System Testing

Analysis

High Level Design

Integration Testing

Low Level Design

Unit Testing

Code

V- MODEL

V- Model Development It is the model what is using by most of the companies. 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. 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.

Waterfalls Model.

Disadvantage of Water falls Model. Disadvantages : More rework and changes will be more, if any error occurs, Time frame will be more, More people will be idle during the initial time Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements.

Extreme Programming.

New approach to development based on the development and delivery of very small increments of functionality Relies on constant code improvement, user involvement in the development team and pair wise programming

Spiral Model. Determine objectives alternatives and constraints

Evaluate alternatives identify, resolve risks Risk analysis Risk analysis Risk analysis

REVIEW Requirements plan Life-cycle plan

Plan next phase

Prototype 3

Prototype 2 Risk analysis Prototype 1

Operational protoype

Simulations, models, benchmarks Concept of Operation

S/W requirements

Development plan

Requirement validation

Integration and test plan

Design V&V

Product design

Detailed design

Code Unit test

Integration test Acceptance test Develop, verify Service next-level product

Spiral Development Process is represented as a spiral rather than as a sequence of activities with backtracking Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required Risks are explicitly assessed and resolved throughout the process

Key Points Software processes are the activities involved in producing and evolving a software system. They are represented in a software process model General activities are specification, design and implementation, validation and evolution Lifecycle models describe the organisation of software processes. Iterative process models describe the software process as a cycle of activities

Project Management. Project Initiation: Map Activities to Software Life Cycle Model Allocate Project Resources Establish Project Environment Plan Project Management Project Monitoring and Control Analyze Risks Perform Contingency Planning Manage the Project Retain Records Implement Problem Reporting Model

Project Management. Software Quality Management • Plan Software Quality Management • Define Metrics • Manage Software Quality • Identify Quality Improvement Needs

Requirement Management. Requirement Management is to gather and manage user, business, technical, and functional requirements within a product development project. • Frequency of change in the total requirements set • Rate of introduction of new requirements • Number of requirements changes to a requirements baseline • Percentage of defects with requirement errors as the root cause • Number of requirements-related change requests (as opposed to defects found in

Risk Management. Risk Management is the process of measuring, or assessing risk and developing strategies to manage it. Strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Traditional risk management focuses on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death, and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments. Software Risk Evaluation (SRE) Continuous Risk Management (CRM) Team Risk Management (TRM)

Configuration Management. Software Configuration management is an umbrella activity that is applied throughout the software process. SCM identifies controls, audits and reports modifications that invariably occur while software is being developed and after it has been released to a customer. All information produced as part of software engineering becomes of software configuration. The configuration is organized in a manner that enables orderly control of change. The following is a sample list of Software Configuration Items:  Management plans (Project Plan, Test Plan, etc.)  Specifications (Requirements, Design, Test Case, etc.)  Customer Documentation (Implementation Manuals, User Manuals, Operations Manuals, On-line help Files)  Source Code (PL/1 Fortran, COBOL, Visual Basic, Visual C, etc.)  Executable Code (Machine readable object code, exe's, etc.)  Libraries (Runtime Libraries, Procedures, %include Files, API's, DLL's, etc.)  Databases (Data being Processed, Data a program requires, test data, Regression test data, etc.)  Production Documentation

Related Documents


More Documents from ""

Background Note
June 2020 30
December 2019 31