Manual Software Testing Terminology

In this post ,i am going to explain you all detailed manual testing terminology and their definitions and use of the tools which used in the manual testing  

Manual Software Testing Terminology 

Monkey Testing

A Test Engineer conducting a test on application build through the coverage of main activities only is called monkey testing or chimpanzee testing.

Exploratory Testing

A Tester conducts testing on an application build through the coverage of activities in level by level.

Ad-Hoc Testing

A Tester conducts a test on application build with respect to pre determined ideas is called ad-hoc testing.

Big bang Testing

An organization conducting a single stage of testing after completion of entire modules development is called big bang testing or informal testing.

Incremental Testing

An organization follows the multiple stages of testing process from document level to system level is called incremental testing or formal testing.
Example: LCT (life cycle testing).

Sanity Testing

Whether the build released by the development team is stable for complete testing to be applied or not?

This observation is called sanity testing or tester acceptance testing (TAT) or build verification testing (BVT).

Smoke Testing

An extra shake-up in sanity testing is called smoke testing. In this phase test engineer will try to find the reason when the build is not working before start working.

Static versus Dynamic Testing
A tester conduct a test on application build without running during testing is called static testing.

Example: Usability, Alignment, Font, Style …..Etc.

A tester conduct a test through the execution of our application build is called dynamic testing.
Example: Functional, Performance and Security Testing.

Manual Vs Automation Testing

A Test Engineer conducts a test on application build without using any third party testing tool is called Manual Testing.
A Tester conducts a test on application build with the help of a testing tool is called test Automation Testing.

A Test impact indicates test repetition with multiple test data.

Example: functionality testing.

A Test criticality indicates that complexity to execute the test manually.
Example: load testing.

Re-Testing
The re-execution of a test on same application build with multiple test data is called re-testing.
Ex: multiple
Expected: Result = Input 1 * Input 2

Regression Testing

The re-execution of selected test on modified build to ensure bug fix work and occurrences of side effects is called regression testing.

Error: A mistake in coding is called Error.
                 

Defect: A test engineer found mismatch due to mistakes in coding during testing is called defect or issue.

Bug: A defect accepted by developers to be solved is called Bug.

Testing Documents

Test Policy
It is a company level document and developed by quality control people. (Almost management) this document defines “testing objective” to be achieved.

Address of company
Location of company
Testing Definition: Verification + Validation.
Testing Process: Proper planning before starts testing.
Testing Standard: 1 defect per 250 loc/1defect per 10fp.
Testing Measurements: QAM, TMM, PCM.
Signature of
(C.E.O)
LOC – Lines of code.
FP – Functional point.

Example: No of screens / No of forms / No. of reports / No. of inputs / No. of outputs / No. of queries.

Using functional point we can know the size of project.

QAM – Quality Assessment Measurements.

TMM – Test Management Measurements.

PCM – Process Capability Measurements.

Test Strategy

It is also a company level document and developed by quality analyst people (project manager level). This strategy document defines testing approach to be followed by testing team.

Scope and objective: The purpose of testing in our organization.

Business issues: Budget control for testing

Ex:

Testing approach: mapping between development stages and testing issues. Ex: v-model

 Development Stages

Testing
Issues Information gathering & Analysis Design Coding System Testing Maintenance
Ease of Use
Authorization

Depends on change request
Test Responsibility Matrix (TRM) / Test Matrix (TM)

Test deliverable s: names of testing documents to be prepared by testing team during every project testing.

Roles and responsibilities: names of jobs in testing team and responsibilities of every job during testing.

Communication and status reporting: required negotiation between every two consecutive jobs in testing team.

Test automation and testing tool: purpose of automation and availability of testing tools in your organization.
Defect reporting and tracking: required negotiation between testing team and development team when testers got mismatches in testing.

Testing measurements and metrics: AM, TMM, PCM

Risks and mitigations: expected failures rose during testing and solutions to overcome.

Change and configuration management: how to handle sudden changes in customer requirements during testing.

Training plan: required number of sessions to understand customer requirements by testing team.

TEST FACTORS OR TESTING ISSUES

To define one quality software. Software engineering people are using 15 factors/issues.

Authorization: whether a user is valid or not? To connect to application.

Access control: whether a valid user have permissions to use specific service or not?

Audit trail:  Maintains Meta data about operations.

Continuity of processing: integration of modules.

Correctness
Meet customer requirements in terms of functionality.

Coupling: Co-existence with other software applications to share common resources.

Ease of use: user friendliness of screens.

Ease of operate: Installation, uninstallation, dumping, down loading, up loading,etc.

File integrity: creation of back up during operations.

Reliability: recover from abnormal situations.

Portable: run on different platforms.

Performance: speed of processing.
Service levels: order of functionalities.

Maintainable: whether our application build is long time serviceable to customer site people or not?
Methodology: whether our testing team is following standards or not? (During testing)


Case study

TEST FACTORS VS TESTING TECHNIQUES

Authorization: Security testing (separate testing team)
Functionality/ requirement testing (common testing team)

Access control: Security testing (separate testing team) Functionality/ requirement testing (common testing team)

Audit trail: functionality/ requirement testing

Continuity of processing: integration testing (top down/ bottom up/ hybrid)

Correctness: functionality testing

Coupling: intersystem testing

Ease of use: user interface testing, manual support testing

Ease of operate: installation testing

File integrity: functionality/ requirement testing Recovery testing

Reliability: recovery testing (1 user level) Stress testing (peak load)

Portable: compatibility testing Configuration testing

Performance: load testing, stress testing, storage testing, data volume testing.

Service levels: functionality/ requirements testing (1 user level)
Stress testing (peak load level)

Maintainable: compliance testing

Methodology: compliance testing

Compliance testing
Whether the testing team is following standards or not during testing, is called compliance testing. Compliance means that complete plan.