From ab41e06b077e34adb8fdea9f1ac9b16b14077b6c Mon Sep 17 00:00:00 2001 From: Claudio Fritsche Date: Fri, 10 Jan 2025 14:34:48 +0100 Subject: [PATCH] vault backup: 2025-01-10 14:34:48 --- .obsidian/workspace.json | 8 +-- ...oject Survival Guide by Steve McConnell.md | 60 ++++++++++++++++++- 2 files changed, 63 insertions(+), 5 deletions(-) diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json index 6700c2a..e812e69 100644 --- a/.obsidian/workspace.json +++ b/.obsidian/workspace.json @@ -588,12 +588,12 @@ } ] }, - "active": "14ca2a444b59a660", + "active": "c913626684654e11", "lastOpenFiles": [ - "5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md", - "0 Journal/Meetings/Hasan Update - 10.1.25.md", - "0 Journal/Meetings/Vidit Update - 8.1.25.md", "2 Personal/Hobbies/Gelbes Velo von Mänu.md", + "0 Journal/Meetings/Hasan Update - 10.1.25.md", + "5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md", + "0 Journal/Meetings/Vidit Update - 8.1.25.md", "0 Journal/0 Daily/2024-05-04.md", "0 Journal/Meetings/OneSec Cofounder Verhandlung.md", "Temporary/Startup Organisation.md", diff --git a/5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md b/5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md index 8489720..e09d8d4 100644 --- a/5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md +++ b/5 Media/0 Books/Software Project Survival Guide by Steve McConnell.md @@ -513,9 +513,65 @@ Tracking where team members spend their time will help with future planning. ### Quality Assurance QA matters because it makes development easier and cheaper. If mistakes and defects are detected upstream they are 50-200 times cheaper, which is why a good quality assurance system pays out. +Quality is important because the software usually acts as a foundation for business decisions, more software and usually lives longer than you might expect. +> [!Quote] Quick and Dirty +> The problem with quick and dirty, as some people have said, is that dirty remains long after quick has been forgotten. +#### Quality Assurance Plan +This document writes down commitments to quality assurance onto paper: +- Software quality assurance activities must be planned +- The plan for quality assurance must be committed to writing +- Quality assurance must beginn in requirements phase or earlier +- Development and quality assurance of the same elements cannot be performed by the same person. +- Train team members in how to perform quality assurance activities. +- Provide adequate funding for quality assurance activities +Typical Quality assurance activities are: +- **defect tracking**: keep record of each defect found, its source, when it was found, when it was resolved, how it was resolved (fixed or not) +- **unit testing**: unit refers to subroutine, module, class or even larger programming entity. This is done by developers, or on the git cloud provider automatically +- **source-code tracing**: interactive debugging line by line. done by developer. +- **technical reviews**: reviews are performed by peers. check all technical work products. Done by developers, QA-team just ensures that they are being held. +- **integration testing**: test new code together with existing code / codebase. Done by developer +- **system testing**: Test the entire system for the purpose of finding defects. Performed by independent test organization / test engineer + +##### Defect Tracking +- document each individual defect +- keep statistics: \# open defects, average time requiered to correct a defect, percentage of defects resolved. +- track only defects that have been comitted. Beforehand you should just fix them (put them into your personal todos.) +- Put defect reports under change control and make it public: automatically in jira / gitlab issues +- create a defect report template + +##### Technical Reviews +This is an activity that assures quality upstream in the process. +- can be: walkthroughs, inspections, code reading +- time to talk about code: + - juniors can learn from seniors and seniors can fix problems in juniors code + - challenge old ways of doing things + +Review pattern: +1. **Notification and distribution**: developer informs reviewer that code is ready for review and shares material for review +2. **Preparation**: Review happens, aided by checklist of common errors +3. **Review Meeting**: talk about the review +4. **Review Report**: log statistics of review: amount of defects, time spent for review, meeting, etc, pass or fail +5. **Follow-up**: Fix the problems and review again until product passes the review. + +Suggestions +- focus on defect detection, do not try to create solutions +- start reviews early in the project +- keep technical reviews technical and be honest about defects +- keep track of what material has been reviewed +- record the defects during reviews and list them in the report +- Verify that defects found during review are actually fixed (in the follow-up) +- make review results public to the project team +- schedule time for reviews and errorfixing of found defects + +##### System Testing +This is an activity that assures quality downstream in the process, compared to technical reviews. +Usually developers cannot wear both the developers' hat as well as the tester's hat: have different people do this. + +- Start system testing as soon as you have the first executable software +- Use a requirements traceability matrix to ensure all requirements are covered. --- ## Steps towards the Software release @@ -534,7 +590,9 @@ QA matters because it makes development easier and cheaper. If mistakes and defe - publicizing of plans and progress - time accounting - once finished sign off by project manager, dev team and Q&A team, then place under change control - +- Quality Assurance Plan + - defect report template to be used to report defects (see page 130) + - review checklists for different parts ## Tool list - Anonymous risk-reporting channel