Archive for the ‘Review’ 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.


Audit Vs Assessment

January 10, 2010 Leave a comment

Audit Vs Assessment

S.No Audit Assessment
1 To verify the conformance of an entity to a given standard. It consists in gathering evidence of conformance or nonconformance. Evaluates the efficiency and/or effectiveness of an entity and results in a measure of its performance with regard to the scope of the assessment.
2 Verification and inspection are synonyms of audit. Appraisal and evaluation are synonyms of assessment.
3 An audit might explicitly point at specific people or groups of people as the cause for noncompliance (attribution). An assessment does not evaluate individuals (non-attribution). Of course, the result of an assessment might still be used to infer responsibility for failure or low scores
4 Example of audit: Verify all the practices established in the organization is followed or not. Example of assessment: Evaluate the CMMI level of an entity.
5 An audit results in a success or a failure An assessment usually provides a score that does not express success or failure

Implementation of QMS (Part4)

October 3, 2009 Leave a comment

Learn From Others & Share Your Experiences

As it was trail or test ride, implement the same across the organization at full fledge, since the procedures / process is matured one now. For implementation of the procedures / process to the full fledge the existing team which is already had used, need to spend time to share their experience with others and help them to get learned.

Quality is a team work rather than individual one.

Types, Objectives & Techniques of Review

June 15, 2008 3 comments

Types, Objectives & Techniques

Process for Software Testing

June 5, 2008 1 comment

Process for Software Testing

Process of Software / System Design (Part 2)

Process of Software / System Design



  1. To describe design goals set.
  2. To define system architecture and detailed design of the system.

Process Requirement:


1. System Architecture:


Entry Criteria: Approved SRS



Ø     On approval of SRS from internally and externally the team which is involved with design activity start to prepare HLD (High Level Design).

Ø     The same as to be review and approved by Project Head / manager

Ø     Refer:


Record Retention: HLD


Exit Criteria: Approved HLD


2. Detailed Design Document:


Entry Criteria: Approved HLD



Ø     On approval of High Level Design, the team involve in the low level design start to prepare (LLD)

Ø     LLD involves web page design and Usability (Navigation)

Ø     The same as to be review and approved by Project Head / manager


Record Retention: LLD


Exit Criteria: Approved LLD


3. Validation


Entry Criteria: HLD & LLD



Ø     Conducting informal reviews and walkthroughs or inspections of the detailed software and data base designs.

Ø     The Critical Design Review (CDR) that completes the software detailed design phase.


Record Retention: HLD & LLD


Exit Criteria: Approved HLD & LLD


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.