by Testing :
- It is considered a good agile development practice to think through requirements before writing functional code. It helps to consider work in terms of how it will be tested, but it also creates and improves traceability and eliminates other wasteful activities that are traditionally part of upfront requirements specification processes. The ability to deliver shippable software by the end of every Sprint requires different testing strategies, where testing activities are to be done as part of development.
Bug :
- A software bug is an error, flaw, failure, or fault that produces an incorrect or unexpected result.
Bugs fixing practices :
- When you find a bug that has already been delivered to the market, at first estimate the amount of work needs to fix it. If it is small do it in the current Sprint and just inform the Product Owner. However, if it is not small, ask the Product Owner to put it on the Product Backlog.
- Unless your company has specific guidance on fixing bugs, they represent work to be done and should be ordered on the Product Backlog by the Product Owner.
- If a Developer is unsure of what to do with a bug, he / she should talk to the Product Owner.
- A bug should be resolved right away if:
1) if the work to fix the bug is less than the work to actually file it.
2) if the bug is so critical that it would be negligent to leave it unfixed - If bugs occur (which they certainly do), the person finding the bug should be able to report (document & send) the bug to people in charge of fixing that error or failure.
- While changing software, you find a bug in a previously delivered piece of functionality. What should you do?
1. Fix the bug if it is critical or easily fixed. Otherwise, put the new bug into the Product Backlog to be prioritized and fixed in an upcoming Sprint. - Bugs discovered in Sprint should be fixed immediately
- The person who have done the bug fix it, or whoever the Developers agree should fix it.
Bug Report :
- A bug report “should explain how exactly the product is broken.”
Good Bug report :
- There are several attributes that a good bug report could have such as evidence as screenshots or other attachments, expected results and observed results, version and build of the software under test, having simple and repeatable reproduction steps, having summary and detail description, the date and time that the defect occurred or reported, reported by, impacted related requirement, the severity of the defect, etc.
- There Key essential for every bug report are:
A. The Problem Description.
B. Steps to reproduce.
C. Expected outcome.
D. Actual outcome.
Screenshots and Versions are good to have but not mandatory.
A Good Bug Report:
- A good bug report contains one Bug Per Report
- A good bug report contains the information needed to reproduce and fix problems
- A good bug report contains clear title and proper grammar in the report,
- A good bug report is an efficient form of communication for both bug reporter and bug receiver.
- A good bug report contains expected vs actual results. These are mandatory.
A bug report may contain version of the plugin/platform, or Screenshot(s) of the problem and Logs but there are not mandatory. A good report should not assign Blame.
Bad Bug report :
- There are several attributes that a bad bug report can have such as vague statements or untested assumptions, assigning blame, with no screenshots or other attachments, with no expected results and observed results, with no version and build of the software under test, having no simple and repeatable reproduction steps, generic titles, with no date and time that the defect occurred or reported, with no reporter name, etc.
- Bad Bug Report has the following Attributes:
1. A bad bug report does not contain the information needed to reproduce and fix problems
2. A bad bug report is a lengthy, inefficient form of communication for everyone involved.
3. A bad bug report has generic titles
4. A bad bug report assigns Vague statements or untested assumptions.
5. A bad bug report assigns blames.
Debt :
- Bugs create Debt
- Incremental Debt : Caused by repeating the above without any work to reduce the debt
- Inadvertent debt: This is typically caused by a lack of awareness or knowledge
- Strategic Debt : Debt caused to gain strategic benefits (such as time to market)
- Tactical debt: Short-time gains, for instance cutting some corners to make an extra release for increased customer satisfaction
- Technical Debt : A Technical debt represents results which are a consequence of poor technical choices.
Technical Debt :
- Technical Debt comes from making bad technical decisions and is the eventual consequences of poor technical choices. The Team should pay it back continuously. If the Team does not pay back, it will decrease the development speed over time. Although its measurement is hard its growth would lead to wrong assumptions about Increments delivery and even might prevent creating the releasable product.
- Technical debt types are as following:
• Implementation debt: bad coding
• Architecture debt: Bad architectural principles, design rule violations, lacking design patterns
• Test debt: Missing test cases, lack of test coverage, lack of test automation
• Documentation debt: Missing documentation, poorly updated documentation, low traceability between documentation and implementation
unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership. - A Technical debt reduces Transparency.
- It misleads the Product Owners, Scrum Masters and even the developers with their assumptions about the “Current state” of the System. For example, if Product Backlog item A is assumed to be completed in a day, it might take three days for it to complete, because of unseen bad code or Technical Debt.
- The Product becomes more unstable, as more functionality / features added over bad code (or existing technical debt). For example, suppose that the team decided to delay some important refactoring to facilitate an early release. Technical debt starts to accrue at that point, and it may not map cleanly to specific items on the Product Backlog. It is far more likely to impact components which cross-cut a range of features. Moreover, if the necessary refactoring is significant it could impact the entire product, and it could affect features in uneven ways.
- Technical debt comes from making bad technical decisions and is the eventual consequences of poor technical choices. The Team should pay back it continuously. If the Team does not pay back, it will decrease the development speed over time. Although its measurement is hard its growth would lead to wrong assumptions about Increments delivery and even might prevent creating a releasable product. On the other hand, each Sprint purpose is creating at least one releasable business functionality. So stopping it to pay the technical debt back is not a proper policy.
Documentation :
- Development Team is responsible for doing all the required tasks to create a potentially releasable Increment. Documentation same as other tasks is a part of the development. Therefore, each developer who has sufficient documentation skills can create the required documentation. In addition, postponing some tasks to the future for example right before a release increases risks and prevents creating done Increment in order to gather feedback from the market. Also, the accountability of doing all tasks belongs to the Development Team as a whole not just one person, like a document writer.
- The Development Team as a cross-functional team is responsible for documentation like other tasks to create a releasable Increment.
- If a Scrum Team decides to have the documentation in its development process, they can add it to the Definition of Done. Then they should adhere to it for each developed feature. Also, having enough documentation can help the team to have easier software maintenance.
More informations for the Scrum PSD certification here.
