vault backup: 2025-01-10 14:34:48

.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",

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