Posts Tagged ‘Testing’

Compliance Test Vs Substantive Test

June 3, 2013 Leave a comment


Compliance Testing

Substantive Testing


Determines controls are being applied that complies with management policies and procedures.

Determines the integrity of actual processing.


Ex: Assess rights, Program Change control procedures and etc.

Ex: Complex calculations and etc


Static Testing Vs Dynamic Testing

April 21, 2008 21 comments


Static Testing

Dynamic Testing


Static testing is a form of software testing where the software isn’t actually used.

In dynamic testing the software must actually be compiled and run.


It is generally not detailed testing, but checks mainly for the sanity of the code, algorithm, or document. It is primarily syntax checking of the code or and manually reading of the code or document to find errors

Dynamic analysis refers to the examination of the physical response from the system to variables that are not constant and change with time


This type of testing can be used by the developer who wrote the code, in isolation. Code reviews, inspections and walkthroughs are also used.


Some of dynamic testing methodologies include unit testing, integration testing, system testing and acceptance testing.


This is the verification portion of Verification and Validation

Dynamic testing is the validation portion of Verification and Validation.



These are verification activites. Code Reviews, inspection and walkthroughs are few of the static testing methodologies.

These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.


Suspension Criteria Vs Resumption Requirements

April 19, 2008 2 comments


Suspension Criteria

Resumption Requirements


For a given input, if the parallel program gives output that is not identical to the output of the sequential program testing will be suspended. If any of the functionalities described in the SRS do not work, testing will be suspended.


Testing will be resumed if the parallel program outputs identical files as the sequential program and has the functionalities described in the SRS.



From the point 1 it’s clear that the expected result is not equal to the actual result so which is tracked as issue/ bug/ defect and report to the development team

On receive of an issue / bug / defect from the testing teaming the development team as to fix the same and release to the testing team.


The Quality document used by the testing team to release is “Test Release”

The Quality document used by the development team to release is “ Development Release”.


This is also known as “Test stop Criteria”

Resumption criteria / requirements are restart criteria for the testing activity.

Not A Bug

April 18, 2008 Leave a comment



An application is released to the testing team. The team has accepted, tested and released to the development team.


On bug fixation the development team came to know that one or more bugs reported by the testing team is unable to reproduce in the development environment and they stated the same in the retest report as “Not a bug” in the developer comments.


Now the testing team tries to reproduce the same but failed to do so. Now who is responsible for this? Well will be the team lead of the testing team or the test member who did the test?


Both will be responsible for this, since


  1. It’s the team lead who has to review the bug list before he/she releases the same to development team. If he/ she did the review then this situation may not rise or they can strongly argue with the development team that they had given proper steps to reproduce, the same can be reproduce and shown to the developer.
  2. Also the tester who had given the test release has to make sure that whether every bug he/she is reporting is able to reproduce at any point of time. He/ she had to check /review the same with the scenario’s or steps they had record more than once before they release.


To avoid such situations:

  1. Use review techniques before you release to the development team
  2. Have regular discussion with the team regards the functionality and testing activities
  3. Conduct training sessions to the team in the areas/ domain where they lag.



  1. It’s a point to be noted down that the testing team is unable to reproduce a bug given by the development team as “ Not a bug” in their retest release.
  2. Usage of the review techniques in the testing activity is poor.


Verification Vs Validation

April 7, 2008 4 comments





The Process of determining whether or not the Product of the given phase in the life cycle fulfill the set of established requirement

The Process of evaluating a system or component during or at the end of the development life cycle, to determine whether it satisfies the specified requirement.


It answers the question, “ Are we building the system right ”

It answer the question “Did we build the right system”

It answer the question “Did we build the right system”


Ex: Review (Include Inspection and Walkthrough)

Ex: Testing