How Software Is Built

Why it matters

A tester who sees only the finished screen sees only the end of a long chain. Many defects start before or outside the code: a vague requirement, a design with no error state, a setting that differs between environments. Knowing which step produced which work product lets you trace a failure to its source and ask questions while changes are still cheap.

It also tells you whom to ask and what to record: a test result means something only when it names the build and environment it came from.

The people: roles on a software team

A role is a set of responsibilities, not a job title: one person may hold several roles, and one role may be a whole team.

• Product owner: decides what the product does next and in what order; in Scrum, accountable for maximising the value of the product and for managing the product backlog, the ordered list of what is needed to improve it.
• Business analyst: works out the detail (business rules, data, exceptions) and writes it down as requirements; some teams leave this to the product owner.
• Designer: decides how people will use the feature: flows, layouts, wording, and states such as empty, loading and error.
• Developer: turns requirements and designs into code, writes unit tests and reviews colleagues’ code, often in one layer such as the front end or back end.
• Tester or QA engineer: reviews requirements and designs, runs tests, reports defects and gives the team information about quality for the release decision.
• DevOps or operations engineer: looks after the build-and-deploy pipeline, the environments and production monitoring. Strictly, DevOps is a way of working for the whole team, but it is also a common job title.

Work products: what each step hands on

Every step produces something the next one uses. ISTQB calls these work products; many teams say artifacts. For a tester they matter twice: you test against them, and you can test them too, by reviewing them before any code runs. They also change: when one is edited, compare the old and new versions to see which tests are affected.

• Requirements: user stories with acceptance criteria, business rules, and targets such as response time. The story below is typical.
• Designs: wireframes and prototypes from the designer; architecture and API contracts from the developers.
• Code: source files in a version control system such as Git; on many teams each change is reviewed in a pull request before it is merged.
• Build: a runnable package made, usually automatically, from one exact version of the code, with its own identifier; a team may produce many a day.
• Release: a build the team has decided to give to users, with a version number and release notes.

STORY-142  Apply a promo code at checkout
As a shopper
I want to apply a promo code at checkout
so that I pay the discounted price.

AC1  A valid code reduces the order total before payment.
AC2  An expired code shows the message "This code has expired".
AC3  Only one code can be applied to an order.

Try it: Text Diff

From idea to operation

Put roles and work products together and you get the path every change travels. The next module calls it the software development lifecycle (SDLC) and compares the models teams use to organise it; here is the simple version.

Two cautions. The steps overlap and loop: a defect sends work back to build, an unclear requirement back to requirements. And testers are not limited to the test step: the ISTQB Foundation syllabus recommends a test activity for every development activity, with testers reviewing work products as soon as drafts exist.

• Idea: feedback, a business goal or a regulation; the product owner decides whether it is worth doing.
• Requirements: stories, rules and acceptance criteria, reviewed by testers.
• Design: screens and flows from the designer, the technical design from developers.
• Build: code is written and reviewed; the pipeline produces a build.
• Test: tests run on the build in a test environment; fixes are retested (confirmation testing).
• Release: the team decides the build is ready, and it is deployed to production with release notes.
• Operate: the team monitors and supports the live system; what it learns becomes the next idea.

Worked example: one promo code from idea to operation

An online store keeps receiving support messages from customers who cannot find where to enter a discount code. The product owner moves a promo code field to the top of the backlog, and the business analyst writes STORY-142. Follow it through the remaining steps:

• Requirements: the tester asks what happens to the discount if an item is removed, and whether codes are case-sensitive. The answers become AC4 and AC5 before any code exists.
• Design: the tester asks for a loading state, because checking a code calls the server.
• Build and test: after pull request 318 is merged, the pipeline produces build 1047 and deploys it to the test environment. The tester reports two defects, each naming build 1047 and the failed criterion, and confirms the fixes in build 1049 (confirmation testing).
• Release: build 1049 goes to production as version 4.6.0, and the tester makes a short check right after the deployment.
• Operate: a user reports a valid code rejected because of a trailing space. The fix goes into the next release with a new regression test, and the loop closes.

Try it: Acceptance Criteria Generator Try it: User Story → Test Scenarios

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020The definition of Scrum: its accountabilities, events and artifacts, including the Definition of Done that testing helps meet.
• About pull requestsGitHubWhat a pull request is: a proposal to merge changes from one branch into another, with a place to discuss, review and run checks before the merge.