Contains a brief description on the Life Cycle and the different Testing Models.

SDLC:

The software development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application/product.

V-Model:

The V-Model shows and translates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model is a software development model which is considered to be an extension of the waterfall model. Instead of moving down in a linear way, the process steps are targeted upwards after the coding phase, to form the typical V shape.

Requirements analysis: In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. The user acceptance tests are designed in this phase.

System Design: System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.

The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.

High-level design: This phase can also be called as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.

Low-level design: This phase can also be called as low-level design. The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo-code - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test design is developed in this stage."

Waterfall Model:

The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.

The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time.

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage.

Stages: Project Planning -> Requirements definition -> Design -> Development -> Integration and Testing -> Installation/Acceptance -> Maintenance

Spiral Model:

There are four phases in the "Spiral Model" which are: Planning, Evaluation, Risk Analysis and Engineering. These four phases are iteratively followed one after other in order to eliminate all the problems, which were faced in "The Waterfall Model". Iterating the phases helps in understating the problems associated with a phase and dealing with those problems when the same phase is repeated next time, planning and developing strategies to be followed while iterating through the phases.

Agile Process:

Agile aims to reduce risk by breaking projects into small, time-limited modules or timeboxes ("iterations") with each iteration being approached like a small, self-contained mini-project, each lasting only a few weeks. Each iteration has it own self-contained stages of analysis, design, production, testing and documentation. In theory, a new software release could be done at the end of each iteration, but in practice the progress made in one iteration may not be worth a release and it will be carried over and incorporated into the next iteration. The project's priorities, direction and progress are re-evaluated at the end of each iteration.

Test life cycle:

1. Test Requirements stage - Requirement Specification documents, Functional Specification documents, Design Specification documents (use cases, etc), Use case Documents, Test Trace-ability Matrix for identifying Test Coverage.
2. Test Plan - Test Scope, Test Environment, Different Test phase and Test Methodologies, Manual and Automation Testing, Defect Management, Configuration Management, Risk Management, Evaluation & identification – Test, Defect tracking tools, test schedule, resource allocation.
3. Test Design - Traceability Matrix and Test coverage, Test Scenarios Identification & Test Case preparation, Test data and Test scripts preparation, Test case reviews and Approval, Base lining under Configuration Management.
4. Test Environment Setup - Test Bed installation and configuration, Network connectivity's, All the Software/ tools Installation and configuration, Coordination with Vendors and others.
5. Test Automation - Automation requirement identification, Tool Evaluation and Identification, Designing or identifying Framework and scripting, Script Integration, Review and Approval, Base lining under Configuration Management.
6. Test Execution and Defect Tracking - Executing Test cases, Testing Test Scripts, Capture, review and analyze Test Results, Raise the defects and tracking for its closure.
7. Test Reports and Acceptance - Test summary reports, Test Metrics and process Improvements made, Build release, Receiving acceptance.

Bug Life Cycle

Some terminologies in the Defect / Bug life cycle.

Bug:

Product is still not yet released in the market. Found before production.

Defect:

Product is released in the market. Found after production.

Defect States:

States:
-Open
-Fixed
-Verified
-Closed
-Double/Duplicate
-Reject (Works as per Requirements, wont fix, works for me)

Defect Content:

Defect heading: IE Error. “Error Loading https://localhost:10000/index.cgi Connection refused”
Hardware Used:

Software version:
Environmental parameters:
Failed Test case ID:
Failed Requirement Id:
Occurrence: Repeatable/Random
Severity:
Keyword/Responsible:
Steps to Reproduce the Problem:
Expected Result: IE login page should be displayed.
Actual Result: Error is displayed. “Error Loading https://localhost:10000/index.cgi Connection refused”
Screenshots if any:
Log files if any:
Time stamp for crash defects:

Severity:

Severity refers to the level of impact, the defect has created on the users. This is set by the tester. Below are some of the common types.
Unacceptable Risk/Blocker: Crash or A risk to the patient/user, operator, service personnel, etc. Creates a Safety Risk
Design NC/Critical: Non-conformance to design input (product specification)
Improvement Opportunity: Observations that do not represent a Design Defect or belong to any of the previous classes
- Enhancements
- Productivity Opportunities

However this varies from company to company.

Priority:

Priority refers to the "Urgency" with which the incident has to be fixed. This is set by the lead.
In most of the cases a critical incident can be of high priority.

Defect example for each severity:

Unacceptable Risk - In a patient monitoring system if the Product /application Crashes, Incorrect parameter value (ex. Instead of 60 Heart Rate 80 Heart Rate is displayed)
Design NC - Patient information not displayed under User Information.
Minor Issue - IP address textbox should be grayed out when DHCP is selected
Improvement Opportunity - Some cosmetic defect which is negligible. ex. when a sub-menu is opened the borders of the sub-menu is cut off. or Documentation Issue.

What to do when a defect is not reproducible:

1. Test on another setup.
2. Take pictures and video the first time the defect occurs.
3. Save and Attach the Log file.