Skip to main content

Terms

A​

B​

C​

D​

E​

Exploratory testing is a form of testing that is done without a plan. In an exploratory test, you're just exploring the application. To have a complete set of manual tests, all you need to do is make a list of all the features your application has, the different types of input it can accept, and the expected results. Now, every time you make a change to your code, you need to go through every single item on that list and check it.

F​

Fuzz testing is a software testing technique using which a random data is given as the inputs to the system. If the application fails, then those issues/defects are to be addressed by the system. In short, unexpected or random inputs might lead to unexpected results

Attack Types​

  • Number/Character Fuzzing
  • Application Fuzzing
  • Protocol Fuzzing
  • File Format Fuzzing

https://github.com/minimaxir/big-list-of-naughty-strings

https://www.freecodecamp.org/news/whats-fuzzing-fuzz-testing-explained

G​

H​

I​

K​

L​

M​

https://medium.com/analytics-vidhya/unit-testing-in-python-mutation-testing-7a70143180d8

N​

O​

P​

"Pentest" is short for "penetration test", and involves having a trusted security expert attack a system for the purpose of discovering, and repairing, security vulnerabilities before malicious attackers can exploit them. This is a critical procedure for securing a system, as the alternative method for discovering vulnerabilities is to wait for unknown agents to exploit them. By this time it is, of course, too late to do anything about them. In order to keep a system secure, it is advisable to conduct a pentest on a regular basis, especially when new technology is added to the stack, or vulnerabilities are exposed in your current stack.- Performance Testing

Q​

R​

S​

Smoke Testing​

Also called as Build Verification Testing or Confidence Testing or Build Acceptance Testing

They're used as a sanity check that your site's core functionality isn't wrecked.

Smoke Testing is a testing technique that is inspired from hardware testing, which checks for the smoke from the hardware components once the hardware's power is switched on. Similarly in Software testing context, smoke testing refers to testing the basic functionality of the build.

If the Test fails, build is declared as unstable and it is NOT tested anymore until the smoke test of the build passes.

Smoke Testing - Features​

  • Identifying the business critical functionalities that a product must satisfy.
  • Designing and executing the basic functionalities of the application.
  • Ensuring that the smoke test passes each and every build in order to proceed with the testing.
  • Smoke Tests enables uncovering obvious errors which saves time and effort of test team.
  • Smoke Tests can be manual or automated.

Smoke Testing - Software Testing - GeeksforGeeks

T​

U​

V​

W​

https://dev.to/maxwell_dev/the-testing-introduction-i-wish-i-had-2dn

https://dev.to/conw_y/towards-zero-bugs-1bop

Testing terms​

  • Code Freeze
  • Code Inspection
  • Code Review
  • Code Walkthrough
  • Code Based Testing
  • Code Driven Testing
  • Code Free Testing
  • Comparison Testing
  • Combatibility Testing
  • Compliance Testing
  • Concurrency Testing
  • Configuration Testing
  • Conformance Testing
  • Context Driven Testing
  • Control Flow Path
  • Conversion Testing

https://www.tutorialspoint.com/software_testing_dictionary/index.htm

API Testing​

  • Smoke Testing - This is done after API development is complete. Simply validate if the APIs are working and nothing breaks.
  • Functional Testing - This creates a test plan based on the functional requirements and compares the results with the expected results.
  • Integration Testing - This test combines several API calls to perform end-to-end tests. The intra-service communications and data transmissions are tested.
  • Regression Testing - This test ensures that bug fixes or new features shouldn’t break the existing behaviors of APIs.
  • Load Testing - This tests applications’ performance by simulating different loads. Then we can calculate the capacity of the application.
  • Stress Testing - We deliberately create high loads to the APIs and test if the APIs are able to function normally.
  • Security Testing - This tests the APIs against all possible external threats.
  • UI Testing - This tests the UI interactions with the APIs to make sure the data can be displayed properly.
  • Fuzz Testing - This injects invalid or unexpected input data into the API and tries to crash the API. In this way, it identifies the API vulnerabilities.

api-testing

White box vs Black box vs Grey box testing​

Black Box Testing​

  • Definition: In black box testing, the tester evaluates the software's functionality without any knowledge of its internal workings. The focus is on the input that goes into the software and the output that is produced, not on how the input is processed.
  • Key Characteristics:
    • External Perspective: Testers do not need to know programming languages or how the software was implemented.
    • Focus on Specifications: Testing is based on software requirements and specifications.
    • Examples of Techniques: Functional testing, non-functional testing (like performance testing), and user acceptance testing (UAT).

White Box Testing​

  • Definition: White box testing, also known as clear or transparent testing, involves thorough insight into the internal logic, structure, and code of the software. The tester knows the internal paths, structures, and implementation of the software.
  • Key Characteristics:
    • Internal Perspective: Requires knowledge of the software's internal workings, including programming languages and architecture.
    • Focus on Code: Tests are based on coverage of code statements, branches, paths, and conditions.
    • Examples of Techniques: Unit testing, integration testing (to some extent), and static code analysis.
  • Requirements
    • Technology used (coding language)
    • Number of repositories
      • No of files (in source code) in each repository
      • No of total lines of code in each repository
    • For white box we need code review and unit testing

What is White Box Testing? (Example, Types, & Techniques) | BrowserStack

SonarQube​

SonarQube primarily focuses on static code analysis and code quality management rather than white-box testing. White-box testing typically involves examining the internal structures and workings of an application or system. This is often done through techniques such as code review, unit testing, and other forms of testing that require access to the source code.

While SonarQube can help in identifying code issues, vulnerabilities, and bugs through static analysis, it doesn't directly perform white-box testing. However, it can complement white-box testing practices by providing insights into code quality, security vulnerabilities, and adherence to coding standards. It's often used in conjunction with other testing tools and methodologies to ensure comprehensive code quality and security coverage.

Gray Box Testing​

  • Definition: Gray box testing is a hybrid approach that combines elements of both black box and white box testing. Testers have partial knowledge of the internal workings of the software, which guides their testing strategy.
  • Key Characteristics:
    • Semi-internal Perspective: Testers are aware of some aspects of the internal workings but do not have full access to the source code.
    • Balanced Focus: While it considers internal structures, it still emphasizes external functional behavior.
    • Examples of Techniques: Integration testing, specialized testing (like security testing), and regression testing.

Comparison and Use Cases​

  • Use Case Sensitivity:
    • Black Box: Ideal for general functionality testing and for testers who are not programmers.
    • White Box: Best suited for detecting hidden errors in specific modules or assessing the thoroughness of existing tests.
    • Gray Box: Effective for situations where understanding both the application’s purpose and its internal operations can lead to more comprehensive testing, such as in security or integration scenarios.

Selection Criteria​

The choice among black box, white box, and gray box testing depends on several factors, including the objectives of the testing, the resources available, the stage of development, and the specific requirements of the software being tested. Each approach has its advantages and limitations, and often, a combination of these testing methodologies is employed to achieve a well-rounded verification and validation of software quality.