Ethics in Software Testing
Testing tells you whether software does what it was built to do. Ethics asks whether what it was built to do is right. These are not the same question — and QA engineers are often the only people in a position to ask both.
The Scenario That Changes Everything
You are a QA engineer at a Wellington fintech. Your job today: validate the new personal loan decisioning system. The acceptance criteria are clear. The test data is prepared. You run the suite.
Everything passes. Green across the board.
But while reviewing the data you notice something. Applicants with Māori or Pasifika surnames are being offered interest rates 1.8 percentage points higher than Pākehā applicants with equivalent credit histories. The algorithm is trained on historical loan performance data — data collected during decades when those communities had systematically less access to credit. The pattern is real. The bias is baked in. The tests passed.
Is your job done?
The test oracle problem is the challenge of knowing what the correct output should be. Traditional oracles — specifications, reference implementations, user stories — tell you what the system is supposed to do. But they say nothing about whether what it does is fair, lawful, or safe.
The fintech scenario above is not a bug in the conventional sense. The algorithm is doing exactly what it was trained to do. The specification was satisfied. The business stakeholder signed off on the model. If you only test against the spec, you will miss it completely.
Ethical testing requires a second oracle: what should this system do to avoid harm? That oracle comes not from a JIRA ticket, but from professional judgment, legal obligation, and human values. That is what this lesson is about.
Why Testers Carry Ethical Weight
Software testing is often described as the "last line of defence" before software reaches users. That metaphor carries more weight than most people realise. Three structural factors place QA engineers in a uniquely powerful — and uniquely responsible — position.
Three Sources of Ethical Power
1. Cross-system visibility
Developers typically see one module or service. Product managers see user flows and KPIs. Business analysts see requirements. QA engineers exercise the whole system: they see the database, the API, the UI, the integration points, the edge cases, and the data flowing through all of it. No other role has that vantage point. When something goes wrong systemically — like a biased algorithm or a privacy leak — the tester is often best placed to see it.
2. Access to real consequences
While most of the team reasons from abstractions (requirements, wireframes, code), testers work with concrete outcomes. You see what the system actually does to real (or realistic) data. You observe the output that a real customer would receive. This grounds ethical concerns in evidence, not speculation.
3. Professional independence
A good QA engineer's role is explicitly to be sceptical — to challenge assumptions and surface problems others missed. That professional identity gives testers licence to raise concerns that a developer or product manager might feel uncomfortable raising without being seen as obstructionist. Use it. The ISTQB Code of Ethics — covered in Section 6 — formalises this independence as an obligation, not just a permission.
Ethical blindness is still a choice. "I only test what I'm told to test" is not a neutral position. It is a decision to not look. When software causes harm and a tester had the access, skills, and opportunity to detect it, the question of culpability is real — both professionally and, in some jurisdictions, legally.
Five Ethical Domains for Testers
Ethical obligations in testing cluster around five domains. Each has technical methods, legal context, and NZ-specific obligations.
A — Algorithmic Bias
NZ Human Rights Act 1993 • Privacy Act 2020Bias in software occurs when a system produces systematically different — and unfair — outcomes for different groups of people. It usually originates in one of three places:
- Training data bias: Historical data encodes historical discrimination. A model trained on past lending decisions inherits past lending discrimination. A model trained on historical hiring decisions learns to replicate past hiring biases.
- Proxy variables: Even without using a protected characteristic directly, a system can achieve the same effect by using correlated proxies. Postcode, surname, school attended, and device type can all serve as proxies for ethnicity or socioeconomic status.
- Disparate impact: A facially neutral rule can still harm a protected group disproportionately. Under the NZ Human Rights Act 1993, indirect discrimination based on characteristics such as race, ethnicity, sex, disability, age, and religious belief is unlawful, even without discriminatory intent.
Protected characteristics under NZ law (Human Rights Act 1993, s21) include: sex, marital status, religious belief, ethical belief, colour, race, ethnic or national origins, disability, age, political opinion, employment status, family status, and sexual orientation. The Privacy Act 2020 extends this with restrictions on how personal information about these characteristics may be collected, used, and disclosed.
What to test for: Disaggregate your output data by demographic group. Compare error rates, approval rates, interest rates, or whatever outcome the system produces, broken down by protected characteristic. Use equivalence partitioning with demographic inputs. Check for disparate impact even when no protected attribute is an explicit input — look for proxy patterns. Document your findings with evidence.
B — Privacy and Test Data
NZ Privacy Act 2020 • Health Information Privacy Code 2020One of the most common — and most casually ignored — ethical failures in software testing is the use of real personal information in non-production environments. It happens because it is convenient: production data is the most realistic test data. But convenience does not make it lawful.
The NZ Privacy Act 2020 establishes thirteen Information Privacy Principles (IPPs). Several apply directly to test data:
- IPP 2 (Collection from subject): Information collected from individuals should be collected for a lawful purpose. "We needed realistic test data" is unlikely to satisfy this principle if customers were not informed.
- IPP 4 (Manner of collection): Collection must not intrude unreasonably on personal affairs.
- IPP 5 (Storage and security): Agencies must ensure personal information is protected by security safeguards. Development and test environments are almost always less secure than production.
- IPP 10 (Limits on use): Information collected for one purpose may not be used for an unrelated purpose without consent. Copying production customer records into a test environment to run load tests is a use for an unrelated purpose.
For health information, the Health Information Privacy Code 2020 (issued under the Privacy Act) imposes even stricter controls. Using real Health NZ patient records in a test environment without specific authorisation would be a serious breach.
The tester's obligation: If you encounter real PII in a test environment, you are obligated to flag it — even if you did not put it there. Document what you found, who you told, and when. Push for synthetic data generation, data masking, or anonymisation before testing continues. This is not optional if you are testing under a contract that includes NZ Privacy Act compliance obligations.
- Synthetic generation: Use tools (Faker, Mimesis, Mockaroo) to generate realistic but entirely fictional datasets. Preferred approach.
- Data masking: Replace real values with realistic substitutes (real name → "John Smith", real IRD number → sequential fake number).
- Tokenisation: Replace sensitive values with opaque tokens that can be reversed only with a key held securely in production.
- Subsetting + masking: Take a small slice of production data structure (schema, statistics) but replace all actual values.
C — Accessibility Ethics
NZ Web Accessibility Standard 1.2 • Human Rights Act 1993Inaccessible software excludes people with disabilities. Exclusion is harm. This is not rhetorical — it is legal doctrine in Aotearoa New Zealand.
The NZ Web Accessibility Standard 1.2 (based on WCAG 2.2 Level AA) is a mandatory requirement for all New Zealand Government agencies' websites and web applications. Failure to meet it is a breach of the standard and can constitute unlawful discrimination under the Human Rights Act 1993, which prohibits discrimination on the grounds of disability.
For private sector organisations, accessibility is not yet mandated by the web standard — but the Human Rights Act still applies. A business website that is materially inaccessible to people with disabilities may be found to discriminate in the supply of goods and services (s44 HRA).
The ethical dimension for testers:
- Accessibility bugs are not cosmetic. A screen reader user who cannot complete a checkout flow has been denied access to a service. A deaf user who cannot access video content without captions has been excluded from information. These are harms.
- Accessibility testing should not wait until the end of the release cycle. By that point, retrofitting costs are high and pressure to ship is intense. Raise accessibility in design review, not just in UAT.
- If you are testing government software and it fails WCAG 2.2 AA, you have documented a legal compliance failure — treat it with the same urgency as a data breach or security vulnerability.
Quick accessibility ethics checklist for testers: keyboard navigation without mouse, screen reader compatibility (NVDA, VoiceOver), sufficient colour contrast (4.5:1 for normal text), captions on video, meaningful alt text on images, form error messages that identify the field, timeout warnings that can be extended.
D — Security Ethics and Responsible Disclosure
Crimes Act 1961 (s252–254) • Computer Fraud and Abuse frameworksSecurity testing raises a cluster of ethical questions that do not arise in functional testing. The core tension: finding a security vulnerability is only useful if it gets fixed, but the act of finding it — and what you do next — can itself cause harm or legal risk.
What authorisation means
In New Zealand, accessing a computer system without authorisation is a criminal offence under the Crimes Act 1961 (sections 252–254: accessing computer systems, damaging computer systems). "Authorisation" in the context of security testing means explicit, documented, written permission to probe specific systems for specific vulnerability types within a defined scope and timeframe. A general employment contract does not constitute this. A general "test the system" mandate does not constitute this.
If you discover a vulnerability that is outside your authorised scope — for example, you find a critical API vulnerability while doing frontend testing — you must stop probing immediately and report what you found. You must not attempt to exploit the vulnerability further to understand its full impact, even with good intentions. Further probing without specific authorisation moves you from "tester" to "unauthorised accessor" in legal terms.
Responsible disclosure
When you find a security vulnerability:
- Document the finding with minimum reproducible evidence (enough to confirm it exists, not enough to weaponise it).
- Report immediately to the security team or relevant lead — not in a standard JIRA ticket that 40 people can see.
- Do not discuss it in public channels, Slack, or with colleagues who do not need to know.
- Follow your organisation's disclosure policy. If none exists, push for one to be written.
Bug bounties and third-party software
If you discover a vulnerability in third-party software while testing (a library, a SaaS platform you integrate with, an open source component), responsible disclosure means contacting the vendor privately and giving them a reasonable time to fix before any public disclosure. Most major vendors have a security disclosure email or HackerOne programme. The standard timeframe is 90 days before going public, though critical vulnerabilities with active exploitation may warrant faster escalation.
Never disclose a vulnerability publicly before the vendor has patched it. Even with good intentions, public disclosure of an unpatched vulnerability provides a roadmap for attackers and can cause real harm. The ethical obligation runs to users of the software, not to the hacker community's right to know.
E — Whistleblowing and Refusing to Sign Off
Protected Disclosures (Protection of Whistleblowers) Act 2022The most difficult ethical situation a tester faces is not finding a bug — it is being pressured to ignore one. Scenarios include:
- A manager asks you to close a defect as "accepted risk" when you believe it poses a genuine safety or privacy threat.
- A release date is immovable and you are asked to sign off on incomplete testing.
- You discover the software is being used for a purpose that was not disclosed to users or regulators.
- A critical bug is being suppressed internally because acknowledging it would trigger regulatory reporting obligations.
Your rights under NZ law
The Protected Disclosures (Protection of Whistleblowers) Act 2022 protects employees who make disclosures about serious wrongdoing. "Serious wrongdoing" includes conduct that is an offence, a serious risk to health or safety, a serious risk to the environment, or conduct that is grossly irresponsible or grossly improper. Suppressing a known security vulnerability that puts customer data at risk could qualify. Deploying software that discriminates illegally could qualify.
To receive protection, the disclosure must be made to an "appropriate authority" — which can include your employer's internal processes, the Privacy Commissioner, the Ombudsman, or a sector-specific regulator (FMA for financial services, Taumata Arowai for water, etc.). External disclosure to the media is a last resort with additional conditions.
The ISTQB position
The ISTQB Code of Ethics (detailed in Section 6) is explicit: testers should not certify software that does not meet their professional standards. Signing off under pressure when you believe the software is unsafe is an ethical violation of your professional obligations, regardless of what you are instructed to do. Document your concerns in writing — email, not verbal — before signing off on anything under pressure.
- Put your objection in writing — email your manager and cc yourself to a personal address.
- State specifically what risk you believe exists and what testing was not completed.
- Request written confirmation that the decision to release was made by the appropriate authority (not you).
- If your concern involves legal violations, consider whether your organisation's legal team, compliance function, or an external regulator is the appropriate next step.
- If you believe you are being retaliated against, seek advice on your rights under the Protected Disclosures Act 2022 and the Employment Relations Act 2000.
AI Ethics for Testers
Generative AI and automated decision-making systems amplify both the power and the ethical risk of software. When you test an AI system, bias, opacity, and unintended harm operate at scale — a biased recommendation algorithm is not making one bad decision, it is making the same bad decision millions of times, invisibly.
Testing for demographic bias in AI
Key AI application areas where demographic bias has been documented and where testers should apply explicit bias testing:
- Facial recognition systems: Well-documented accuracy disparities across gender and ethnicity. If you are testing a facial recognition feature (for identity verification, access control, or attendance), run accuracy tests against demographically diverse test sets. Measure false acceptance and false rejection rates by group. A system that is 99% accurate overall but 85% accurate for dark-skinned women is not a passing system.
- Lending and credit decisioning: As per the opening scenario. Test with synthetic applicant profiles that are identical in creditworthiness but vary by name, address postcode, and other potential proxies.
- Benefit eligibility systems: Government-operated automated systems that determine eligibility for social support (Working for Families, Jobseeker support, etc.) must not produce discriminatory outcomes. Testing these systems requires explicit demographic disaggregation of outcomes.
- Recruitment AI: Systems that screen CVs or rank candidates have been shown to encode gender and ethnicity biases from historical hiring data.
NZ Algorithm Charter
The New Zealand Algorithm Charter (2020, refreshed 2023) is a voluntary commitment by government agencies to responsible use of algorithms and AI. Signatory agencies commit to: transparency about how algorithms are used, human oversight of significant decisions, testing for bias and fairness, and providing mechanisms for individuals to query decisions made about them.
If you are testing software for a signatory government agency, the Charter provides a de facto checklist. Even for non-signatory organisations, the Charter's principles represent good practice and are increasingly expected by NZ regulators.
EU AI Act implications for NZ
The EU AI Act (in force from 2024, fully applicable from 2026) establishes risk tiers for AI systems and imposes mandatory conformity assessments, documentation, and testing requirements for "high-risk" AI — which includes credit scoring, employment screening, benefit eligibility, and biometric identification. NZ organisations that sell into the EU, or that handle data of EU residents, may be subject to these requirements. Even where the Act does not apply directly, it is becoming the de facto international standard for AI risk management, and NZ regulators are watching it closely. Testers should be aware of its requirements, particularly the mandatory bias assessment and human oversight obligations for high-risk systems.
Practical Scenarios — What Would You Do?
Ethical decisions in testing are rarely obvious in the moment. The following scenarios are designed to make the dilemmas concrete. Read each one and think about your answer before reading the guidance.
While running integration tests on the new IRD tax return lodgement API, you notice the error logs being written to your shared test environment server contain full responses from the IRD sandbox — including what appear to be real IRD numbers and taxpayer names, not synthetic test data. The integration was set up six months ago by a developer who has since left. There are approximately 10,000 records.
Log in Jira or escalate immediately?
Escalate immediately — do not log this as a standard JIRA ticket. A JIRA ticket is visible to your entire engineering team and potentially others. The fact that real IRD numbers may have been in a shared test environment for six months is a potential notifiable privacy breach under the Privacy Act 2020. Your organisation may have an obligation to notify the Privacy Commissioner if the breach has caused, or is likely to cause, serious harm.
Immediately: notify your security lead and privacy officer (or equivalent) verbally and in writing. Stop further testing that accesses those logs. Preserve the evidence — do not delete anything. Do not discuss it on public Slack channels. Ask your organisation to assess its notification obligations under IPP 12 and the Act's breach notification provisions (Part 6).
The mobile app you are testing consistently fails a suite of performance tests under load — page load times exceed the contractual SLA of 3 seconds on 95th percentile. The release is scheduled for Monday. On Friday afternoon, the dev lead says: "These tests are too strict for mobile. Can you just update the thresholds to 6 seconds so we can get the sign-off done? The SLA is aspirational anyway."
What do you do?
Changing the test to match the output is a fundamental testing anti-pattern — and in this context, it is an ethical violation. The SLA exists in a contract. Misrepresenting test results to achieve a sign-off that enables a release that will breach a contractual obligation is potentially fraudulent, and certainly a breach of your professional obligations.
Decline. Put the decline in writing. Document that you were asked to change the test thresholds and that you refused. Offer an alternative: can the release be scoped to exclude the performance-critical features? Can the release note the known performance limitation with a remediation timeline? Can the client be consulted about whether they accept the delay? The product can still ship — but not by falsifying the test results.
You are onboarding to a new project: a patient portal for a DHB-successor Health NZ network. Your test environment has been pre-populated with data. As you start exploring, you realise the patient names, NHI numbers, and appointment histories in the test system look very real. You search for a name and find a matching person on LinkedIn who lives in the region. This is not synthetic data.
What do you do?
Stop testing immediately. Health information is subject to the Health Information Privacy Code 2020, which imposes strict controls on use and disclosure. Real patient health records in a non-production environment without patient consent is a serious breach — potentially one that must be reported to the Privacy Commissioner and possibly to affected individuals.
Notify your team lead and your organisation's privacy officer in writing immediately. Do not continue testing against this data. Do not conduct further lookups (you have already established the data is real — any further access increases the scope of the breach). Preserve all evidence of what you found and when. Advocate strongly for the test environment to be rebuilt with synthetic data before testing resumes. If you are told to continue anyway, document your refusal and consider whether external escalation (Privacy Commissioner) is warranted.
ISTQB Code of Ethics — Applied to NZ Testing
The ISTQB (International Software Testing Qualifications Board) Code of Ethics is derived from the ACM/IEEE Software Engineering Code of Ethics. It defines eight principles. Below each principle is mapped to a concrete NZ testing context.
Public
Act consistently with the public interest. NZ context: If you are testing a system that processes Kiwis' tax, health, or welfare data, you serve the public first — not the release deadline. A decision to ship known defects in a government tax portal is a decision that affects every New Zealander who uses it.
Client and Employer
Act in the best interest of the client and employer, consistent with the public interest. NZ context: "Consistent with the public interest" is the key qualifier. Your employer's interest in shipping on time does not override the public interest in a non-discriminatory lending algorithm. The principle requires you to raise the conflict, not resolve it by ignoring the public interest.
Product
Ensure the products and related modifications meet the highest professional standards possible. NZ context: "Highest professional standards" includes legal compliance. If your test plan does not include accessibility testing for a government web application, it does not meet the professional standard required by the NZ Web Accessibility Standard 1.2.
Judgment
Maintain integrity and independence in professional judgment. NZ context: This is the anti-pressure principle. When a manager asks you to change test thresholds, sign off incomplete tests, or close bugs as "acceptable," your professional judgment — not the hierarchy — is the ethical standard. Independence is not insubordination; it is your professional obligation.
Management
Subscribe to and promote an ethical approach to software testing management. NZ context: Senior testers and test managers are responsible not just for their own conduct but for creating an environment where junior testers feel safe raising ethical concerns. A team culture where "just fix the test" is acceptable training is an ethical failure at the management level.
Profession
Advance the integrity and reputation of the profession. NZ context: This includes knowledge-sharing within the NZ QA community. If you discover a new pattern of bias in a particular class of algorithm, sharing that pattern (appropriately anonymised) through NZQA forums or professional networks advances the profession's collective ability to detect it.
Colleagues
Be fair to and supportive of colleagues. NZ context: Support colleagues who raise ethical concerns. If a junior tester on your team raises a concern about privacy or bias, take it seriously — not dismissing it as "not your job" or "overthinking it." A psychologically safe testing team catches more ethical issues.
Self
Participate in lifelong learning regarding the practice of the profession. NZ context: NZ law changes. The Privacy Act 2020 replaced the 1993 Act. The Algorithm Charter is updated. The EU AI Act is rolling out. Remaining current on the legal and ethical landscape is not optional for a professional tester working on systems that affect people's lives.
Self-Check
Click each question to reveal the answer.
1. A loan decisioning system produces different interest rates for applicants with Māori surnames compared to applicants with Anglo-Celtic surnames, despite identical credit profiles. The algorithm does not use ethnicity as a direct input. Is this still potentially unlawful under NZ law?
Yes. The Human Rights Act 1993 prohibits indirect discrimination — that is, a facially neutral practice that disproportionately disadvantages a group defined by a protected characteristic. Ethnic or national origin is a protected characteristic under s21. The fact that surname is used as a proxy rather than ethnicity directly does not remove the discriminatory effect. Additionally, if the algorithm is used by a government agency, it may breach the NZ Algorithm Charter's commitment to algorithmic fairness.
2. Your test environment contains real customer names and email addresses copied from production six months ago. You did not set this up. Do you have any obligation to act?
Yes. The Privacy Act 2020 places obligations on agencies (organisations) to protect personal information — not just on the individuals who originally collected it. As a tester who has discovered a likely breach of IPP 5 (security safeguards) and IPP 10 (use consistent with collection purpose), you have a professional and ethical obligation to report what you found to your organisation's privacy officer or equivalent. The Privacy Act's breach notification provisions (Part 6) may also require the organisation to notify the Privacy Commissioner and affected individuals if the breach is likely to cause serious harm. "I didn't create the problem" is not a reason to ignore it.
3. While doing authorised frontend testing on a payment app, you accidentally discover that you can access any user's transaction history by changing a numeric ID in the URL — a classic IDOR vulnerability. You were only authorised to test the UI. What should you do next?
Stop exploiting the vulnerability immediately. You have enough evidence to confirm it exists (you found it accidentally). Any further deliberate testing of the vulnerability — accessing other accounts, testing the scope — would likely exceed your authorisation and could constitute unauthorised access under the Crimes Act 1961 (s252). Document exactly what you found and how, with minimum reproducible evidence. Report it immediately through a secure channel (not a public Jira ticket) to your security lead. The vulnerability should be added to your authorised scope before any further testing is done. This is textbook responsible disclosure within an organisation.
4. A government website you are testing fails WCAG 2.2 AA colour contrast requirements on its primary navigation. The agency is a signatory to the NZ Web Accessibility Standard 1.2. The project manager says "it's close enough and we have visual design sign-off." How do you handle this?
The NZ Web Accessibility Standard 1.2 is mandatory for New Zealand Government agencies, not aspirational. "Close enough" is not a valid response to a legal compliance obligation. Log the defect with specificity: which elements fail, what their measured contrast ratio is, and what the required ratio is (4.5:1 for normal text, 3:1 for large text). Mark it as a compliance defect, not a cosmetic issue. Escalate if the project manager declines to address it — this is a legal obligation, and failing to meet it could expose the agency to a Human Rights Act complaint. Document your escalation in writing.
5. You are under intense pressure to sign off a release. A critical defect you raised — a race condition that could corrupt financial transaction records under concurrent load — has been closed as "will not fix" by the development manager, who says the load scenario is "too unlikely." You disagree. What are your options?
You have several options, in order of escalation: (1) Document your position in writing — email the dev manager and your own lead stating clearly that you do not consider the risk acceptably mitigated, with your technical reasoning. (2) Request a written decision from an appropriate authority — ideally someone with authority over the release who can formally accept the risk on behalf of the organisation. You should not be the one signing off on a risk you have explicitly flagged as unacceptable. (3) If the financial data corruption risk is serious enough, escalate to the appropriate internal function — risk, legal, or compliance. (4) If the software is in a regulated sector (financial services, healthcare), consider whether your obligation extends to a sector regulator (FMA, etc.). The Protected Disclosures (Protection of Whistleblowers) Act 2022 may apply if you believe the decision constitutes serious wrongdoing. Throughout: keep records of everything. Your professional integrity depends on being able to show what you raised, when, and to whom.
Knowledge Graph
This lesson connects to related testing domains. Explore adjacent skills to build a complete picture.
Test data anonymisation, PII detection, Privacy Act compliance patterns
Demographic disaggregation, disparate impact analysis, synthetic data generation
WCAG 2.2 AA, NZ Web Accessibility Standard 1.2, screen reader testing
Human Rights Act 1993, Privacy Act 2020, Protected Disclosures Act 2022
NZ Algorithm Charter, EU AI Act, testing LLMs and automated decisions
Responsible disclosure, authorisation boundaries, Crimes Act 1961