What Is Software?

Why it matters

You cannot test well what you cannot describe. A wrong total on a checkout screen may come from the screen, a business rule on the server, a price in the database, or a setting that differs between the test and live systems. Knowing the parts lets you say where a problem appears and ask the right person.

The cost of a problem also depends on where it sits: a cut-off label annoys users, while a tax rate set too high in the configuration overcharges every customer from the moment it is deployed.

Programs, data and configuration

Every running system combines three kinds of material that change at different speeds. The same program can behave differently with other data or configuration: a checkout that works in the test environment can fail in production because production uses another payment service, or because real data holds a longer product name than any test data. So record the version, the data and the environment with every test result.

• Program (code): instructions that developers write and build into something that runs, such as the code that adds VAT to an order. It changes only with a new release.
• Data: the information the program works on and keeps, such as customers, products, prices and orders. Users change it all day, with no new release.
• Configuration: settings that change behaviour without changing code, such as the tax rate, the payment service address or the session timeout. It usually differs between environments, for example test and production.

PROGRAM         total = subtotal + round(subtotal * vat_rate, 2)

CONFIGURATION   vat_rate: 0.15
                payment_service: https://payments.test.example.com
                session_timeout_minutes: 30

DATA            {"sku": "1042", "name": "Arabic coffee 250 g", "price": 38.00}

Try it: YAML Formatter Try it: JSON Tree Viewer

Types of software you will test

The type tells you where the software runs, how it reaches users and which risks matter. Many products combine several: a bank may run a website, mobile apps, an API for partners and software in its card terminals.

• Web applications run in a browser and load their pages from a server. Users install nothing, but each page must work across browsers, screen sizes and languages.
• Mobile apps are installed on Android or iOS devices and must cope with many device models, permissions, interruptions such as calls, and weak networks.
• Desktop applications are installed on Windows, macOS or Linux, like the point-of-sale program at a shop counter. Installation, updates and local printers become part of testing.
• APIs and services have no screen: other programs call them over a network, as a shop calls a payment service. You test them by sending requests and checking the responses.
• Embedded software runs inside devices such as card terminals and smart meters, often with limited memory and always on real hardware. Updating devices in the field can be slow or hard, so a defect that reaches them is expensive to fix.

Try it: User-Agent Parser

The layers of a typical web application

Most business software splits its work into layers, each with one job. Teams name them differently (presentation, application and data tiers; client and server), but a typical web application has these four. A mobile app usually shares the same back end, database and infrastructure; the app itself is another front end.

• Front end (presentation): web pages in the browser or the screens of an app. It shows information, collects input and makes first checks such as "this field is required". A tester checks layout, wording, input handling and messages.
• Back end (application logic): programs on servers that apply the business rules, such as prices, VAT, stock and permissions. The front end calls it with HTTP requests to an API. A tester checks rules and calculations, through the screen or the API.
• Database (data): keeps records such as customers, products and orders after the user leaves. A tester checks that the right records were saved, changed or deleted, and nothing else.
• Infrastructure: servers or cloud services, operating systems, networks, domain names, certificates and each environment’s configuration. A tester records which environment and version were tested.

Worked example: one order through every layer

A customer buys two packs of coffee at 38.00 SAR each and taps "Place order". The front end and the back end exchange HTTP requests and responses, whose meaning is defined in RFC 9110.

The customer sees only steps 1 and 6. Everything between them happens out of sight, so a confirmation on the screen does not prove that the order was stored correctly.

1  Front end   checks that the address is filled in, then sends the order
2  Request     POST https://shop.example.com/api/orders
               {"items": [{"sku": "1042", "qty": 2}]}
3  Back end    checks stock; 2 x 38.00 = 76.00; VAT 15% = 11.40; total = 87.40
4  Database    saves order 55031 with its line; reduces the stock of 1042 by 2
5  Response    201 Created   {"orderId": 55031, "total": "87.40"}
6  Front end   shows the confirmation: order 55031, total 87.40 SAR

   Underneath  infrastructure: servers, network, certificate of shop.example.com

Try it: URL Parser Try it: HTTP Status Code Lookup Try it: JSON Formatter

People build software, and people make mistakes

Every part of that order was written or set up by someone. People misread requirements, forget a case, type 0.51 instead of 0.15, or build two parts that each work alone but disagree. Defects are a normal result of building complex things, not a sign of a careless team.

In ISTQB terms, a person makes an error (a mistake) that can produce a defect (also called a fault or bug) in the code or in another work product, such as a requirement or a configuration file; executing the defective part can cause a failure. A later lesson covers these terms. In the coffee order, each layer can hide its own defect while the customer sees only the screen:

• Front end: a double tap sends the order twice.
• Back end: VAT is calculated on the wrong amount.
• Database: the order is saved without its line.
• Infrastructure and configuration: the test environment points to the live payment service.

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.
• RFC 9110: HTTP SemanticsIETF · 2022The meaning of HTTP methods, header fields, status codes and content negotiation, independent of the wire version.
• Overview of HTTP — MDNMDN Web Docs (Mozilla)How HTTP works: a stateless client–server protocol in which the client sends a request and the server answers with a response message.