Friday, December 28, 2012

Agile SDLC Model

  • Speeds up or bypasses one or more life cycle phases.
  • Usually less formal and reduced scope.
  • Used for time-critical applications.
  • Used in organizations that employ disciplined methods.


Some Agile Methods:

  • Adaptive Software Development (ASD)
  • Feature Driven Development (FDD)
  • Crystal Clear
  • Dynamic Software Development Method (DSDM)
  • Rapid Application Development (RAD)
  • Scrum
  • Extreme Programming (XP)
  • Rational Unified Process (RUP)


Agile process SDLC Model
Agile SDLC


IMPORTANT LINKS:




Spiral Model

Adds risk analysis, and 4gl RAD prototyping to the waterfall model.
Each cycle involves the same sequence of steps as the waterfall process model.


Spiral-SDLC-Model
Spiral Model
Typical Activities:
  • Create a design
  • Review design
  • Develop code
  • Inspect code
  • Test product

Spiral Model Strengths:
  • Provides early indication of insurmountable risks, without much cost.
  • Users see the system early because of rapid prototyping tools.
  • Critical high-risk functions are developed first.
  • The design does not have to be perfect.
  • Users can be closely tied to all life-cycle steps.
  • Early and frequent feedback from users.
  • Cumulative costs assessed frequently.

Spiral Model Drawbacks:
  • Time spent for evaluating risks too large for small or low-risk projects.
  • Time spent planning, resetting objectives, doing risk analysis and prototyping may  be excessive.
  • The model is complex.
  • Risk assessment expertise is required.
  • Spiral may continue indefinitely.
  • Developers must be reassigned during non-development phase activities.
  • May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration.

When to use Spiral Model:
  • When creation of a prototype is appropriate.
  • When costs and risk evaluation is important.
  • For medium to high-risk projects.
  • Long-term project commitment unwise because of potential changes to economic priorities.
  • Users are unsure of their needs.
  • Requirements are complex.
  • New product line.
  • Significant changes are expected.


Incremental Model


Incremental Model
Incremental Model



  • Constructs a partial implementation of a total system.
  • Then slowly adds increased functionality.
  • The incremental model prioritizes requirements of the system and then implements them in groups.
  • Each subsequent release of the system adds function to the previous release, until all designed functionality has been implemented.


Incremental Model Strengths:
Incremental Model - SDLC
Incremental Model

  • Develop high-risk or major functions first.
  • Each release delivers an operational product.
  • Customer can respond to each build.
  • Uses  “divide and conquer” breakdown of tasks.
  • Lowers initial delivery cost.
  • Initial product delivery is faster.
  • Customers get important functionality early.
  • Risk of changing requirements is reduced.


Incremental Model Draw Backs:

  • Requires good planning and design.
  • Requires early definition of a complete and fully functional system to allow for the definition of increments.
  • Well-defined module interfaces are required (some will be developed long before others).
  • Total cost of the complete system is not lower.


When to use Incremental Model:

  • Risk, funding, schedule, program complexity, or need for early realization of benefits.
  • Most of the requirements are known up-front but are expected to evolve over time.
  • A need to get basic functionality to the market early.
  • On projects which have lengthy development schedules.
  • On a project with new technology.



Thursday, December 27, 2012

Rad-Model



  • Requirements planning phase - a workshop utilizing structured discussion of business problems.
  • User description phase – automated tools capture information from users.
  • Construction phase – productivity tools, such as code generators, screen generators, etc. inside a time-box. (“Do until done”)
  • Cut over phase  -- installation of the system, user acceptance testing and user training.


RAD - Strengths:

  • Reduced cycle time and improved productivity with fewer people means lower costs.
  • Time-box approach mitigates cost and schedule risk.
  • Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs.
  • Focus moves from documentation to code.
  • Uses modeling concepts to capture information about business, data, and processes.


RAD - Drawbacks:

  • Accelerated development process must give quick responses to the user.
  • Risk of never achieving closure .
  • Hard to use with legacy systems.
  • Requires a system that can be modularized.
  • Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.


When To Use RAD:

  • Reasonably well-known requirements.
  • User involved throughout the life cycle.
  • Project can be time-boxed.
  • Functionality delivered in increments.
  • High performance not required.
  • Low technical risks.
  • System can be modularized.




IMPORTANT LINKS:




V-Model

It is a variant of Waterfall Model that emphasizes the verification and validation of the product. Testing of the product is planned in parallel with a corresponding development phase.


V-Model / V-Shaped Model
V-Model / V-Shaped Model



Project and Requirements Planning:– allocate resources.
Product Requirements and Specification Analysis:– complete specification of the software systems.
Architecture or High-Level Design:– defines how software functions fulfill the design.
Detailed Design – develop algorithms for each architectural component Production, operation and maintenance:– provide for enhancement and corrections.
System and acceptance testing:– check the entire software system in its environment.
Integration Testing:– check that modules  interconnect correctly.
Unit testing:– check that each module acts as expected.
Coding:– transform algorithms into software.

V-Model Strengths:

  • Emphasizes planning for verification and validation of the product in early stages of product development phase.
  • Each deliverable are easily testable.
  • Project management can track progress by milestones.
  • Easy to use.


V-Model / V-Shaped Model.
V-Model / V-Shaped Model.


V-Model Drawbacks:

  • Does not easily handle concurrent events.
  • Does not handle iterations or phases.
  • Does not easily handle dynamic changes in requirements.
  • Does not contain risk analysis activities.

When to use V-Model:

  • Excellent choice for systems requiring high reliability.
  • All requirements are known up-front.
  • When it can be modified to handle changing requirements beyond analysis phase .
  • Solution and technology are known.


IMPORTANT LINKS:


Topic: SDLC Model.


Next: |   RAD - Rapid Application Development Model   |   Incremental Model   |   Waterfall Model   |   Spiral Model   |   Agile SDLC Model   |


| Introduction to Software Testing | Roles and Responsibilities of a Software Tester | What is a Test Case | Software Testing types and Methods | STLC Process | Hierarchy Chart | Most Common Interview Questions | Resume Preparation Tips | SDLC Models | Blog Index | Software Testing FAQs |


Waterfall Model

Waterfall Model has 5 main stages:
1) Requirement Analysis
2) Design
3) Implementation
4) Verification or Testing and
5) Maintenance



Waterfall Model-SDLC
Waterfall Model.



Requirements: – defines needed information, function, behavior, performance and interfaces.

Design:defines data structures, software architecture, interface representations, algorithmic details.

Implementation:source code, database, user documentation.

Verification: - to test and detect bugs, defects, errors, & adherence to standard validations.

Maintenance: - to correct the found bugs and defects. Make final changes according to client requirements.

Advantages of Waterfall Model:
Waterfall Model is very easy to understand, and easy to use. It Provides structure to inexperienced staff. Milestones are well understood. Waterfall Model Sets requirements stability. And it is Good for management control. Most importantly waterfall Model Works well when quality is more important than cost or schedule.

Waterfall Model Drawbacks:
All requirements must be known upfront for the design phase to begin. Deliverance created for each phase are considered frozen – inhibits flexibility. It can give a false impression of progress. It Does not reflect problem-solving nature of software development – iterations of phases. Also, Integration is one big bang at the end. It has Little opportunity for customers to preview the system.

When to use the Waterfall Model:
Waterfall Model should be generally preferred when requirements are very well known, Product definition is stable, Technology is understood, New version of an existing product is being launched or if you are Porting an existing product to a new platform.


Wednesday, December 26, 2012

SDLC Models

Q) What is SDLC?

SDLC [sometimes termed as Systems Development Life-cycle] is an acronym for Software Development Life Cycle which follows a systematic process to unravel a software while following problem handling methodologies and analysis.

One should be familiar with SDLC models before getting into the world of software testing.

A process: defines “what” needs to be done and which roles are involved
A procedure: defines “how” to do the task and usually only applies to a single role


 Each process has a set of procedures to be followed. There are different kinds of SDLC methodologies and these methodologies cast the frameworks to control and plan the composition of an information system or the software development process.

SDLC Model
SDLC Model.

Different types of SDLC Models are:


SDLC-Model-Process.
SDLC-Agile Process.


    SDLC has 7 main stages:
    1) Preliminary Investigation
    2) Feasibility Study
    3) Analysis
    4) Design
    5) Coding
    6) Testing
    7) Maintenance & Review







Important Links:



Wednesday, December 12, 2012

Iterative Waterfall Model

  • Water Fall model has been revised later to be Iterative.
  • Everything remains the same as Waterfall Model.
  • It is easy to use.

Iterative Waterfall Model.
Iterative Waterfall Model



SDLC,iterative waterfall model,picture,image
Iterative Waterfall Model.
  • Each iteration involves Design Analysis and Implementation as well as verification of the current build/version of the system.
  • If the application lacks any requirements or has any problems then the phase will be looped back to previous iteration.
  • It supports redesign, acceptance and review of any new requirement.
  • It involves analysis of usability, achievement of goals, reliability, efficiency, and structure. 


iterative waterfall model,SDLC
Waterfall Model Iteration.


  • It has many draw backs - each process is iterative and has many problems to meet the project deadlines.


Important Links:




Friday, December 7, 2012

Test Case

Test Case: is a set of conditions or laws which a tester uses to determine the correct functioning of a module or application/software.

You may need more than one test case to validate the functional working of a module.

Writing test cases is essential to trace the test coverage. It helps in minimizing redundant test cases and increases speed of test cycle. It also assists developers in understanding the issues/defects/errors/glitches associated with the software and increases maintenance speed.

Test Cases and Test scenarios.



Sample Test Case for Login form and Logout button:

  1. Enter valid email-id and password and then click on submit button.
    • Should take you to successful Login page.
  2. Enter invalid email-id and invalid password and then click on submit button.
    • Should not log you in.
    • It should show validation messages. Ex: "Invalid username or password".
    • Fields having errors should not be highlighted as user should not know whether email-id is wrong or password is wrong. 
  3. Enter valid email-id and invalid password and then click on submit button.
    • Should not log you in.
    • It should show validation messages. Ex: "Invalid username or password".
    • Fields having errors should not be highlighted as user should not know whether email-id is wrong or password is wrong. 
  4. Enter invalid email-id and valid password and then click on submit button.
    • Should not log you in.
    • It should show validation messages. Ex: "Invalid username or password".
    • Fields having errors should not be highlighted as user should not know whether email-id is wrong or password is wrong. 
  5. Click on submit button leaving email and password fields null.
    • Should not log you in.
    • It should show validation messages. Ex: "Please enter your email address" and "Password can't be blank"
    • Now fields having errors should be highlighted [Usually red in color].
  6. Check if form fields and buttons are aligned properly.
    • Verify if buttons should be round cornered.
    • Verify if text fields border should be round cornered.
    • Check if asterix(*) and help texts are aligned properly.
    • Check if help text and text fields are aligned properly.
    • Check if loading gif image has to be loaded after clicking on submit button.
  7. Verify whether validations are handled properly.
    • Validation messages should be meaningful and relevant to error event.
  8. After logging in successfully, copy the url and place it in a different browser.
    • It should get routed to login page instead of keeping you logged in, as you have placed the url in different browser and session has not yet being created for that browser.
  9. Close browser tab after logging in successfully and open page again by placing the copied url.
    • Now closing the browser tab should not end the session unless you click on Logout button. So instead of showing login form again it should take you to page 2 - which is successful login page.
  10. After Logout click on browser back button.
    • Clicking on browser back button after Logging out should not take you to page 2. Instead it should get routed to login page since session has been destroyed after logout.




Wednesday, September 26, 2012

Roles & Responsibilities

Test Engineer's Roles and Responsibilities

Roles and responsibilities of a Software Test Engineer include:

1) Requirements Analysis from the client and suggestions.
2) Participating in preparing Test Plans.
3) Preparing Use Case document using functional specification document.
4) Preparing Test Scenarios based on Use Cases or wire-frames or functional specification document.
5) Preparing Test Cases for integration and system testing using test scenario documentation.
6) Preparing Test Data’s for the test cases.
7) Analyzing and executing the Test Cases prepared by other team members
8) Preparing Test Environment to execute the test cases.
9) Executing the Test Cases.
10) Defect Tracking.
11) Giving steps to reproduce - information of a defect to developers in order to fix it.
12) Preparing Summary Reports.
13) Preparing Lesson Learnt documents from the previous project testing experience.
14) Preparing Suggestions/Enhancement Documents to improve the quality of the application.
15) Communication with the Test Lead / Test Manager.
16) Conducting Review Meetings within the Team.


Roles and Responsibilities of a Software Tester

1) Preparing Bug Report and submit it to any tool(whichever is used by your organization).
2) Deciding the Severity and Priority of Bugs.
3) Preparing work done and when document.
4) Regularly search Internet for new testing Techniques and implement them.





Google Search