D480 Software Design and Quality Assurance is banner number ITSW 3151 and three competency units in the School of Technology. The catalog describes it as applying a quality assurance focus to every phase of the software development life cycle, covering quality analysis, planning and testing strategies. The phrase every phase is the load bearing one, because the course argues that quality is decided long before testing begins. Note a catalog oddity while you are searching: ITSW 3151 is printed for both this course and D280 JavaScript Programming, so use the D code on your degree plan.
Quality is decided before anything is tested
The idea the course is built on is that a defect found in requirements costs a conversation, the same defect found in design costs a redraw, in code it costs a rewrite, and in production it costs a customer. Testing at the end catches defects at their most expensive. Applying quality assurance to every phase means putting a quality activity into each one: requirements get reviewed for testability, designs get inspected against the requirements, code gets reviewed and unit tested, integration gets exercised deliberately, and release gets a gate that somebody has to sign.
Two words get used interchangeably by students, and the course separates them firmly. Quality assurance is about the process and is preventive, asking whether the way we work produces good software. Quality control is about the product and is detective, asking whether this build is good. A submission that describes only test execution has covered control and skipped assurance, which is half the title of the course.
Verification and validation form the second distinction. Verification asks whether the product was built correctly against its specification. Validation asks whether the correct product was built against the user's actual need. A system can pass every verification activity and fail validation completely, and being able to explain that with an example is a standard graded move.
Test design is where the technical craft lives. Equivalence partitioning, boundary value analysis, decision tables and state transition testing are the techniques that turn an infinite input space into a finite set of cases with a rationale behind each. Choosing cases by intuition and calling it a test plan is the difference between a submission that scores and one that returns.
Turning aspects into a quality plan and a word budget
Aspects are judged individually at WGU, a 2 is required in each, and one gap returns the task. Here the aspects usually name phases or artifacts, so build a matrix with life cycle phases down one side and the quality activity, entry criteria, exit criteria and artifact across the top. Any phase with an empty row is an aspect you have not answered.
Now the budget. Suppose ten scored aspects and a document of about 1,800 words alongside your test artifacts. Ten into 1,800 is 180 each. Sort them. Three aspects are artifact aspects satisfied by a test plan table or a defect log, needing 100 words each of framing, so 300, releasing 240. Three are strategy arguments, asking which testing approach fits this system and why, at 300 each, or 900. Two ask about metrics and criteria, at 220 each, or 440. Two are process aspects about roles and reviews, at 150 each, or 300. Adding those, 300 plus 900 plus 440 plus 300 is 1,940, so trim one strategy section to 240 and one metric section to 180, landing near 1,840 with the strategy arguments taking almost half the document.
Write the exit criteria before the test cases. A test plan that cannot say what condition ends testing has no way to answer an aspect about release readiness.
Working the D480 quality task?
Send the aspects and a description of the system. You get a phase matrix, a test design approach with rationale, and a model plan document.
A quality activity for every phase
| Phase | Quality activity | Artifact it produces | Exit condition |
|---|---|---|---|
| Requirements | Review each requirement for testability and ambiguity | Annotated requirements with identifiers | Every requirement has a way to be proven |
| Design | Inspect the design against the requirement set | Inspection log with findings | No requirement without a design element |
| Implementation | Peer review and unit tests written with the code | Review records and a test suite | Agreed coverage of the logic paths that matter |
| Integration | Interface testing between components | Integration test results | Interfaces exercised in both directions |
| System | End to end functional and non-functional testing | Executed test cases and a defect log | No open defects above the agreed severity |
| Acceptance | Validation against the user need, not the specification | Acceptance results and sign-off | The user agrees this is the product they needed |
| Release and after | Regression suite maintained, defects fed back | Regression pack and defect trends | Escaped defects analyzed rather than only fixed |
The exit condition column is the one that makes this a plan rather than a description. Without it you have a list of activities that could run forever.
Test cases and defect reports that hold up
A test case is a small contract. It needs an identifier, the requirement it traces to, preconditions, the steps, the specific data used, the expected result and a place for the observed result. Cases without expected results are not tests, they are exploration, and an evaluator can tell instantly. Cases that share an identifier with a requirement answer traceability aspects without extra prose.
Defect reports have their own discipline. Title that states the symptom, environment, steps that reproduce it every time, expected against actual, severity separated from priority. Severity is how badly it breaks the product, priority is how soon somebody should fix it, and the two are genuinely different: a spelling error on the home page can be low severity and high priority. Confusing them is a common and visible mistake in this course.
For sources, established software testing texts and published standards for test documentation and quality models are the strong citations, and a recognized body of knowledge in testing gives you named definitions for the terms your aspects use. Cite in APA where your program requires it, and prefer the source that defines a technique to a blog post that summarizes it. Where your scenario supplies a system description, quote it when you justify a testing choice so the reader can see the choice came from the situation rather than from habit.
What clears evaluation in a QA course
WGU work is Competent or Not Competent, with no letter grades and no ordinary grade point average, and a performance assessment that misses an aspect can be revised and resubmitted without penalty. The cost is queue time in a six month flat rate term, which is why completeness beats polish on a first submission.
Plans that clear are specific to the system in front of them. They name the features being tested and the ones deliberately out of scope. They use recognized test design techniques and say which one produced which cases. They set entry and exit criteria with numbers. They separate assurance activities from control activities, which is the distinction the course title contains.
Returns come from generic documents. A test plan that would fit any software product, a list of testing types with definitions attached, cases with no expected results, and a section on quality metrics that names metrics without saying what decision each one would inform. Every one of those is a section that looks complete and answers a question the scenario did not ask.
Six mistakes that cost D480 students time
- Treating QA as testing. Assurance is process and prevention. A document that only covers execution has skipped half its subject.
- Test cases without expected results. Without an expected result there is no pass or fail, only an observation.
- Confusing severity with priority. They answer different questions and mixing them is visible immediately in a defect log.
- Skipping boundaries. Most defects live at the edges of ranges. A test set with no boundary cases has tested the easy middle.
- Metrics with no decision attached. A metric that changes nothing is decoration. Say what action a bad number would trigger.
- Searching by the banner number. ITSW 3151 appears in the catalog for both D480 and D280 JavaScript Programming, so confirm the D code before buying materials.
How we work on this course
Support for D480 is structure first. Send the scored aspects and the system description and you get a phase matrix with entry and exit criteria, a test design approach that names the technique behind each group of cases, a defect log format that separates severity from priority, and a model plan written the way WGU evaluators read quality documents. Where a part of your course is assessed by an objective assessment, our help is preparation only, and objective assessments are proctored: we never sit one, never assist during one, and never ask for or touch your portal credentials.
Terms are six months at a flat rate, so what a course really costs is the share of the term it consumes. Quality planning is one of the courses where a good structure at the start saves a full rewrite later.
Three questions D480 students ask
Is D480 the same course as ITSW 3151?
Do I need to write automated tests for this course?
What is the difference between verification and validation?
Where D480 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.