Software Testing Process and QA

Short answer: software testing is not a single phase at the end of a project but a three-layer process that runs alongside development. Developers verify their own code with unit tests, the team verifies that modules talk to each other with integration tests, and you as the client verify the result with acceptance testing (UAT). In a healthy project, testing takes 20 to 30 per cent of total development effort. Cutting it does not make the project faster; it postpones the bugs until they are live.

How many layers does testing have?

The test pyramid rests on a simple idea: put most of your tests in the cheapest layer. Hundreds of unit tests that run in seconds at the bottom, integration tests in the middle, a small number of end-to-end scenarios at the top. Flip the pyramid — test everything by clicking through screens — and every release costs more than the one before it.

• Unit tests: Check that a single function returns the right result. Fast, written by developers, run automatically on every change.
• Integration tests: Verify that the database, the payment service and the shipping API work together. In integration-heavy projects this is the critical layer.
• End-to-end (E2E) tests: Walk through a real scenario in a browser: log in, add to cart, pay. Slow, so reserved for critical flows only.
• Acceptance testing (UAT): The stage where you confirm the software does the job that was agreed. Business-focused, not technical.
• Regression testing: Confirms new features have not broken old ones. This is where automation pays for itself.

Automation does not pay off the first time it is written; it pays off at the third release. A manually tested project re-checks the same screens before every release, while the automated version does it in seconds.

What does a test actually look like?

The example below tests a small discount function. The point is not the test itself but what it does: it turns an acceptance criterion into code. Capping the coupon at 50 per cent is a business rule, and from now on nobody can break it by accident.

export function hesaplaIndirim(tutar: number, kuponYuzde: number) {
  if (tutar <= 0) throw new Error('Tutar sifirdan buyuk olmali');
  const oran = Math.min(Math.max(kuponYuzde, 0), 50); // kupon en fazla %50
  return Math.round(tutar * (1 - oran / 100) * 100) / 100;
}

// Kabul kriteri: kupon %50 ile sinirlanir ve kurus yuvarlamasi kaybolmaz.
describe('hesaplaIndirim', () => {
  it('kuponu %50 ile sinirlar', () => {
    expect(hesaplaIndirim(200, 80)).toBe(100);
  });

  it('kurus yuvarlamasini dogru yapar', () => {
    expect(hesaplaIndirim(19.99, 10)).toBe(17.99);
  });

  it('sifir ve negatif tutari reddeder', () => {
    expect(() => hesaplaIndirim(0, 10)).toThrow();
  });
});

Those three checks will raise an alarm the moment somebody lifts the cap or changes the rounding months later. How acceptance criteria belong in the paperwork is covered in software development contract.

Manual testing or automation?

They are not competitors; they do different jobs. Automation takes over the repetitive checks, while manual testing catches what only a person notices: a button in the wrong place, a nonsensical error message, a table that overflows on mobile. The question that sets the balance is simple: how many times will we repeat this check?

• Automate: critical flows such as login, payment and order creation that get retested on every release.
• Test manually: visual consistency, copy, and newly built screens that are still changing.
• Do not automate: screens used once a month, constantly changing, where writing the test takes longer than running it by hand.
• Remember: performance is a separate discipline — we covered how it is measured in website performance testing.

UAT: the part of the work that is yours

Handover is the stage that causes the most argument, and the reason is almost always the same: the acceptance criteria were never written down. UAT does not prove the software is bug-free; it proves it does the agreed job. The way to get through it efficiently is to write the test scenarios at the start, alongside the brief — see writing a software project brief.

• Test scenarios, not screens. Not "I checked the order screen" but "I placed an order with two items, shipping was calculated correctly, the invoice was issued".
• Use real data. A system that behaves with test data can behave very differently with real customer names and long product titles.
• Keep bugs in one place. Feedback scattered across chat messages gets lost; keep one list, and attach a screenshot and steps to every item.
• Prioritise. Not every bug is urgent. Without classification the team fixes the easy ones first and the critical ones wait.

Bug prioritisation: what gets fixed when?

A healthy bug list has three levels, and those levels decide the launch date. Critical bugs block the release, important bugs are closed in the first week, cosmetic ones go to the maintenance list. Projects that skip this distinction either never launch or launch with the wrong things fixed.

• Critical (blocks launch): data loss, payments failing, users unable to log in, a security hole.
• Important (first week after launch): a feature behaving incorrectly while a workaround exists.
• Cosmetic (maintenance list): alignment, typos, icon mismatches — anything that does not affect the flow.

The launch decision is driven by the class of the remaining bugs, not by their number. There is no bug-free software; there is software with no critical bugs.

How long does testing take and what does it cost?

Testing is not priced as a separate service; it sits inside the development effort. In practice a 40 person-day project spends 8 to 12 person-days on testing and fixes. Removing that line does not make the project cheaper, it moves the cost into production: fixing a live bug costs far more than the same bug caught during development, because data repair, customer communication and an emergency release all get added on top.

Conclusion

A proper testing process is not an optional extra; it is the condition for the project being deliverable at all: automated tests from the developers, integration checks from the team, and acceptance testing run by you. With all three in place, the delivery date stops being a matter of debate. If you want to talk through how to set this up on your project, look at our custom software service or request a quote — we write the testing effort as its own line when we scope the work.