DEV Community

Cover image for Software testing topics
G Gokul
G Gokul

Posted on

Software testing topics

Positive test cases:

  • These are ones in which the system being tested is expected to work correctly.
  • These tests are designed to show that the system can handle valid input and produce the expected output.

Negative test cases:

  • These are those in which the system being tested is expected to fail.
  • These tests help ensure that the system can handle invalid input and produce error messages or other appropriate outputs when necessary.

Destructive test cases:

  • These are those in which the system being tested is deliberately broken to test its recovery capabilities. These tests help ensure that the system can deal with unexpected failures and still function properly.

Difference between positive test case and negative test case

n

relationship between test case and test scenario

on

cross functional testing:

  • Cross-functional testing holistically evaluates the functionalities of software systems.
  • It involves product managers, developers, testers, and business analysts from various teams working together to validate the entire system and achieve the desired outcomes.

Unit testing:

  • A unit test is a software testing method where the smallest testable parts of an application, called units (such as individual functions, methods, or classes), are isolated and verified for correctness.
  • Typically written and executed by developers during the coding phase, unit testing acts as the first line of defense to catch bugs early before the code is integrated into larger systems.

Integration testing:

  • Integration Testing is a Software Testing Technique that focuses on verifying the interactions and data exchange between different components or modules of a Software Application.
  • The goal of Integration Testing is to identify any problems or bugs that arise when different components are combined and interact with each other.

System testing:

  • System Testing is a software testing level in which the complete and integrated application is tested as a whole to ensure it meets the specified requirements.
  • It is performed after Integration Testing and before Acceptance Testing to verify the system's overall functionality, performance, and reliability.

Difference between unit, integration and system testing

tion
on

Types of Integration Testing:

1. Big-Bang Integration Testing

  • In Big Bang Integration Testing, all modules are integrated at once and tested together as a complete system.
  • Suitable only for small applications where module count is limited.
  • Difficult to identify the exact root cause when defects occur.
  • No incremental testing, so debugging becomes complex and time-consuming.

2. Bottom-Up Integration Testing

  • In Bottom-Up Integration Testing, lower-level modules are tested first, followed by gradual integration of higher-level modules.
  • Uses test drivers to simulate higher-level modules that are not yet available.
  • Focuses on validating internal module logic and data flow first.
  • Defects in core components are easier to detect and fix early.

3. Top-Down Integration Testing

  • In Top-down Integration Testing, high-level modules are tested first, and lower-level modules are integrated step by step.
  • Uses stubs to simulate lower-level modules during early testing.
  • Helps validate system architecture and major workflows early in development.
  • Ensures critical business logic is tested before full system integration .

4. Mixed Integration Testing

  • A combination of both top-down and bottom-up approaches executed in parallel.
  • Uses both stubs and drivers for simultaneous testing of different layers.
  • Reduces overall testing time by parallel execution of modules.
  • Provides balanced coverage of both high-level and low-level system components.

Difference between top down approach and bottom up approach

I

Test bed:

  • testbed is a controlled, isolated environment containing the specific hardware, software, network configurations, test data, and tools needed to run and validate tests on a system.
  • It allows teams to safely evaluate software or technology under realistic conditions without risking live production systems.

Difference between stub and driver

tion

BRS:

  • BRS stands for Business Requirement Specification (also known as a Business Requirement Document or BRD).
  • In software testing, it is a high-level document that outlines a client's core business goals, expectations, and product scope using non-technical language.

FRS:

  • FRS stands for functional requirement specification โ€” a document that outlines all the functions the software or product must perform.

SRS:

  • SRS stands for Software Requirements Specification.
  • It is a detailed document that acts as a blueprint or roadmap for a software project.
  • It describes what the software will do, how it should perform, and the functional and non-functional requirements it must meet to satisfy both the user and the business.

Difference between Brs,Frs and Srs

on

Difference between error, bug, defect

tion

Cosmetic bugs:

Cosmetic bugs are minor visual flaws in software that affect the look or layout of a user interface but do not stop the program from working.

will developer do testing?

  • Yes, developers do test code, but they mostly focus on unit tests and component checks rather than full system quality assurance.
  • Software teams typically use a shared approach where developers handle initial code validation, while dedicated testers handle broader scenarios.

Early testing is good.justify

Early testing is a vital practice that saves money, time, and effort by catching design mistakes and code bugs when they are first made, rather than waiting until the end of a project.

Top comments (0)