Archive for the ‘Testing Technique’ Category

Difference between Sanity and Smoke Testing:

Smoke Testing:

  • When a build is received smoke testing is done to ensure that whether the build is ready or stable for further testing.
  • Smoke testing is a wide approach where all areas of software application are tested without getting into deeper.
  • Test Cases for smoke testing can be manual or automated.
  • A smoke test is basically designed to touch each and every part of an app in a cursory way.
  • Smoke testing is Shallow and wide.
  • Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details.
  • Smoke testing is like General Health Check Up

Sanity Testing:

  • After receiving a software build, with minor changes in code, or functionality, Sanity testing is performed to ascertain that the bugs have been fixed and no further issues are introduced due to these changes. The goal is to determine that the proposed functionality works roughly as expected.
  • Sanity testing exercises only the particular component of the entire system.
  • A sanity test is usually unscripted and without test scripts or test cases.
  • Sanity Testing is narrow and deep
  • Sanity testing is to verify whether requirements are met or not, checking all features breadth-first
  • Sanity Testing is like specialized health check up
Advertisements

Software Testing Techniques/Methods:

There are different types of techniques and methodologies involved in this testing; both mean different things.

White box testing: White box testing is done by the Developers. This requires knowledge of the internal coding of the software.

White box testing is concerned with testing the implementation of the program. The intent of this testing is not to exercise all the different input or output conditions, but to exercise different programming structures and data structures used in the program. It is commonly called structural testing.

White box testing mainly applicable to lower levels of testing: Unit testing and Integration Testing.

Implementation knowledge is required for white box testing.

Black box testing:

Black box testing is done by the professional testing team. This does not require knowledge of internal coding of the application. Testing the application against the functionality of the application without the knowledge of internal coding of the software.

In Black box testing the structure of the program is not considered. Test cases are decided solely on the basis of the requirements or specification of the program or module.

Black box testing mainly applicable to higher levels of testing: Acceptance Testing and System Testing.

Implementation knowledge is not required for black box testing.

Gray box testing:

A combination of Black Box and White Box testing methodologies: testing a piece of software against its specification but using some knowledge of its internal workings. It can be performed by either development or testing teams.In gray box testing tester applies a limited no of test cases to the internal working of the software under test. In remaining part of gray box testing one takes a black box approach in applying inputs to the software under test and observing the outputs.

Unit testing:

The first test in the development process is the unit test. Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Unit test depends upon the language on which the project is developed.

Integration testing:

Testing in which modules are combined and tested as a group. Modules are typically code modules, individual applications, client and server applications on a network, etc. Integration Testing follows unit testing and precedes system testing.

Regression testing:

Testing the application as a whole for the modification in any module or functionality. Such testing ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process.

Usability testing:

Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing.

Performance testing:

Functional testing conducted to evaluate the compliance of a system or component with specified performance requirements. It is usually conducted by the performance engineer. Performance testing will determine whether or not their software meets speed, scalability and stability requirements under expected workload.

Types of performance testing:

Load testing

Stress testing

Volume testing

Scalability testing

Endurance testing

Spike testing

Load testing- Load testing is the simplest form of performance testing .Load testing is a generic term covering Performance Testing and Stress Testing. Testing technique that puts demand on a system or device and measures its response. It is usually conducted by the performance engineers.

Stress testing- Stress testing is normally used to understand the upper limits of capacity within the system Testing technique which evaluates a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. It is usually conducted by the performance engineer.

Or

Stress testing involves testing an application under extreme workloads to see how it handles high traffic or data processing .The objective is to identify breaking point of an application.

Volume testing- testing which confirms that any values that may become large over time (such as accumulated counts, logs, and data files), can be accommodated by the program and will not cause the program to stop working or degrade its operation in any manner. It is usually conducted by the performance engineer.

Endurance testing- It is also known as soak testing. Type of testing which checks for memory leaks or other problems that may occur with prolonged execution. It is usually performed by performance engineers.

Scalability testing– The objective of scalability testing is to determine the software application’s effectiveness in “scaling up” to support an increase in user load. It helps plan capacity addition to your software system.

Spike testing- tests the software’s reaction to sudden large spikes in the load generated by users i.e.  Spike testing is done by suddenly increasing the number of, or load generated by, users by a very large amount and observing the behavior of the system. The goal is to determine whether performance will suffer, the system will fail, or it will be able to handle dramatic changes in load.

Recovery testing:

Testing technique which evaluates how well a system recovers from crashes, hardware failures, or other catastrophic problems. It is performed by the testing teams.

Security Testing:

A process to determine that an information system protects data and maintains functionality as intended. It can be performed by testing teams or by specialized security-testing companies. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks.

Conformance testing:

Verifying implementation conformance to industry standards. Producing tests for the behavior of an implementation to be sure it provides the portability, interoperability, and/or compatibility a standard defines.

Smoke testing:

Testing technique which examines all the basic components of a software system to ensure that they work properly. Typically, smoke testing is conducted by the testing team, immediately after a software build is made .

Compatibility testing:

Testing to ensure compatibility of an application or Web site with different browsers, OSs, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.

System testing:

Testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.

Alpha testing:

Type of testing a software product or system conducted at the developer’s site. Usually it is performed by the end user. Testing is done at the end of development.

Beta testing:

Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.

Acceptance testing:

Testing to verify a product meets customer specified requirements. A customer usually does this type of testing on a product that is developed externally.

Comparison testing:

Comparison of product strengths and weaknesses with previous versions or other similar products.

Sanity testing:

Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix.

Ad-hoc Testing:

Testing performed without planning and documentation – the tester tries to ‘break’ the system by randomly trying the system’s functionality. It is performed by the testing teams.

Difference between white box testing and black box testing:

White box testing:

  • White box testing is done by the Developers. This requires knowledge of the internal coding of the software.
  • White box testing is concerned with testing the implementation of the program. The intent of this testing is not to exercise all the different input or output conditions, but to exercise different programming structures and data structures used in the program. It is commonly called structural testing.
  • White box testing mainly applicable to lower levels of testing: Unit testing and Integration Testing.
  • Implementation knowledge is required for white box testing.

Black box testing:

  • Black box testing is done by the professional testing team. This does not require knowledge of internal coding of the application. Testing the application against the functionality of the application without the knowledge of internal coding of the software.
  • In Black box testing the structure of the program is not considered. Test cases are decided solely on the basis of the requirements or specification of the program or module.
  • Black box testing mainly applicable to higher levels of testing: Acceptance Testing and System Testing.
  • Implementation knowledge is not required for black box testing.