Sunday, May 4, 2008

Key Integration Issues in SDLC

What modules should be assembled and tested as a group?
  • Functional subassemblies
  • Top level grouping working down
  • Bottom level groupings work up
  • Crtical feature first


How much scaffolding cde or test support code is required?


How much testing is appropriate?

  • Subassembly
  • Interfaces only
  • All invoking functions and features
  • Stress and break conditions


How will problems be isolated?

Thursday, May 1, 2008

Integration Test Criteria

Integration Test Criteria includes:
  • Compliance with Sub-Assumbly Functional Requirements
  • Assessment of Timing, Sizing and Accuracy
  • Performance at Boundaries and Under Stress
  • Measurement of Functional Test Coverage
  • Measurement of Software Reliability

Objective of Integration Testing

The objective of Integration Test is to ensure that various system parts of related components and programs work properly together.

It includes:
  • Integrates Components.
  • Components with Components Tests
  • Hardware Interfaces Tests
  • External Software Interfaces Tests
  • Functional Requirements Tests
  • Sub-Assembly Tests

Program Debugging

There are 3 different approaches to debugging and they includes:

  • Induction Approach
  • Deduction Approach
  • Intuition Approach

Friday, March 7, 2008

Difficulties in Program Walkthrough

As testing should be done by someone else, some difficulties of a Program Walkthrough includes:
  • cannot depend on human eyes
  • Programmers would be reluctant
  • difficulties in inviting external party
  • resources

Structural Testing in SDLC

Continuing on the Structural Testing:

  • More powerful form of test is Path Coverage
  • This strategy ensures that all statements in the program are executed at least once and conditional statements are tested for both true and false cases
  • The starting point is to derive a program flow graph
  • A flow graph consists of nodes representing decisions and edges showing flow of control
  • Tester must not be seduced into thinking that such testing is adequate
  • Cyclomatic complexity is a measure of the program's control complexity. The data complexity is not taken into account
  • Program fragments which are equivalent in function may not have the same cyclomatic complexities
  • It is generally true that the # of paths through a program is proportional to its size. Thus, as modules are integrated into systems, it is unfeasible to use structural testing techniques.

Friday, February 22, 2008

What is Structural Testing

Structural Testing includes:
  • Cover structure, quality and style.

  • Implementation based.

  • Best done by programmer.

  • Not aiming at testing functions or detecting missing functions.

  • The tester analyses the code and use knowledge about the structure of a component to derive the test data.

  • Simplest form of testing includes:
    - Statement coverage
    - Branch coverage

Cause-effect Analysis

Another analysis you should consider in Functional Testing is Cause-effect Analysis. This includes:
  • Even when a program operates successfully for individual test inputs, combinations of these inputs may detect program errors.

  • Involves examining the output and analysing to see if combinations of input partitions always cause outputs in the same output partition to be producted.

  • The causes of these effects used as test cases.

Boundary Value Analysis

In Functional Testing, one of the consideration is Boundary Value Analysis. This includes:

  • Input conditions are 'edges' of equivalence class.

  • Values like above and below range, minimum and maximum number and up to the array limit.

Saturday, January 12, 2008

What is Equivanlence Testing

Equivalence Testing is:
  • Input conditions are partitioned into Equivalence Classes.

  • Classes like specific numeric value, range of values and set of related values.



Example:

A database state that the product must be able to handle any no of records from 0 to 100,000.

Art of Testing in SDLC

Art of testing is to set up a small, manageable set of test cases in such a way as to maximize the chances of detecting a fault while minimizing the chances of wasting a test case by having the same fault detected by more than one test case.

The technique use is Equivalence Testing + Boundary Vaule Analysis + Cost Effect Analysis

Monday, January 7, 2008

Functional Testing - SDLC

What is Functional Testing?

  • It is function oriented.

  • Test cases prepared by looking at logic from outside just as though it was a black box.

  • Concentration on the verification process.


So what should be considered in this functional testing black box?

  • Under waht conditions would we not perform the test?

  • What should we know and need to know about the input and output?

  • What can we state about our assumptions and expectations?

  • How much must we know about the intended use of the system?

  • How important are the various attributes and how much can we trade one off again another?

  • What is the one factor against wich all others can be judged?

Module Testing

For testing, there are 2 ways of systematically contructing test data to test a module. These include:

  • Functional Test
    To test according to the specification.

  • Structural Test
    Testing on the code.

Structured Walkthough Tips

When conducting Structured Walkthough, I have the following tips:
  • Make sure that the team is ready.

  • Record preparation time and issues ready to be raised.

  • Take notes.

  • Summarize the work done page by page.

  • Record assumptions, questions and dissent.

  • Record minority views.

  • Record quality issues and their conflict with standards.

  • Take care over sudden agreement over correctness.

  • Summarize total effort.

  • Make sure that the team does not get bogged down in discussions or correction activities.

  • Focus on internal and external interfaces.

  • Make sure to review the final product instead of the person.

Saturday, January 5, 2008

Conducting Structure Walkthrough in SDLC

Structure Walkthrough can be conducted:
  • at any point in time during SDLC.

  • to review users requirements in the feasibility study stage or the external design stage, system design during the internal design stage or source coding duirng the development stage.


What is Structured Walkthrough

Structured Walkthrough is:

  • a tool for analysing the design of a system to ensure it addresses all requirements.

  • a mean of ensuring conformity to standard.

  • a mean to make reviewees more conscious of the way the product looks.

  • used as a learning experience for the team.

Prototyping in SDLC

A prototype is:
  • a demonstration system.

  • a partially or fully working system waiting for idea testing and modification to meet requirements.

  • an intermediate state that exhibits the essential features of a later generation.

  • technique for clarifying user requirements (especially on user interface).

  • can also verify the feasibility of a design.

Friday, January 4, 2008

Overview on External and Internal Design

External Design

In this phase, the full details of the system functions, screen and report formats, external interfaces, security and audit controls, operational procedures, recovery and contingency procedures and reponse times are defined.

Internal Design

This phase is concerned with the internal details of the system such as databases/files, records and programs. For each program it defines the functions it performs, the files accessed and the input and/or outputs processed.

Overview of SDLC

System Development Life Cycle (SDLC) sets out the steps to be performed when developing systems, the work to be done in each step and the deliverables to be produced. It applies to all types of system development projects. By following SDLC, it ensures planning the project at the beginning and monitoring it along the way so that the schedule is met and the final system meets the requirements.

SDLC comprises a number of consecutive phases:

  1. Initial Request
  2. Feasibility Study
  3. External Design
  4. Internal Design
  5. Programming
  6. System Test
  7. Acceptance Test
  8. Implementation
  9. Post Implementation