Testing Methodology - Vedantika1509/Ecommerce-website GitHub Wiki
Types of Testing
Unit Testing
In computer programming, unit testing is a software testing method by which individual units of source code, sets of one or more computer modules together with associated control data, usage procedures, and operating procedures are tested to determine whether they are fit for use. Intuitively, one can view a unit as the smallest testable part of an application. In procedural programming, a unit could unit be an entire module, but it is more commonly an individual function or procedure. In object-oriented programming, a unit is often an entire interface, such as a class, but could be an individual method. Unit tests are short code fragments created by programmers or occasionally by white box testers during the development process. It forms the basis for component testing.
Unit testing is commonly automated, but may still be performed manually. The IEEE does not favor one over the other. The objective in unit testing is to isolate a unit and validate its correctness. A manual approach to unit testing may employ a step-by-step instructional document. However, automation is efficient for achieving this, and enables the many benefits listed in this article. Conversely, if not planned carefully, a careless manual unit test case may execute as an integration test case that involves many software components, and thus preclude the achievement of most if not all of the goals for unit testing. As a consequence, unit testing is traditionally a motivator for programmers to create decoupled and cohesive code bodies. This practice promotes healthy habits in software development.
Manual Testing
Manual testing is a technique to test the software that is carried out using the functions and features of an application. In manual software testing, a tester tests the software by following a set of predefined test cases. In this testing, testers make test cases for the codes, test the software, and give the final report about that software.
Automation Testing
Automation testing involves using specialized software tools to execute pre-scripted tests on a software application before it is released into production. Here are some key points about automation testing:
Efficiency and Speed: Automation allows for quicker test execution compared to manual testing. Automated test scripts can be run frequently without human intervention, leading to faster feedback on issues.
Reduced Manual Effort: Repetitive tasks, such as regression testing, are automated, reducing the burden on manual testers. This efficiency becomes crucial as software expands and the number of test cases grows.
Early Issue Detection: Automation helps identify bugs early in the development cycle, allowing teams to address them promptly. This contributes to better software quality.
Cost-Effectiveness: Although there’s an initial effort in creating and maintaining automated test scripts, the long-term benefits outweigh manual testing costs.
Consistency and Reusability: Automated test scripts can be reused across different test cycles, ensuring consistency and accuracy.
System Testing
System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. System testing fails within the scope of black-box testing, and as such, should require no knowledge of the inner design of the code or logic. As a rule, system testing takes, as its input, all of the “integrated” software components that have passed integration testing and also the software system itself integrated with any applicable hardware system(s). The purpose of integration testing is to detect any inconsistencies between the software units that are integrated together or between any of the assemblages and the hardware. System testing is a more limited type of testing; it seeks to detect defects both within the “inter-assemblages” and also within the system as a whole.
System testing is performed on the entire system in the context of a Functional Requirement
Specification(s) (FRS) and/or a System Requirement Specification (SRS). System testing tests not only the design, but also the behavior and even the believed expectations of the customer. It is also
intended to test up to and beyond the bounds defined in the software/hardware requirements
specification(s).
Black Box Testing
Black-box testing is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance. It is sometimes referred to as specification-based testing. Test design techniques: Typical black-box test techniques include: Decision table testing, Equivalence Testing, Boundary Value Analysis, Cause-effect Graph, Error Guessing, State Transition Testing, Use Case Testing, Domain Analysis, Syntax Testing etc. ${\color{red}Black-box\space \ testing\space \ also \space \ known\space \ as\space \ Behavioral\space \ Testing}$ is a software testing method in which the internal structure/design/implementation of the item being tested is not known to the tester. These tests can be functional or non-functional, though usually functional.
White Box Testing
White-box testing also known as clear box testing or glass box testing or transparent box
testing and structural testing is a method of testing software that tests internal structures or
workings of an application, as opposed to its functionality. In white-box testing an internal
perspective of the system, as well as programming skills, are used to design test cases. The
tester chooses inputs to exercise paths through the code and determine the expected outputs.
This is analogous to testing nodes in a circuit. White-box testing can be applied at the unit,
integration and system levels of the software testing process. Although Traditional testers
tended to think of white-box testing as being done at the unit level, it is used for integration
and system testing more frequently today. It can test paths within a unit, paths between units
during integration, and between subsystems during a systemlevel test. Though this method of
test design can uncover many errors or problems, It has the potential to miss unimplemented
parts of the specification or missing diff - text in red requirements.
- text in red
+ text in green
! text in orange
# text in gray
@@ text in purple (and bold)@@
$${\color{red}Red}$$ $${\color{red}Welcome \space \color{lightblue}To \space \color{orange}Stackoverflow}$$