Question 6 of 8

Question 6 (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part (a) — OO equivalents of unit and integration testing. In an object-oriented system, the smallest meaningfully-testable unit is not usually a single method in isolation but the class (or cluster of tightly-collaborating classes), because a method's behaviour is entangled with the object's state (encapsulated attributes), inheritance, and polymorphism — testing a method with no regard for object state is often meaningless. So OO "unit" testing becomes class testing: testing all methods and attributes together, across the states an object can legitimately be in, including any inherited/overridden behaviour. OO "integration" testing becomes cluster testing (testing a small group of collaborating classes together) followed by use-based / thread-based testing, which integrates classes in the order their collaborations actually occur in a use case, rather than the top-down/bottom-up control-hierarchy order used for procedural code (there is no single "main" control module to integrate downward from in an OO design).

Part (b) — quality and usability. Usability is one of the quality characteristics that make up overall software quality (ISO/IEC 25010), alongside functionality, reliability, maintainability, efficiency and portability — so raising usability (clearer UI, better error recovery, lower learning curve) directly raises the software's measured quality, and conversely a functionally correct but hard-to-use system is, by the standard's own definition, LOWER quality even though it "works." The relationship also runs practically: poor usability drives real-world defect reports (users misusing a confusing interface and reporting the result as a "bug"), so improving usability reduces the field-defect rate that other quality metrics (such as customer-reported problems) measure.

Part (c) — HR management's effect on software quality. Human resource management affects software quality through several concrete channels:

• Staffing and skill match — assigning developers with the right domain/technical experience to a component reduces the defect rate that mismatched skill would otherwise introduce.
• Training — keeping the team current on the languages, tools, and quality practices (code review discipline, testing techniques) actually in use directly affects the defect rate and review effectiveness.
• Turnover and continuity — losing developers who hold undocumented tacit knowledge of a legacy module raises the risk of introduced defects when someone else must modify it, and onboarding time for replacements delays quality-critical work.
• Workload and morale — chronic overtime/understaffing is empirically linked to higher defect injection rates (fatigue, corners cut on reviews/tests) and to attrition, which compounds the turnover effect above.
• Team structure and incentives — how people are organized (e.g. cross-functional agile teams that own quality end-to-end vs. siloed groups that can blame each other) and how they are measured/rewarded (rewarding raw feature throughput over defect rate encourages corner-cutting) shape whether quality practices are actually followed under pressure, not just documented in the SQA plan (Q1a).