:::: MENU ::::

Software testing enthusiast.

Software Testing

Software testing is an activity to make sure that the software product meets the expected criteria and to make sure that the software has a minimal defects. Software testing aims to minimize bugs, find a missing requirement, or identify that the software meets acceptance criteria. What activities can be done manually and/or automatically?

Why we need software testing?

We need software testing because bugs in production are either very expensive or dangerous. We can lost our potential customer, sell opportunity, or even cause a disaster. If we can catch the bug earlier than we can fix it sooner before the delivery of the product. Thus the cost will be cheaper.

Software Testing Life Cycle (STLC)

What is STLC?

Software Testing Life Cycle (STLC) is a sequence of systematic and planned activities which are executed during software testing activities. STLC is an important process because it ensure the quality of the software. Different with SDLC, that covers the whole software development process, STLC only covers testing activity.

Software Testing Life Cycle (STLC) has six major steps, which are:

  1. Requirement Analysis
  2. Test Planning
  3. Test Case Development
  4. Test Environment Setup
  5. Test Execution
  6. Test Closure
Each of those step has an entry criteria, activity, deliverable and exit criteria related to it.

Entry criteria are initial conditions that must be met before the test process can be run 

Exit criteria are items that must be completed during the testing process so that testing can be considered complete.

Activity is activities that are carried out during the testing process.

Deliverable is the result that can delivered after the test is finished.

To read more about STLC please follow the link bellow.


6 Major Steps of Software Testing Life Cycle (STLC)

Testing levels

  • Unit testing
  • Integration testing
  • System testing
  • Acceptance testing

Testing types, techniques and tactics

  • Acceptance testing: Make sure that all services is working as intended.
  • Integration testing: Make sure that all components are working together.
  • Unit testing: Checking that function is working in the unit level.
  • Functional testing: Validating the functionality of the services by simulating user behavior or business process. Can be done using black box testing.
  • Performance testing: Checking how the software performs under a ramping up workloads. Can be done using Load testing.
  • Regression testing: Validating that the old menus or services still working after new features are introduced.
  • Stress testing: Testing how much request can be processed before the system is breaking.
  • Usability testing: Validating how well a customer can use a system or web application to complete a task.

White box VS Black box

White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) verifies the internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing, an internal perspective of the system (the source code), as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. While white-box testing can be applied at the unit, integration, and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.

Black-box testing (also known as functional testing) treats the software as a “black box,” examining functionality without any knowledge of internal implementation, without seeing the source code. The testers are only aware of what the software is supposed to do, not how it does it. Black-box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, state transition tables, decision table testing, fuzz testing, model-based testing, use case testing, exploratory testing, and specification-based testing.

Testing Artifact

  • Test Plan
  • Traceability matrix
  • Test case
  • Test script
  • Test suite
  • Test fixture or test data
  • test run

Follow me on

Facebook: https://www.facebook.com/mydoqa/ 

Instagram: https://www.instagram.com/mydoqa/

Twitter: https://twitter.com/MydoQa


Post a Comment

Find this blog interesting? Follow us