MSQE Framework Assessment Workshop

Metadata

Purpose

Practise applying the MSQE Educational Framework to prioritise quality improvement in a realistic delivery context. The workshop develops structured discussion and evidence-based prioritisation; it does not score organisational maturity or certify a team.

QE Capability Developed

Cross-domain quality assessment, systems-risk analysis, evidence-gap identification, facilitation, and improvement planning.

Prerequisites

• Read Chapter 9 and review the Modern Software Quality Engineering Framework.
• Use a group with diverse delivery perspectives where possible, or complete the activity individually and record missing perspectives.

Scenario

The following is an illustrative scenario.

Harbour Learning operates an online professional-learning service. During enrolment peaks, some learners experience slow page loads and occasional failed payment confirmations. Support reports that users sometimes see a confirmation email before the learning entitlement is visible. The team has a large UI regression suite, but it cannot explain failures that occur only with delayed payment-provider events. The service has technical error logs but no clear signal for completed enrolment. Leadership must decide whether to invest first in more UI automation, data reconciliation, delivery controls, observability, or performance work.

Important Boundary

The MSQE Educational Framework is an original teaching model. Use it to structure questions and identify connections among capability areas. Do not assign a numeric score, maturity level, certification label, or universal organisation rating.

Instructions

1. Establish the outcome and risk context

2. Assess the ten framework domains qualitatively

For each domain, identify evidence, an uncertainty or risk, a systemic dependency, and one possible improvement. Do not turn the table into a scorecard.

3. Examine cross-cutting concerns

4. Produce a Quality Engineering Improvement Plan

Select no more than three improvements for the next planning period.

5. State deliberate non-priorities

Expected Outputs

• a ten-domain evidence and risk assessment;
• identified cross-cutting dependencies;
• a three-item Quality Engineering Improvement Plan; and
• explicit non-priorities with reconsideration triggers.

Portfolio Relevance

Portfolio Candidate: The completed fictional workshop output can demonstrate framework application, prioritisation, and facilitation. For a real organisation, use only safe, anonymised information and avoid publishing customer, incident, architecture, security, or investment details.

Reflection Questions

1. Which domain changed the initial preference for more UI automation?
2. Which risk cannot be reduced without collaboration across domain or team boundaries?
3. Which available measure risks recording activity rather than a customer outcome?
4. What evidence would make you revisit a deliberate non-priority?

Completion Criteria

• All ten framework domains are considered without assigning numeric scores.
• Cross-cutting concerns alter at least one proposed improvement.
• The plan contains no more than three prioritised actions.
• Each priority has evidence of progress and a review point.
• At least one non-priority and its reconsideration trigger are explicit.