DEV Community: Tester Academy

Write Your First Python Unit Tests with pytest: A Discount Calculator Example

Tester Academy — Mon, 26 Oct 2026 12:02:03 +0000

A discount calculator is a useful starting point for learning unit testing. Its rules are simple, but it still gives you normal inputs, boundary values and errors to check.

Let’s build one in Python and test it with pytest.

Decide What the Function Should Do

Before writing tests, define the expected behaviour.
Understanding the basics of unit testing helps you turn these requirements into focused checks.

Our function should:

Apply a percentage discount to a price.
Accept discounts from 0% to 100%.
Reject discounts outside that range.

For a ₹1,000 product, a 10% discount should return ₹900. A zero discount should leave the price unchanged.

This example assumes a valid, non-negative numeric price. Production pricing also needs input validation and explicit currency-rounding rules.

Create the Discount Function

Create a folder for the example. Inside it, save this code as discount.py:

def discounted_price(price, discount): if not 0 <= discount <= 100: raise ValueError("Discount must be between 0 and 100") return price * (100 - discount) / 100

The condition rejects invalid percentages. The final line calculates the amount remaining after the discount.

Install pytest

With Python installed, open a terminal in your project folder and run:
python -m pip install pytestNext, create a file named test_discount.py alongside discount.py.
The test_ prefix lets pytest discover the test file using its default naming rules.

Write Your First Test

Add this code to test_discount.py:
from discount import discounted_pricedef test_ten_percent_discount(): price = 1000 result = discounted_price(price, 10) assert result == 900

This follows Arrange, Act, Assert:

Arrange: Prepare the original price.
Act: Call the discount function.
Assert: Check that the result equals ₹900.
Run it with:
python -m pytest -q
If everything is correct, the summary should show 1 passed.

Test the Boundary Values

A normal discount is only one case. Add separate tests for the lowest and highest accepted percentages:

def test_zero_discount(): assert discounted_price(1000, 0) == 1000def test_full_discount(): assert discounted_price(1000, 100) == 0
These tests check that valid boundary values remain accepted. Each test has a descriptive name, making failures easier to identify.

Check Invalid Discounts

Add import pytest at the top of test_discount.py, then include:

def test_negative_discount():    with pytest.raises(ValueError):        discounted_price(1000, -10)def test_discount_above_limit():    with pytest.raises(ValueError):        discounted_price(1000, 120)

pytest.raises checks whether the function raises the expected exception.
These tests pass when invalid discounts trigger ValueError. They fail if the function silently accepts those values.

Run the command again:

python -m pytest -q
The expected summary is now 5 passed.

See What a Failure Looks Like

Temporarily change the calculation in discount.py to:
return price * discount / 100
Run the tests again. The 10% test fails because the function returns ₹100, the discount amount, instead of ₹900, the final price.

The failure identifies a mismatch between the expected and actual result. Check the requirement and implementation, then restore the correct formula.

Final Thoughts
You now have five tests covering a standard discount, two boundaries and two invalid inputs.

They check the calculation’s defined behaviour. They do not verify checkout, payments or order creation.

As a next exercise, define what should happen when the original price is negative. Write a test for that requirement, then update the function to satisfy it.

System Testing vs Integration Testing: What Actually Changes?

Tester Academy — Tue, 13 Oct 2026 11:07:52 +0000

Integration testing and system testing can examine the same features, which often makes them confusing for beginners.

The difference becomes clearer when you look at what each test is trying to prove.
Let's use an online payment example.

Start With Integration Testing

Imagine an e-commerce application with three components:

Payment service
Order management service
Inventory service The payment service processes transactions, the order service creates orders, and the inventory service maintains stock quantities.

These components need to communicate correctly.

During integration testing, a tester might check whether a successful payment response is correctly passed to the order management service.

They could verify that:

The payment service returns a valid transaction response.
The order service receives the response.
The correct transaction reference is recorded.
An error response is handled appropriately.

The main concern is whether the connected components interact according to their interface requirements.

What Changes During System Testing?

System testing looks at the complete application.
Instead of checking only the payment and order services, the tester evaluates the full checkout process against the application's requirements.

For example, a customer:

Logs in.
Selects a product.
Adds it to the shopping cart.
Completes payment.
Receives an order confirmation.
Checks the order in their account.
The tester verifies every expected result.

If payment succeeds but the product inventory does not decrease, the complete system test may fail.

An integration test might also detect this problem if it specifically covers the relevant interaction. The difference is the testing objective and scope, not whether a particular defect belongs exclusively to one level.

Comparing the Two Approaches

Integration testing focuses on connected components.

Its main questions include:

Is information transferred correctly?
Does the receiving component understand the response?
Are errors handled between components?
Do connected services behave according to their contracts?

System testing focuses on the complete application.

Its questions include:

Can users complete important workflows?
Does the application meet its specified requirements?
Do all required results appear correctly?
How does the application behave when actions fail or get interrupted?

Both testing levels are important because they provide different forms of confidence.

Consider a Failed Payment

Suppose a customer attempts to purchase a product, but the payment is declined.

An integration test might verify that the order service receives the correct failure response from the payment provider.

A system test could verify the broader outcome:

The customer sees an appropriate payment failure message.
No confirmed order is created.
Inventory remains unchanged.
The customer can retry payment according to the requirements.
The application does not create duplicate charges.
The system test evaluates the complete business workflow.
This practical distinction is useful when designing test cases. Tester Academy's guide to the system testing process includes an e-commerce example showing how scenarios, expected results and defect reports fit together.
Where Does System Integration Testing Fit?
Another term you may encounter is system integration testing, often shortened to SIT.
In many organisations, SIT focuses on interactions between complete systems, such as an application connected to a payment provider, CRM or ERP platform.
Terminology and boundaries can vary between organisations, so it is important to understand what the project means by each testing level.
System testing still focuses on verifying the integrated application against its overall requirements.
When Should You Perform Each?
Integration testing usually begins once the relevant components are available and can be connected.
System testing generally follows when the application is sufficiently integrated and meets the agreed entry criteria.
In Agile projects, these activities may overlap. Teams can run integration checks and system-level tests throughout development rather than treating them as completely separate phases.
Final Thoughts
Integration testing answers whether connected components communicate and behave correctly together.
System testing answers whether the complete application meets its requirements.
One checks important interactions. The other evaluates the overall product.
Understanding this difference helps testers create clearer test cases and avoid assuming that successful component interactions guarantee a successful user experience.

Integration Testing for APIs, Microservices and Event-Driven Systems

Tester Academy — Tue, 06 Oct 2026 10:50:26 +0000

Modern applications rarely run as one tightly connected system. They depend on APIs, databases, microservices, message queues and third-party services. That makes integration testing more important because many failures happen between components rather than inside them.

A practical integration testing guide should therefore cover how these modern systems communicate, fail and recover.

API Integration Testing

API integration testing checks whether connected services exchange the right data and handle responses correctly.

Important checks include:

Request and response schemas
Status codes
Authentication
Headers
Required fields
Invalid input
Timeouts
Duplicate requests

For example, an order service might send payment information to a payment API. The test should confirm that the correct amount, currency and customer details are sent, and that the application handles approved, declined and failed responses properly.

A successful 200 response is not always enough. The test should also verify whether the expected data was saved and whether the correct downstream actions happened.

Microservices Integration Testing

Microservices create additional risk because different services can be developed and deployed independently.

One service might update its response format while another still expects the old version. Both services may work correctly on their own, but the integration between them breaks.

Integration tests for microservices should check:

Service-to-service communication
API compatibility
Authentication
Dependency availability
Timeouts
Partial failures
Version changes Contract testing can also help by checking whether a service still follows the interface expected by its consumers.

Event-Driven Integration Testing

Event-driven systems work differently because the result may not appear immediately.

A typical flow might be:

Order Service → Message Queue → Inventory Service

The test should not simply wait for a fixed number of seconds. It should wait for the expected condition or event.

Important scenarios include:

Delayed messages
Duplicate events
Events arriving out of order
Failed retries
Dead-letter queues
Idempotency

For example, if the same payment event is delivered twice, the system should not create two orders or charge the customer again.

The goal of integration testing in modern systems is not just to prove that services can connect. It is to verify that data remains correct, interfaces stay compatible, failures are handled safely and asynchronous workflows reach the expected state.

How Exploratory Testing Works in Real Testing Sessions

Tester Academy — Wed, 30 Sep 2026 06:55:26 +0000

Exploratory testing is most effective when testers actively investigate the product instead of following a fixed sequence of predefined steps.

A real exploratory session usually starts with a clear area of focus, but the direction can change as soon as the tester discovers something unexpected.

The aim is not random testing. The tester observes the software, asks questions, tries different actions, and uses each result to decide what to test next.

Start With a Clear Objective

A good exploratory testing session begins with a purpose.
The tester may want to investigate:

A newly released feature
A risky workflow
A recent code change
An area with repeated defects
A user journey that has not been tested deeply

For example, the objective could be to check how a checkout flow behaves when users apply discount codes under different conditions.
This keeps the session focused while still allowing flexibility.

Create a Test Charter

A test charter gives the session direction without turning it into a rigid script.

A simple charter might be:

Explore the checkout page with valid, expired, and repeated discount codes to discover pricing and validation issues.

The charter tells the tester what to investigate, but it does not define every action in advance.

That freedom is important because exploratory testing depends on what the tester discovers during the session.

Explore and Follow the Findings

Once the session starts, the tester begins with the planned area and observes how the software behaves.

Suppose a valid discount code works correctly. The tester may then try an expired code. If that also behaves as expected, the next question might be:

What happens if the cart is changed after the discount is applied?

That result may lead to another test, such as removing an item, changing the quantity, refreshing the page, or applying another code.

Each finding influences the next action.

This adaptive process is what separates exploratory testing from a fixed test script.

Use Testing Techniques During the Session

Exploratory testing does not mean testing without technique.
Testers may use:

Error guessing
Boundary value analysis
Equivalence partitioning
Risk-based exploration
Heuristics
Test tours

For example, if a field accepts a maximum of 50 characters, the tester may try 49, 50, and 51 characters. If a payment form looks risky, the tester may deliberately interrupt the process or enter unusual data.

These techniques help make the session more focused and productive.

Record What Happens

Good exploratory testing should leave useful evidence behind.
During the session, testers can record:

What they tested
What they observed
Defects found
Screenshots
Logs
Reproduction steps
Questions that need follow-up

This makes the session easier to review and gives the rest of the team clear information to act on.

A wider look at test charters, techniques, examples, and the full exploratory testing process can help show how these activities work together.

Review the Session

After testing, the team should review what was covered and what still needs attention.

The tester may identify areas that need another session, defects that should become regression checks, or risks that require deeper testing.

Final Thoughts

Real exploratory testing sessions are structured enough to stay focused but flexible enough to follow new information.

The value comes from observing the software, adapting quickly, and investigating risks that predefined test cases may not fully cover.

When supported by clear objectives, test charters, useful techniques, and proper notes, exploratory testing becomes a practical way to uncover issues that might otherwise remain hidden.

How Does the Beta Testing Process Work?

Tester Academy — Thu, 17 Sep 2026 12:50:49 +0000

Beta testing helps teams understand how software performs when real users try it before a wider release. It usually happens after substantial internal testing and focuses on bugs, usability issues, compatibility, and real-world behaviour.
Beta testing is one of the broader types of software testing used across the development lifecycle, but its main difference is that real or representative users test the product in realistic environments.

1. Define the Testing Goals

Start by deciding what you want to learn from the beta.
The goal may be to find environment-specific bugs, test a new feature, check compatibility, review usability, or confirm stability before release.
Clear objectives make it easier to choose the right testers and collect useful feedback.

2. Prepare the Beta Build

The beta version should be stable enough for users to test important workflows properly.
It does not need to be completely finished, but known critical issues should not prevent users from installing, accessing, or using the product.
An unstable build can result in repetitive feedback about problems the team already knows about.

3. Select Beta Testers

Choose participants who represent the type of users you want feedback from.
Selection may depend on:
Device type
Operating system
Customer segment
Technical experience
Location
Product usage
A small closed beta may involve selected users, while an open beta may include a much larger audience.

4. Set Up Feedback Channels

Users need a simple way to report bugs and share their experience.
Teams can use surveys, bug reporting forms, email, support tickets, in-app feedback, or dedicated beta platforms.
A useful report should explain what happened, what the user expected, the device or environment involved, and the steps needed to reproduce the problem.

5. Run the Beta Test

Once everything is ready, release the build to participants.
Users should be allowed to interact with the software naturally instead of following only strict test cases.
This real-world behaviour is one of the main reasons beta testing can uncover issues missed during internal testing.

6. Review Feedback and Issues

As reports arrive, organise them by severity, frequency, feature, and user impact.
Look for repeated problems rather than treating every report equally.
A bug affecting many users across different environments may require more attention than an isolated issue.

7. Fix and Retest Important Problems

High-priority issues should be investigated and fixed.
After a change is made, verify that the problem is actually resolved. This may require internal regression testing or asking affected beta users to test the same scenario again.

8. Review the Final Results

At the end of the beta, compare the findings with the original goals.
Check whether major workflows work correctly, critical defects are resolved, and enough useful feedback has been collected.
The results help the team decide whether the software is ready for wider release or needs another testing cycle.

Final Thoughts

A good beta testing process is not just about releasing software early. It depends on clear objectives, suitable testers, organised feedback, and proper follow-up.
When managed well, beta testing gives teams a better understanding of how the product behaves before it reaches a larger audience.

Where Alpha Testing Fits in SDLC, Agile, and CI/CD

Tester Academy — Wed, 09 Sep 2026 11:12:47 +0000

Alpha testing usually happens when a product is stable enough for realistic internal testing but has not yet reached external users. Its exact position can vary depending on how the team develops and releases software.

In a traditional SDLC, alpha testing often appears as a distinct stage. In Agile and CI/CD environments, it may work more like an internal release checkpoint that happens repeatedly before selected users receive access.

Where Alpha Testing Fits in the SDLC

In a traditional Software Development Life Cycle, testing activities are often organised into clear stages.

A simplified flow may look like:

Requirements → Development → Unit Testing → Integration Testing → System Testing → Alpha Testing → Beta Testing → Release
Alpha testing generally begins after major system-level problems have been addressed.

By this stage, individual components should work, integrations should be functional, and the application should be stable enough for internal teams to test complete user journeys.

Earlier testing stages have different objectives. Unit testing focuses on individual components. Integration testing checks whether different components communicate correctly. System testing evaluates the complete integrated application against defined requirements.

Alpha testing then focuses more broadly on internal release readiness. Teams examine realistic workflows, usability, integrations, defects, stability, and remaining product risks. A structured Alpha Testing process can help teams evaluate these areas and define suitable exit criteria before moving to beta testing.

Alpha Testing in Agile Development

Agile development changes the way teams think about testing stages.

Instead of waiting until an entire product is finished, teams usually develop and test smaller increments during short iterations.

Because of this, alpha testing may not always appear as one large phase near the end of development.

Teams may conduct internal alpha-style testing whenever a significant feature, release candidate, or product increment becomes ready.

For example, a SaaS team releasing a new subscription system may test the feature internally before exposing it to selected customers.

The process could include:

Testing complete subscription workflows
Checking payment integrations
Evaluating permissions
Running regression tests
Exploring unusual scenarios
Reviewing usability
Resolving critical defects

Once the feature meets internal readiness criteria, it can move to a limited external release.

This makes alpha testing more flexible.

The concept remains the same even if the activity is not formally labelled "Alpha Testing."

The team is still validating product readiness before wider exposure.

How Alpha Testing Works Across Agile Sprints

Testing in Agile should not be postponed until the end of several sprints.

Many alpha-related activities can happen continuously.

During each sprint, teams may test:

New functionality
Integration changes
User workflows
Error handling
Permissions
Regression risk

However, before a major release, teams can bring these activities together into a broader internal readiness review.

This is useful because a feature that works correctly on its own may still fail when combined with other changes introduced across multiple sprints.

For example, changes to authentication, subscriptions, and user roles may individually pass testing but create unexpected behaviour when used together.

Internal alpha testing gives the team an opportunity to examine those complete workflows before external users encounter them.

Alpha Testing in CI/CD Pipelines

CI/CD environments rely heavily on automation.

Every code change may trigger checks such as:

Code Commit → Build → Unit Tests → Integration Tests → API Tests → Regression Tests → Deployment to Staging

Alpha testing can sit after these automated checks.

A possible flow is:

Code → Automated Checks → Integration Environment → Staging → Regression → Internal Alpha → Release Gate → Beta

Automation removes many repetitive and predictable defects before human testers begin broader internal evaluation.

This allows alpha testing to focus on areas automation may not fully cover.

These can include:

Exploratory testing
Complete business workflows
Usability
Unusual user behaviour
Complex failure scenarios
Product experience
Business-risk decisions

CI/CD therefore does not remove the need for alpha testing.

It changes how much preliminary testing can happen automatically.

Where Automation Helps

Automation is especially valuable for repetitive checks.

Teams may use automated tests for:

Smoke testing
Regression testing
API validation
Authentication flows
Browser checks
Integration scenarios
Critical business journeys

These tests can run every time a new build reaches the testing environment.

If a critical automated test fails, the build may never reach internal alpha testing.

This reduces wasted testing effort.

What Still Needs Human Evaluation

Some product risks require human judgement.

A test script can verify that a form submits successfully.

A tester may notice that the form is confusing, gives unclear feedback, or requires unnecessary steps.

Human testers are particularly valuable for:

Exploratory testing
Usability
Unexpected workflows
Error-message clarity
Visual problems
Business-risk assessment

These observations become especially important before real users receive access.

Alpha Testing as a Release Gate

Whether a team follows traditional SDLC, Agile, or CI/CD, alpha testing ultimately serves a similar purpose.

It acts as an internal release gate.

Before moving forward, teams can review:

Critical defects
High-risk workflows
Regression results
Blocked tests
Known limitations
Release-readiness metrics
Stakeholder approval

The exact implementation may change, but the decision remains consistent.

The team needs enough evidence to determine whether the product is stable enough for beta testing or another form of controlled external release.

Final Thoughts

Alpha testing does not need to be a rigid stage that looks identical in every development model.

In traditional SDLC, it may appear as a clearly defined phase before beta testing. In Agile, it can happen repeatedly around release candidates. In CI/CD, automated checks can prepare builds for focused internal evaluation.

What matters is maintaining a controlled point where teams can evaluate real product risk before external users are involved.

Accessibility Testing for Developers: What Automated Tools Miss

Tester Academy — Thu, 27 Aug 2026 12:09:21 +0000

Automated accessibility tools are useful, but they only show part of the picture.
A scanner can identify missing labels, contrast problems, invalid ARIA, and other rule-based issues. What it cannot reliably tell you is whether the interface actually makes sense to someone using a keyboard, screen reader, or another assistive technology.

What Automated Checks Do Well

Tools such as axe, Lighthouse, WAVE, and Accessibility Insights are good for catching issues that can be detected programmatically.
They can quickly flag problems such as missing accessible names, incorrect ARIA attributes, some contrast failures, missing form labels, and structural issues.
This makes them useful during development and regression testing.

Where Automated Scanners Fall Short

Passing an automated scan does not mean the experience is accessible.
A tool may confirm that an image has alt text, but it cannot always judge whether that text is useful. It may see that a button can receive focus, but not whether the focus order makes sense across the full page.
A broader accessibility testing approach is needed to catch issues that depend on context and real user interaction.

Keyboard Testing Still Matters

Developers should test important workflows without using a mouse.
Focus should move in a logical order, remain visible, and reach every interactive control. Menus, modals, dropdowns, and custom components should also work without trapping the user.
Keyboard testing is one of the fastest ways to expose problems that automated tools may miss.

ARIA Needs Human Review

ARIA can improve accessibility when used correctly, but incorrect ARIA can make an interface more confusing.
Automated tools can flag some invalid attributes, but they cannot always judge whether the chosen role, label, state, or relationship matches what the component actually does.
Custom buttons, tabs, dialogs, and expandable elements deserve manual review.

Dynamic Components Need Extra Attention

Many accessibility problems appear only after interaction.
Loading messages, validation errors, notifications, modals, autocomplete results, and live updates may need correct focus handling or screen reader announcements.
These states often look fine visually while remaining unclear to assistive technology.

Manual Verification Completes the Picture

The best workflow combines automation with keyboard testing, screen reader testing, and manual review of important user journeys.
Automated tools are excellent for speed and consistency. Human testing adds context.
The goal is not simply to remove scanner warnings. It is to make sure users can understand the interface, interact with it, and complete the task successfully.

How Developers and Testers Can Run an Ad Hoc Testing Session

Tester Academy — Tue, 25 Aug 2026 11:08:21 +0000

Ad hoc testing allows developers and testers to investigate software without following predefined test cases. It is useful when a feature appears stable but still contains uncertain behaviour.
The approach may be informal, but the session should still have direction. A clear target, limited timeframe, and accurate defect notes make the results more valuable.

Choose One Feature or Risk Area

Avoid starting with the entire application. Choose one feature, integration, recent change, or previously unstable component.
Good targets include:
A recently updated checkout flow
A new user registration form
A feature connected to several APIs
An area with repeated production defects
A critical workflow approaching release
A basic understanding of the ad hoc testing process can help teams keep these informal sessions focused and useful.

Understand the Expected User Flow

Complete the normal user journey before trying unusual actions. This establishes how the feature should behave under expected conditions.
Identify its main inputs, dependencies, permissions, and possible outcomes. Developers can explain technical dependencies, while testers can identify risky user behaviours.
For example, a checkout flow may depend on authentication, inventory, payment processing, and order creation. A failure in any connected component could affect the final result.

Change Inputs, Sequence and System State

Once the expected flow works, start changing one condition at a time. Use missing, incorrect, duplicated, expired, or unusually formatted data.
Change the normal sequence by:
Refreshing during submission
Opening the same action in multiple tabs
Clicking a button repeatedly
Returning to a previous step
Switching accounts during the process
Disconnecting and reconnecting the network
These actions help expose state management, validation, timing, and concurrency problems.

Test Boundaries and Unusual Combinations

Boundary testing works particularly well during ad hoc sessions. Try values immediately below, at, and above the accepted limits.
Combine conditions that formal test cases may treat separately. Test a large file on a slow connection, an expired session during payment, or restricted permissions after changing account roles.
Unexpected combinations frequently reveal defects that individual functional tests cannot detect.

Record Reproducible Defects

Informal testing should not produce informal bug reports. Record enough detail for another team member to reproduce every meaningful problem.
Include:
Device, browser and application version
User role and account state
Test data used
Actions performed
Expected and actual results
Screenshots, logs or recordings
If the precise sequence is unclear, repeat the test before reporting it. A reliable reproduction path saves considerable investigation time.

Convert Important Findings Into Test Cases

Ad hoc testing should improve future structured testing. Convert repeatable, high-risk findings into documented regression scenarios.
Automate the scenario when it is stable, repeatable, and likely to recur. Keep hardware-dependent, visual, or highly variable checks within manual coverage when automation offers little value.
This process prevents the same defect from returning unnoticed.

Keep the Session Short and Focused

Set a clear objective and limit each session to approximately 30 or 45 minutes. Short sessions help participants maintain concentration and produce more useful observations.
End by reviewing the tested conditions, identified defects, unanswered questions, and required regression updates.
Ad hoc testing works best when freedom has a clear boundary. The team explores without a script, but every useful discovery strengthens the broader QA process.