D781 Software Quality Assurance and Deployment is banner number ITSW 5104 and four competency units in the School of Technology, the heaviest course in the graduate software engineering sequence. The catalog describes it as equipping students to ensure high-quality software development and effective deployment practices, joining two subjects that are usually taught apart. That join is the point: quality that stops at the door of production is not quality, and a release process without quality gates is a way of shipping defects faster.
Quality that continues past the release
Treating deployment as part of quality changes what a quality plan contains. It is no longer a test strategy ending at a sign-off. It becomes a chain of gates from commit through to production, each with an entry condition, an automated or human check, and a defined outcome when the check fails. The graded competency is designing that chain for a stated context rather than describing testing in general.
The test pyramid is the shape most of these chains take, and stating why matters at graduate level. Many fast unit tests, fewer integration tests, a small number of end-to-end tests. The reason is cost and signal: a failing unit test names the defect, a failing end-to-end test says something somewhere broke, and slow flaky tests at the top erode trust in the whole suite. A plan that inverts the pyramid produces a pipeline nobody believes.
Deployment strategy is the second half and it is a risk conversation. Recreate, rolling, blue and green, and canary each trade downtime, resource cost and blast radius differently, and each depends on properties of the application, such as whether two versions can run at once against one schema. That last question is where student plans usually break down, because database changes are the part of a deployment that cannot simply be rolled back.
What happens after release completes the subject. Monitoring that would detect the failure this release could cause, a defined rollback with a trigger condition somebody is authorized to pull, and a feedback path from production defects back into the test suite so the same defect cannot escape twice.
Turning scored aspects into gates and a word budget
Aspects are judged individually and each needs a 2 to pass. In a four unit graduate course the aspect list is long, so map each row onto a gate, a strategy decision or a measurement, and keep the map visible while you draft.
Budget it out. Suppose thirteen scored aspects and a document of about 2,300 words alongside a pipeline diagram and a test plan. Thirteen into 2,300 is 177 each. Sort them. Five are artifact aspects where a table or the diagram answers, needing 110 each of framing, which is 550 and releases about 330. Two ask you to justify the testing strategy and its distribution, at 300 each, or 600. Two ask about deployment strategy and rollback, at 300 each, or 600. Two ask about metrics, criteria or monitoring, at 220 each, or 440. Two are shorter context and conclusion sections at 60 each, or 120. That totals 550 plus 600 plus 600 plus 440 plus 120, which is 2,310, on target, with the four strategy sections carrying just over half the prose.
Draw the pipeline before writing. Stages left to right, the check at each stage, the condition that stops the line, and who is notified. Most of the document then explains a picture that already contains the decisions.
Working the D781 deliverable?
Send the aspects and the delivery context. You get a gate chain, a deployment strategy with its rollback condition, and a model plan.
A gate chain from commit to production
| Stage | Gate | Fails when | Consequence |
|---|---|---|---|
| Commit | Build, static analysis, unit tests | Any test fails or analysis exceeds a threshold | The commit is rejected and the author is notified immediately |
| Integration | Component tests against real dependencies | A contract between components is broken | The pipeline stops before any environment is touched |
| Artifact | One versioned build produced and stored | The artifact cannot be reproduced from the commit | Promotion is blocked, since environments must share one artifact |
| Test environment | End-to-end journeys, migrations applied | A journey fails or a migration cannot roll forward | Deployment stops and the migration is redesigned |
| Non-functional | Performance and security checks against thresholds | A stated threshold is exceeded | Release is held pending a decision with a named owner |
| Production release | Progressive exposure with monitored signals | Error rate or latency crosses the rollback trigger | Automatic rollback or halt, decided in advance |
| After release | Monitoring and defect feedback | A defect escapes to users | A test is added at the lowest level that would have caught it |
The consequence column is what makes these gates rather than checkpoints. A check with no consequence is a report, and reports do not stop defects.
Metrics that inform decisions, and what to cite
Graduate quality work is expected to measure, and the discipline is attaching a decision to every metric. Coverage without a target and a policy is a number. Escaped defect counts, lead time from commit to production, deployment frequency, change failure rate and time to restore are all measurements that tell you something actionable, and each should appear with the decision a bad reading would trigger.
Be honest about coverage in particular. High line coverage with weak assertions measures execution, not verification, and saying so in your document demonstrates the judgment the aspects are looking for. A smaller number of meaningful tests beats a large number of tests that assert nothing.
For sources, published standards for testing and quality models, established texts on continuous delivery and release engineering, and peer reviewed work on defect prevention are the strong citations, in APA where your program requires it. Tool documentation is authoritative for what a tool does and is not evidence that a practice works. Where your scenario supplies constraints, such as a regulated environment or a fixed release window, quote them when justifying a gate so the design is visibly derived from the case.
What passes, and what returns
Work at WGU is Competent or Not Competent, and revision after a return costs no marks. In a six month flat rate term it costs days, and in a four unit graduate course those are days the rest of your term needed.
Plans that clear are specific to their context. They name the release cadence the organization can support, they choose a deployment strategy the application's data layer actually permits, and they define rollback with a trigger and an owner rather than as a possibility. Their test distribution is argued rather than assumed. Their gates each have a consequence.
Returns come from plans that would fit any organization. Testing types listed with definitions, a pipeline diagram with no failure conditions, a deployment strategy chosen without reference to whether two versions can coexist, and metrics presented as a dashboard with no decision attached to any reading.
Seven mistakes that cost D781 students time
- Ignoring database changes. Schema migration is the part of a release that resists rollback, and a strategy that assumes it can be reversed is unsound.
- Inverting the test pyramid. Slow end-to-end suites at the base produce a pipeline people bypass, which removes every gate at once.
- Coverage as the quality target. Coverage measures execution. Say what your tests assert and why those assertions matter.
- Rollback as an intention. Without a trigger condition, a named owner and a tested procedure, rollback is a hope rather than a control.
- Rebuilding per environment. One artifact promoted through environments is the property that makes testing meaningful. Rebuilding breaks it silently.
- No feedback loop. A defect that reaches users and does not produce a new test will reach users again.
- Leaving flaky tests in the suite. A test that fails intermittently teaches the team to rerun rather than to investigate, and once rerunning is normal every gate downstream of it has stopped working.
How we work on this course
D781 support is chain design. Send the scored aspects and the delivery context and you get a gate chain with entry conditions and consequences, a test distribution argued from cost and signal, a deployment strategy checked against your data layer, a rollback definition with a trigger, a metric set with decisions attached, and a model document in the register WGU graduate evaluators expect. Where your course includes an objective assessment, our help is preparation only, and objective assessments are proctored: we never sit or assist during one and never ask for or use portal credentials.
Four units at graduate level is the largest single block in this sequence. Planning the chain before drafting is the difference between one term and two.
Three questions D781 students ask
Is D781 the same course as ITSW 5104?
How does D781 differ from the undergraduate quality course?
Do I need to build a working pipeline?
Where D781 sits in WGU's programs
The July 2026 catalog places this code in 4 current WGU programs. Open a program page for the complete standard path and term positions. The live Degree Plan remains authoritative after transfer credit, substitutions, and mentor planning.
The assessments, one by one
The public catalog does not publish this course's PA/OA identity or task count. WGU Tutors publishes at most one PA manual per course and only from a WGU-controlled public rubric. Until that source exists, PA help begins from the student's real Course of Study and OA support remains preparation only.