Archive

Archive for the ‘Testing’ Category

How SCRUM Methodology is different from the traditional methodology?

September 2, 2010 3 comments

This is most frequent question we hear in the arena of SEPG. Will try to address it in the forum to the best and appreciate the viewer’s response.

As part of the engineering position SCRUM is no different from normal traditional methodology of SDLC (Iterative method), but the way the project management is implemented in the SCRUM is interesting and appreciable.

In the traditional methodology the managerial position is done by managers, whereas is in SCRUM it is responsibility of SCRUM team to do that. For example in traditional, estimation is done by head or manager where as in SCRUM it is done by team in conjunction with product owner and SCRUM Master during the SPRINT Planning Meeting.

Assumptions, Constraints and dependencies (ACD) are documented by manager but the implementation rate is very low, whereas it is plugged or enable in the SCRUM through the channel of Daily standup meeting.

Communication Plan / Escalation plan is documented in the traditional methodology but the usage of the same is minimal whereas it is implemented effectively through daily standup meeting here in SCRUM.

Sprint Review meeting is the channel through which the acceptance criteria for the product is met in the SCRUM methodology. Also it’s the responsibility of the SCRUM team to demonstrate the product to the product owner and prove that things are done according to the definition of Done (DOD). We mean to say SCRUM team defines the boundary of acceptance criteria during the Sprint Planning, whereas in the traditional methodology no where the team which is going to develop the product involved to define the criteria for acceptance.

Changes during the SCRUM are not allowed is the Thumb rule in SCRUM.

Configuration Management should be take care during the Zero sprinting or during the Sprint Planning a line item, need to be addressed.

Lessons learned during the project are not documented in formal or informal manner in the traditional whereas here it is reported through retrospective meeting in SCRUM.

Implementation of the Risk Management in the SCRUM will post later.

Advertisements

Process for Software Testing

June 5, 2008 1 comment

Process for Software Testing

Retest Vs Regression Testing

April 22, 2008 2 comments

Sl.No

Retest

Regression Testing

1

Retest is the process of checking whether the reported bugs are been fixed or not by the development team

 

Regression Testing: Testing conducted for the purpose of evaluating whether or not a change to the system (all CM items) has introduced a new failure

 

2

Purpose: To identify whether the given bugs /issues/ defects are fixed or not.

Purpose: To identify whether on fixation of the issues / bugs / defects new issues get introduced into the system.

3

To carry out the retest activity the issue report given by testing team with developer comments is enough. (I.e. Whether the issue is fixed or not commented by the developer against the developer comments column)

To carry out the regression testing, issue report along with that the requirements tracability matrix need to be given.

Static Testing Vs Dynamic Testing

April 21, 2008 21 comments

Sl.No

Static Testing

Dynamic Testing

1

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.

2

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

3

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.

4

This is the verification portion of Verification and Validation

Dynamic testing is the validation portion of Verification and Validation.

 

5

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.

 

Testing Type Vs Testing Techniques

April 20, 2008 1 comment

Sl.No

Testing Type

Testing Techniques

1

Testing types deal with what aspect of the computer software would be tested.

Testing techniques deal with how a specific part of the software would be tested.

2

Testing types mean whether we are testing the function or the structure of the software. In other words, we may test each function of the software to see if it is operational or we may test the internal components of the software to check if its internal workings are according to specification.

 

Testing technique’ means what methods or ways would be applied or calculations would be done to test a particular feature of a software

3

Ex: Black Box and white box

Ex: Boundary Value Analysis, Equivalence Partitioning Method, Error Guessing, State transition Method, Path Testing, Condition Coverage, Decision Coverage, Statement Coverage and etc.

Suspension Criteria Vs Resumption Requirements

April 19, 2008 2 comments

Sl.No

Suspension Criteria

Resumption Requirements

1

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.

 

2

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.

3

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”.

4

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

Scenario:

 

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.

 

Summary:

  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.