Software engineering basics: stages, tests and what to ask

That's the short version.

You don't need to write code to follow the rest.

We wrote it for two kinds of readers. One's a US business owner about to pay a developer or an agency for an app, a booking tool or a custom site. The other is a beginner who wants the map before picking a course. Both get the same stages, the same words and, at each step, the question worth asking.

Software engineering is the whole job, and coding is one part

Software engineering is the discipline of planning, building, testing, releasing and maintaining software so it keeps working as it changes. Coding is the part where someone types the instructions. It isn't the whole job.

The IEEE's 1990 glossary of software engineering terms defined it as "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software."

Development is only one of three nouns there, and that's the point.

The IEEE Computer Society's Software Engineering Body of Knowledge (SWEBOK), version 4 splits the field into 18 knowledge areas. Requirements, design, testing, maintenance, configuration management, operations and security each get a chapter. Construction, the coding part, is just one chapter out of 18. That's worth remembering when a quote is all about code.

Think of a kitchen remodel. Swapping a faucet is a job one handy person can do on a Saturday. Moving the sink means drawings, permits, a plumber and an electrician who don't trip over each other, an inspection and someone who'll answer the phone when a pipe drips next spring.

A small script is the faucet. A booking app your customers pay through is the remodel, and that's where engineering earns its fee.

So is a software engineer different from a programmer? Mostly in scope. The title varies by company, but the engineering work is the planning, checking and upkeep that's wrapped around the code.

The work runs in stages, and each one should leave proof

When you buy software, those areas map roughly onto stages. Every stage should leave something you can see, even if you can't read a line of code.

Teams don't always run these in a straight line. Our software development life cycle guide lays out a website project stage by stage, with the sign-offs you'll give at each one. Agile teams repeat the middle stages in short cycles of a week or two; our post on agile vs waterfall for website projects explains which fits a fixed budget. Either way, the questions in the table don't change.

Requirements are where "done" gets written down

So start where most arguments with a developer start, months before anyone notices. Requirements say who uses the software, what it must do, and what it won't do in this round.

Example: Live Oak Movers is a made-up moving company in Tallahassee, Florida. The owner wants customers to get a moving quote online and book a date. The first user story is "As a customer, I enter my old and new address and the number of rooms, and I see a price," which tells the developer what the quote screen needs. The second is "As the owner, I see every booking on one calendar." The out-of-scope list matters just as much: there's no crew app and no online payment in this round.

Two lines on that list save weeks of back and forth.

Ask your developer to write the requirements back to you in their own words. If what comes back surprises you, you've found the problem while it's still cheap.

Design decides what gets built and what gets borrowed

Once the requirements are agreed, design decides how the parts fit. That covers the screens, where the data lives, and which pieces come from outside, such as a maps service for distances or a calendar tool.

Borrowing is normal. NIST's Secure Software Development Framework (SP 800-218) tells teams to reuse well-secured components, such as "software libraries, modules, middleware, frameworks," and to keep checking them over their whole life. Every borrowed piece is also something that can change price, break or stop getting updates, and you won't control when.

So ask for the list. Which services and libraries will the project use, who pays for them, and who updates them? Our guide to third-party integrations covers what to check before you connect one. If the honest answer is that a ready-made tool does most of the job, our comparison of no-code and custom development helps you decide whether custom code is worth it at all.

What is version control, and why does it matter?

Code belongs in version control from its first line. The Git book puts it plainly: version control "records changes to a file or set of files over time so that you can recall specific versions later." Git keeps the full history of the project on every developer's machine.

Each saved change is a commit. It carries a message, an author and a date, so you can always see who changed what and when.

Developers also work on branches. As the Git book puts it, branching "means you diverge from the main line of development and continue to do work without messing with that main line." A half-finished feature stays on its branch until it's ready.

For a business owner, the big question is whose account the repository lives in. NIST's framework says to store code "based on the principle of least privilege," so only the people who need access have it (practice PS.1.1 in SP 800-218). Ask for the repository to sit in an account your business owns, with the developer added as a member. If they leave, you remove one person, and the code doesn't go anywhere.

A one-cent bug we planted, and the test that caught it

Now here's what version control and tests look like together. We tried it on October 25, 2026, on a Mac, with Git 2.54.0 and Python 3.9.6, both already on the machine.

We wrote a tiny quote calculator, the kind of function the Live Oak Movers tool would need. It adds sales tax to a job and rounds to the cent. Next to it, we wrote a test file with two cases: a $189.99 job at a sample 8.25% rate picked for the test must come to $205.66, and a $50 job with no tax must stay $50.00. We saved the pair as our first commit, and both tests passed. That's the safe starting point.

import unittest
from decimal import Decimal
from quote import total_with_tax


class TotalWithTax(unittest.TestCase):
    def test_rounds_to_the_cent(self):
        # $189.99 at 8.25% tax is $205.664175, so the customer pays $205.66
        self.assertEqual(total_with_tax(189.99, 0.0825), Decimal("205.66"))

    def test_no_tax(self):
        self.assertEqual(total_with_tax(50, 0), Decimal("50.00"))


if __name__ == "__main__":
    unittest.main()

Then we played a rushed developer. We changed one rounding setting to "round up", committed it with the message "Round totals up so we never undercharge", and skipped the tests. When we ran them, the first case failed: the code now said $205.67. The exact total is $205.664175, so rounding up overcharges the customer by one cent.

It's a cent on every job, and nobody would spot it by clicking around.

One command, git revert, undid it, and both tests passed again.

$ python3 -m unittest
.F
======================================================================
FAIL: test_rounds_to_the_cent (test_quote.TotalWithTax)
AssertionError: Decimal('205.67') != Decimal('205.66')
FAILED (failures=1)

$ git revert --no-edit HEAD
[main e8314aa] Revert "Round totals up so we never undercharge"
 1 file changed, 2 insertions(+), 2 deletions(-)

$ python3 -m unittest
Ran 2 tests in 0.000s
OK

Here's what the revert did. The git revert manual says it records "new commits to reverse the effect of some earlier commits." The bad commit is still in the history, next to its undo, so anyone who looks later can see what happened and why it's gone.

Tests are small promises the computer checks for you

That test file is 16 lines long, and both cases ran in under a thousandth of a second. Python's documentation describes a test case as something that "checks for a specific response to a particular set of inputs." Each one is a small promise: this input gives that answer.

Automated tests don't replace a person trying the app on a phone. They catch the dull, repeatable mistakes, the ones that'll slip back in six months later when someone edits nearby code.

Ask which tests run automatically on every change, and ask to see the last report. A developer who tests can show it in seconds, and won't mind.

One who doesn't will talk about how careful they are.

Code review means a second person reads every change

But tests only check what someone thought to test.

Review catches the rest. Google's engineering guide defines code review as "a process where someone other than the author(s) of a piece of code examines that code," and its checklist starts with design, functionality, complexity and tests, then naming and documentation.

On GitHub, that happens in a pull request, which GitHub's docs call a proposal to merge code changes into a project. The reviewer comments, the author fixes, and only then does the change join the main line.

NIST's framework treats review as a security practice too. Practice PW.7.1 describes code review, where "a person looks directly at the code to find issues," next to automated code analysis (SP 800-218, section PW.7).

A solo freelancer can't review their own work. That's fine for a small job, but ask who checks their changes on a bigger one. Some pair up with another developer for exactly this.

A good release is small, boring and easy to undo

Once code's been reviewed, it still has to reach your live site or app. That step is deployment, and the best teams make it dull on purpose.

DORA, a long-running research program on software delivery, tracks five software delivery metrics, including change lead time and change fail rate. Its finding is blunt: "speed and stability are not tradeoffs." Its advice is to make each change "as small as possible", because small changes are easier to check and easier to recover from.

Versions get numbers so everyone knows what's changed. Under Semantic Versioning, 2.4.1 to 2.4.2 is a bug fix, 2.5.0 adds something without breaking anything, and 3.0.0 signals a change that breaks how other code uses it.

Ask how a release happens and how long it takes to roll one back. After each release of a website, check load time with the speed test on our site and compare it with the last run. If it's slower right after a release, that release is the first suspect.

Security has to be part of every stage

But none of those stages is secure by accident. NIST's framework opens with the problem: "Few software development life cycle (SDLC) models explicitly address software security in detail" (SP 800-218, February 2022). So it's built around practices in four groups: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities.

CISA, the US cyber defense agency, pushes software makers the same way. Its Secure by Design page says products should come with "multi-factor authentication (MFA), logging, and single sign-on (SSO) available at no extra cost."

For buyers, CISA's Secure by Demand guide lists questions to ask, such as whether a vendor has removed default passwords and runs a public vulnerability disclosure policy.

For web apps, the OWASP Top 10 for 2025 is the usual checklist. Broken access control is first, followed by security misconfiguration and software supply chain failures. In plain words, that's users seeing other users' data, settings left wide open, and borrowed code that turns out to be bad.

You don't need to audit code to ask small, checkable questions. Is MFA on for the admin login? How are libraries updated? Who gets told if someone reports a flaw? Once the site is live, our SSL checker shows whether its certificate is valid and when it expires.

Technical debt is the interest you pay on shortcuts

Even careful teams leave something behind when they rush.

Martin Fowler calls it cruft, and his essay on technical debt explains the metaphor Ward Cunningham coined for it: "The extra effort that it takes to add new features is the interest paid on the debt."

It's an easy example to price. A feature that would take four days in clean code takes six in messy code. The extra two days are the interest, and you pay them on every future change until someone cleans up. His cleanup, the principal, costs five days. For one feature that's a loss, nine days instead of six, but with two more similar features coming, he says cleaning up first comes out ahead.

Not all debt is bad, and some of it's a fair trade. Launching before a busy season with a known shortcut can be the right call, as long as the shortcut is written down and fixed later.

Ask your developer to keep a list of shortcuts taken, and to price the cleanup. Then budget for maintenance after launch: updates, security patches and small fixes. Our guide to website uptime monitoring covers the cheapest part of that, knowing the moment your app goes down.

Get the code, the keys and the paperwork before the last payment

That's only useful if you can carry on without the person who built it. Handover is the stage owners forget until the developer is gone.

Before the final invoice is paid, you should have:

• admin access to the code repository, in your business's account
• a list of every service, login and API key the software uses, with who pays for each
• a README that explains how to set the project up and release it
• the test suite and how to run it
• a signed document that transfers ownership of the code to you

That last item isn't a formality. The US Copyright Office's Circular 30 on works made for hire explains that work by an employee within the scope of the job belongs to the employer. A commissioned work counts as made for hire only in nine listed categories, and only with a written agreement signed by both sides. Software isn't named on that list, so with an outside contractor, ownership usually moves through a written transfer. We're not lawyers, and this isn't legal advice; have a business attorney read the contract before you sign it.

Before you sign anyone, read our checklist for hiring a full stack developer: ten questions, current rates and the red flags.

Two myths that cost owners money

That last step sounds like the end. Two common beliefs make owners treat it that way, and both are wrong.

The first is that agile means no documentation. The Agile Manifesto values "working software over comprehensive documentation," but the next line says "there is value in the items on the right." Agile teams write less up front. They don't skip requirements, decisions or setup steps.

The second is that launch means finished. Browsers update, libraries get security patches, and customers ask for changes the week after launch. Software that nobody maintains doesn't stay the same; it slowly breaks.

Budget for it now, and it won't surprise you.

Software engineering for beginners: where to start

Now, if you're here to learn rather than hire, the outlook's good.

The federal labor statistics office, BLS, puts the median pay for software developers at $135,980 in May 2025, and $104,300 for quality assurance analysts and testers. The combined group held 1,905,400 jobs in 2025 and is projected to grow 10% by 2035, with about 106,100 openings a year.

BLS lists a bachelor's degree as the typical way in, and says some employers prefer a master's. You can still start on your own and build proof as you go.

A good order is one language first, then Git, then tests. Our JavaScript tutorial for beginners gets you writing code in a browser. Our list of programming languages to learn helps you choose a second one, and our ranking of in-demand tech skills shows which roles are growing fastest.

For reading, the SWEBOK guide can be downloaded from the IEEE Computer Society after a short form, and the Git book is free to read online. Then repeat our test: write a function, write two tests for it, break it on purpose and undo the break with Git. It's the whole engineering habit in miniature.

If you'd rather hire it out

You don't need to learn any of this to buy software well. You'll need the table near the top and the nerve to ask for proof at each stage.

Our take: the questions matter more than the tech stack. A developer who shows you the repository, the test report and a rollback plan without being asked is worth more than one who quotes less and shows nothing.

If you'd like us to build it, our developers work this way for small businesses, from the first spec to the handover. It's our own paid service, so compare it with others using the same questions, and ask for a price through our quote form.

How we made this guide: on October 25, 2026, we built the small Git repository described above on a Mac (macOS 27.0.1, Git 2.54.0, Python 3.9.6), broke it on purpose and kept the full terminal log with the article files. The BLS figures come from the Occupational Outlook Handbook page, read that day. Everything else is linked where it's used: the IEEE, NIST, CISA, the Copyright Office, and the Git, Python, GitHub, DORA and OWASP documentation. We checked each fact against its source that same day, and we didn't review any real client's code. Eram N., the author, reviews and approves the final text.

First published August 2020. Rewritten October 25, 2026: the old tutorial was a thin set of textbook definitions that ended in a broken list. It's now a plain-words guide to the stages of software engineering, with a real Git and testing example, NIST and CISA security practices, code ownership, 2025 BLS pay data and the question to ask a developer at each stage.

Sources

• IEEE Computer Society: Software Engineering Body of Knowledge (SWEBOK), version 4.0
• IEEE Std 610.12: Standard Glossary of Software Engineering Terminology (superseded)
• NIST SP 800-218: Secure Software Development Framework version 1.1 (February 2022)
• NIST SP 800-218 full text (PDF)
• CISA: Secure by Design
• CISA: Secure by Demand Guide
• OWASP Top 10:2025
• US Bureau of Labor Statistics: Software Developers, Quality Assurance Analysts, and Testers
• Pro Git: About Version Control
• Pro Git: Branches in a Nutshell
• Git documentation: git-revert
• Python documentation: unittest
• Google Engineering Practices: Code Review
• GitHub Docs: Pull requests
• DORA: Software delivery performance metrics
• Semantic Versioning 2.0.0
• Martin Fowler: Technical Debt (May 2019)
• Manifesto for Agile Software Development
• US Copyright Office: Circular 30, Works Made for Hire (PDF)