Saturday 7 December 2013

What is a Defect Life Cycle or a Bug lifecycle in software testing? 

Defect life cycle is a cycle which a defect goes through during its lifetime. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced. Defect life cycle is related to the bug found during testing.
The bug has different states in the Life Cycle. The Life cycle of the bug can be shown diagrammatically as follows:


  1. New:  When a defect is logged and posted for the first time. It’s state is given as new.
  2. Assigned:  After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as assigned.
  3. Open:  At  this state the developer has started analyzing and working on the defect fix.
  4. Fixed:  When developer makes necessary code changes and verifies the changes then he/she can make bug status as ‘Fixed’ and the bug is passed to testing team.
  5. Pending retest:  After fixing the defect the developer has given that particular code for retesting to the tester. Here the testing is pending on the testers end. Hence its status is pending retest.
  6. Retest:  At this stage the tester do the retesting of the changed code which developer has given to him to check whether the defect got fixed or not.
  7. Verified:  The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified”.
  8. Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. The bug goes through the life cycle once again.
  9. Closed:  Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.
  10. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate“.
  11. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.
  12. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software. 
  13. Not a bug:  The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the  application.

Agile Testing

What is Agile Testing? Advantages of Agile Methodology



Agile development recognizes that testing is not a separate phase, but an integral part of software development, along with coding. Agile teams use a "whole-team" approach to "baking quality in" to the softwssare product. Testers on agile teams lend their expertise in eliciting examples of desired behavior from customers, collaborating with the development team to turn those into executable specifications that guide coding. Testing and coding are done incrementally and iteratively, building up each feature until it provide

The conncept of "Time-To_Market" is the keyword in today's IT market that completer the software Vendors to come up with new strategies to save the time, resources, cut down the cost involved and at the same time, deliver reliable product that meets the user requirements.
In this case reasonably good amount of end-to-end testing is carried out and product could be acceptable with known issues/defects at the end of intermediate release. These defects are harmless the Application usability. .




As and when the Developer implements the code, the Testing team identifies if the application can be built using this code for a quick testing. This is to identify the defects at the early stage so that the developer can fix them in the next round on priority basis and continue with further development. This iteration continues until the end of the code implementation. Once the testing cycle starts, the Test team can now focus more on major test items such as Integration, Usability Testing and System Testing etc.

Agile Methodology Life Cycle
Good communication must exist among Automation testing team, developers, business analysts and stake holders. There must be highly collaborative interaction between client and the delivery teams. More client involvement implies more suggestions or changes from the client. It implies more bandwidth for communication. The key challenge is that the process should be able to capture and effectively implement all the changes and data integrity needs to be retained. In traditional testing, developers and testers are like oil and water, but in agile environment, the challenging task is that they both must work together to achieve the target.

Daily Scrum Meeting is one of the key activities in Agile Process. Teams do meet for 15 minutes stand up sessions. What is the effectiveness of these meetings? How far these meetings help Automation practice Developers?

The daily standup meeting or scrum meeting presents the team with a regular opportunity to synchronize development activities with the iteration plan and to check and reflect on the progress of the team’s commitments towards the iteration goal.

The daily scrum meeting is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant subgroup immediately after the meeting. During the daily scrum, each team member answers the following three questions:
  1. What did you do yesterday?
  2. What will you do today?
  3. Are there any impediments in your way?
By focusing on what each person accomplished yesterday and will accomplish today, the team gains an excellent understanding of what work has been done and what work remains. The daily scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.
If a programmer stands up and says, "Today, I will finish the data storage module," everyone knows that in tomorrow's meeting, he will say whether or not he finished. This has the wonderful effect of helping a team realize the significance of these commitments, and that their commitments are to one another, not to some far-off customer or salesman.

In cases where the ScrumMaster cannot remove these impediments directly himself (e.g., usually the more technical issues), he still takes responsibility for making sure someone on the team does quickly resolve the issue.
The vast majority of teams conduct the daily scrum meeting by having each person answer the three questions in order. You answer all three, then the next person, the next and so on. An interesting alternative that some teams find helpful is to talk through one product backlog item before moving on to the next. In this way, an individual may give an update at multiple different times during the same meeting.

sprint (software development)

In product development, a sprint is a set period of time during which specific work has to be completed and made ready for review.

Each sprint begins with a planning meeting. During the meeting, the product owner (the person requesting the work) and the development team agree upon exactly what work will be accomplished during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria needs to be met for the work to be approved and accepted.

The duration of a sprint is determined by the scrum master, the team's facilitator. Once the team reaches a consensus for how many days a sprint should last, all future sprints should be the same. Traditionally, a sprint lasts 30 days.

After a sprint begins, the product owner must step back and let the team do their work. During the sprint, the team holds daily stand up meeting to discuss progress and brainstorm solutions to challenges. The project owner may attend these meetings as an observer but is not allowed to participate unless it is to answer questions. (See pigs and chickens). The project owner may not make requests for changes during a sprint and only the scrum master or project manager has the power to interrupt or stop the sprint.
At the end of the sprint, the team presents its completed work to the project owner and the project owner uses the criteria established at the sprint planning meeting to either accept or reject the work.

Select Language