Software testing
Checks an application’s features and behaviour. Does each screen, form and function do what it should, including when people make mistakes?
Software & System Testing
Know how your software behaves before your users do.
Testing gives you evidence about how your software and systems actually behave. IT Looms plans and runs tests, reports what was found in plain language, and checks again once issues are fixed.
- Functional
- Integration
- System
- Regression
- Performance
test-run · sample checks
IllustrationCan a customer create an account?
Functional · Passed
Does the booking reach the calendar service?
Integration · Passed
Does login still work after the latest change?
Regression · Issue logged
Does the full booking workflow complete?
System · Queued
Issue · High
Login fails after password reset on mobile.
- 1. Reset password from email link
- 2. Sign in on a mobile browser
- Fixed · retest passed
Two levels of testing
Software testing and system testing look at different things.
Both are useful, and many projects need a mix. The difference is how much of the picture each one checks.
System testing
Checks how the complete system and its connected parts work together — applications, backend, databases and outside services — across whole workflows.
Testing scopes
Choose the questions you need answered.
Each testing area answers a different question. We can discuss one, several, or help you decide which matter most for your system.
Functional testing
Do features behave as expected?
Each feature is checked against what it is supposed to do, including invalid input and unusual cases.
Integration testing
Do connected components exchange information correctly?
Checks the points where parts meet — an app and its API, a website and a payment provider, two internal systems.
System testing
Does the complete system support the intended workflow?
Follows real tasks from start to finish across the whole system, the way your users would perform them.
Regression testing
Have recent changes affected existing functionality?
After updates or fixes, previously working features are rechecked so that new changes do not break old ones.
Performance testing
How does the system behave under an agreed workload?
Measures response times and stability against a workload agreed with you in advance, and reports what was observed.
Test automation
Which repeatable checks can run automatically?
Identifies checks worth automating and builds scripts that can run them again quickly after each change.
A concrete example
Testing an online booking system.
For an online booking system, testing could check account creation, availability, booking confirmation and the connections between those steps.
- Step 1
Account creation
Can a new customer register and sign in?
- Step 2
Availability
Are only genuinely free slots offered?
- Step 3
Booking confirmation
Do the page, records and email all agree?
Between the steps, integration checks could confirm that information is passed on correctly — for example, that a booked slot disappears from availability and that the confirmation email matches the booking record.
What you receive
Findings you can act on.
A clear test report shows what was tested, what was expected, what actually happened and how serious each issue is. The sample below is illustrative only.
Test report — Online booking system
Illustrative sample — not a real client report
Test scope
- In scope
- Account creation, availability search, booking confirmation and the confirmation email.
- Out of scope
- Payments and administrator screens.
- Environment
- Test environment; desktop and mobile browsers.
Severity scale
- Critical
- Blocks a core workflow; no workaround.
- High
- Wrong result in an important feature.
- Medium
- Feature works with a workaround or minor error.
- Low
- Cosmetic or wording issue.
Expected and observed behaviour
TC-01Account creation
Passed- Expected
- Account is created and a verification email is sent.
- Observed
- As expected.
TC-02Availability search
Passed- Expected
- Only free time slots are shown for the chosen date.
- Observed
- As expected.
TC-03Booking confirmation
Issue BK-03 · High- Expected
- Confirmation page and email show the same date and time.
- Observed
- Email shows a time one hour earlier than the booking.
Issue BK-03 — steps to reproduce
Confirmation email shows the wrong booking time
Severity: High — customers may arrive at the wrong time.
- Sign in as a test customer.
- Search for availability on any future date.
- Book the 10:00 slot and confirm.
- Open the confirmation email.
Expected: 10:00 · Observed: 09:00
Retest status
- ReportedIssue logged with steps and evidence.
- Fix receivedTime-zone handling corrected by the development team.
- Retested: passedTC-03 rerun, related cases TC-01 and TC-02 rechecked.
Proposed testing workflow
Agree, prepare, execute, report, retest.
A proposed outline for a testing engagement. The depth of each step is agreed with you based on the system and its risks.
Step 01
Agree Scope
Decide what will be tested, on which environments, and what counts as expected behaviour.
Step 02
Prepare Tests
Write test cases and test data from the requirements and the workflows that matter most.
Step 03
Execute
Run the agreed tests manually or with automation, recording what was observed.
Step 04
Report
Share clear findings: expected and observed behaviour, severity and steps to reproduce.
Step 05
Retest
Once fixes are made, rerun the failed checks and related areas to confirm the result.
Discuss Your Testing Requirements
Tell us about the software or system you want checked, what has changed recently and when you need the results.
Prefer to talk? +92 316 1039878