Status of Bug

Status of Bug

       1>New

       2>Open

       3>Rejected

       4>Fixed

       5>Closed

Bug Life Cycle

BUG LIFE CYCLE

V-Model

V-MODEL

Ø  Just like the WFM, the V-shaped life cycle is a sequential path of execution of process

Ø  Each phase must be completed before the next phase begins.

Ø  Testing is emphasized in this model more.

Ø  The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation.

Ø  Requirements begin the life cycle just like the WFM. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.

Ø  The design phase focuses on system architecture & design. An integration test plan is created in this phase as well in order to test the piece of s/w systems ability to work together.

Ø  The low Level Design (Coding) phase is where the actual s/w component are designed & unit tests are created in this phase as well.

Ø  Once Coding is completed, the path of execution continues up the right side of the V, where the test plans developed earlier are now put to use.

ADVANTAGES

1)      Simple & easy to use.

2)      Each phase has specific deliverables.

3)      Higher chance of success over the WFM due to the development of test plans early on during the life cycle.

4)      Works well for small projects where requirements r easily understood.

     DISADVANTAGES

1)      Very rigid, like WFM(It needs lot of resources & money)

2)      S/W is developed during the implementation phase, so no early prototype of the s/w is produced.

3)      Model doesn’t provide a clear path problem found during testing phase.

4)      Little flexible & adjusting scope is difficult & expensive.

Spiral Model

SPIRAL MODEL

Ø  The Spiral Model is similar to the incremental model, with more emphasis placed on risk analysis.

Ø  In spiral Model, the angular component represents “PROGRESS” & the radial component represent “COST”.

Ø  Each cycle in the spiral begins with the identification of objectives for that cycle, the different alternatives that r possible for achieving the objectives & the constraint that exist.

Ø  Next Step in the cycle is to evaluate these different alternatives based on objectives & constraint, design for that cycle. The focus of evaluation in this step is based on the risk perception for the project. Risk reflects the chances that some of the objectives of the project may be not met.

Ø  The next step is to develop strategies that resolve uncertainties & risk. This step may involve activities such as benchmarking, simulation & prototyping.

Ø  Finally in 4^th quadrant we plan for the next cycle or module.

Ø  The spiral model works for development as well as enhancement projects.

ADVANTAGES

1)      High amt of risk analysis, so preferred for high risks projects.

2)      Good for large & mission critical projects.

3)      S/W is produced early in the s/w life cycle.

DISADVANTAGES

1)      Can be a costly model to use.

2)      Risk analysis requires specific expertise...

3)      Project’s success is highly dependent.

Evolutionary Model

ITERATIVE ENHANCEMENT or EVOLUTIONARY MODEL

Ø  This model counters the limitation of WFM that requirements be completely specified before the rest of the development can proceed & tries to combine the benefits of both prototyping & WFM.

Ø  One effective use of this type of model is for product development.

Ø  The s/w should be developed in increments, each increment adding some functional capability to the system until the full system is implemented.

Ø  At each step (iteration), extensions & design modification can be made.

Ø  Each iteration passes through the requirements, design, implementation & testing process.

Ø  A working version of s/w is produced during the first iteration, so u have working s/w early on during the s/w development life cycle.

Ø  Subsequent iterations build on the initial s/w produced during the first iteration.

Ø  First a version is released that contains some capability. Based on feedback from users & experience with this version, a list of additional desirable’s features & capabilities is generated. These features form the basis of enhancement of the s/w & are included in the next version.

The first version contains some core capabilities & then more are added to later versions.

ADVANTAGES

1)      Generates working s/w quickly & early during the s/w life cycle.

2)      More flexible –less costly to change scope & requirements.

3)      Easier to test & debug in each increments than testing entire system as in WFM.

4)      Easier to manage risk becoz risky pieces r identified & handled during its iterations.

5)      Each iteration is an easily managed milestone.

DISADVANTAGES

1)      In generating business contract- how will the cost of additional features be determined & negotiated, particularly becoz the client organization is likely to be tied to the original vendor who developed the first version.

2)      Problems may arise pertaining to system architecture becoz not all requirements are gathered up front for the entire s/w life cycle.

3)      Each phase of an iteration is rigid & do not overlap each other.

Prototyping Model

PROTOTYPING MODEL

Ø  The goal of a prototyping –based development process is to counter the limitation of WFM. Requirement frozen.

Ø  Instead of freezing the requirements before any design  or coding can proceed, a throwaway prototype is built to help understand the requirements. This prototype is developed based on the currently known requirements.

Ø  By using this prototype, the client can get an actual feel of the system, because the intraction with the prototype can enable the client to better understand the requirements of the desired system. This results in more stable requirements that change less frequently.

Ø  After the prototype has been developed, the end user & clients are given an opportunity to use the prototype & play with it.

Ø  Based on their experience, they provide feedback to the developers regarding the prototype: What is correct, what needs to be modified, what is missing, what is not needed.

Ø  Based on the feedback, the initial requirements are modified to produce the final requirements specification, which is then used to develop the production quality system.

ADVANTAGES

1)      It is well suited for projects where requirements are hard to determine & the confidence in obtained requirements is low.

2)      It is an excellent technique for reducing some types of risks associated with a project.

3)      By using COST CUTTING METHODS, it is possible to keep the cost of prototype less than a few percent of the total development cost. COST CUTTING METHODS-Minimal documentation, Reduce Testing.

            DISADVANTAGES

1)      Inferior, temporary design solutions may become  permanent after  a while, when  the developers has forgotten  that they were only intended to be temporary.(Result in poor software quality)

2)      Customer may object to prototyping being  thrown away & may demand “ a few changes” to make it working .(Result in poor s/w quality & maintainability)

3)      MINIMAL DOCUMENTATION may cause problem, in prototyping. Design doc, a test plan, a test case specification r not needed during the development of prototype. REDUCE TESTING cost cutting measures-but results in low quality product.

èPrototyping is often not used , as it is feared that development costs may become large. However, in some situations, the cost of s/w development without prototyping may be more than with prototyping. There r two major reason for that………..

a)      The experience of developing the prototyping might reduce the cost of the the later phases when the actual software development is done.

b)      In many projects the requirements are constantly changing, particularly when development takes a long time.

Waterfall Model

WATERFALL MODEL

Ø  WFM states that the phases are organized in a linear order. It is also referred as linear sequential life cycle model.

Ø  Each phase must be completed in its entirety, before the next phase can begin.

Ø  There r 2 assumptions made, when we work with WFM

v  For a successful project resulting in a successful product, all phases listed in WFM must be performed in anyways.

v  Any different ordering of the phases will result in a less successful software product.

Ø  In a typical model, a project begins with feasibility study. On successful demonstrating the feasibility of project, the requirements analysis & project planning begins. The design Starts after the requirements analysis is completed & coding begin after the design is completed. Once the programming is completed, the code is integrated & testing is done. On successful completion of testing, the system is installed. After this, the regular operations & maintenance of the system takes place.

Ø  When the activities of the phase r completed, there should be some product that is produced by the phase. The Goal of a phase is to produce this product. The o/ps of the earlier phases r often called WORK PRODUCTs (or intermediate products) & r usually in the form of documents like the requirement doc or design doc.

Ø  O/Ps of phases r-   
1>Requirement Doc
2>Project Plan
3>System Design Doc
4>Detailed Design Doc
5>Test plan & Test Reports
6>Final Code
7>Software manual(e.g. User, installation etc)

ADVANTAGES

1)      Simple & easy to use.

2)      Phases r processed & completed one at a time.

3)      Work well for smaller projects where requirements are very well understood.

4)      Easy to manage due to rigidity of Model-each phase has specific deliverables & a review process.

      DISADVANTAGES

1)      The requirements of the system can be frozen before the design begin, we can’t change SRS if design is done.

2)      Working s/w produced at the end of all phases so there is a long wait.

3)      High amt of risk & uncertainty.

4)      Poor Model where requirements r at a moderate –high risk of changing.

5)      Poor Model for long n ongoing projects.

6)      Poor Model for complex & Object oriented projects.

SDLC Models

SDLC or SOFTWARE PROCESS MODELS

SDLC is a structured & organized approach in which we go for life cycle of software. How a s/w starts & develops & ends.

Following are the main Process models

1>Waterfall Model

2>Prototype Model

3>Evolutionary Model

4>Spiral Model

5>V-Model

SDLC-S/W Development Life Cycle

SDLC or SOFTWARE PROCESS

It is a structured & organized approach in which we go for life cycle of software. How a s/w starts & develops & ends.

It has several phases start with …         

1>Feasibility Study:- The analysts conducts an initially study of the problem & ask is the solutions.

Ø  Is software is technologically possible?

Ø  Is software is economically possible?

Ø  Is software is Legally possible?

Ø  Is software is Operationally possible?

2>Requirement Analysis:-

Ø  Business requirements are gathered in this phase.

Ø  Meetings with managers, Stake holders & users are held in order to determine the requirements.

Ø  Who is going to the system?
How will they use the system?
What data should be input into the system?
What data should be o/p by the system?
These are the general question asked during a requirement gathering phase.

Ø  This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that process data, what data is stored & used by the system & how the user interface should work.

Ø  The overall result is the system as a whole & how it performs, not how it is actually going to do it.

3>Design:-

Ø  The s/w system design is produced from the results of the requirements phase.

Ø  This is where the details on how the system will work is produced.

Ø  Architecture, including h/w, s/w, communication, s/w design are all part of the deliverables of a design phase.

Ø  Design Document that consists of Architectural Design, Database Design & Interface design.

4>Implementation:-

Ø  Code is produces from the deliverables of the design phase during Implementation.

Ø  This is the longest phase of the SDLC.

Ø  If the design is performed in a detailed manner, code generation can be accomplished without much complication.

5>Testing:-

Ø  During testing, the implementation is tested against the requirements to make sure that the product is actually solving the needs addressed & gathered during the requirement phase.

6>Installation & maintenance:-

Ø  During Installation, the s/w is deployed to customer site & it ready to use by the customer.

Ø  The s/w will definitely undergo change once it is delivered to the customer.

Ø  The software should be developed to accommodate change that could happen during the post implementation period.

                                                                          

S/W Test Life Cycle (STLC)

Software Test Life Cycle (STLC)

Level of Testing

LEVEL OF TESTING

Unit Testing- In this, different modules r tested against the specification produced during design for the modules.

Integration Testing:- In this, many unit tested modules r combined into subsystems, which r then tested. The goal here is to see if the modules can be integrated properly.

System Testing:- here the system is tested against the system requirements to see if all the requirements r met  & if the system performed as specified by the requirements.

Acceptance Testing:- testing when development & testing r essentially completed & final Bugs & problems need o be found before final release.

Test Cases for Pen

These are the possible test cases for Testing of a Writing Pen

T.C. 1:  Verify whether the cap is opening or not
T.C. 2:  Verify whether there is a riffle in it or not
T.C. 3:  Verify whether it is writing or not
T.C. 4:  Verify to write on different objects
T.C. 5:  verify is there any leakage during writing
T.C. 6:  Verify the characters are visible
T.C. 7:  Verify whether it is refillable or not.
T.C. 8:  verify is there any damage.  
T.C. 9:  Verify if it is breakable or not
T.C. 10:  Verify it is comfortable or not
T.C. 11:  Compare it with other models

If you can add some more test cases in it, plz add, its a practice exercise for you.

Basics of Testing

SOFTWARE TESTING:-

Testing is a process used to help identify the correctness, completeness & Quality of developed Software using manual or Automation methods.

TEST CASE:-

*Test Case is the set of procedures in order to find out bugs.

* Test case is a description of Wht to be tested, Wht data to be given & wht action to be taken to check the actual result against the expected result.

TEST PLAN:-

• A s/w project test Plan is a document that describes the Objectives, Scope, Approaches 7 focus of a S/W Testing effort.
• It is planning how to test 7 wht to test & how to follow.
• Test plan is the document where it contains the elements like

Ø  Items to be tested

Ø  Items need not be tested

Ø  Test Schedule, test Case Design & Execution

Ø  Pass/Fail Criteria, Approaches to test

Ø  Roles & responsibilities of the test Team

Ø  Defect management

Ø  Risk Assessment

WHEN TO STOP TESTING:-

*When All the requirements are adequately executed successfully through Test Cases.

*Bug reporting rate reaches a particular min threshold limit.

* The Scheduled time for testing is over.

*The budget allocation for Testing is over.

SOFTWARE QUALITY:-
Software Quality based on these factors, A Software is a Quality Software when a s/w is

• Bug Free
• Delivered on Time
• Within Budget
• Meets Requirements
• Is Maintainable