[Testing] Getting Started with Software Testing

Software Testing:

  • is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test (SUT).
  • Can provide an objective, independent view of the software to allow business to appreciate and understand the risk of software implementation.
  • aims to execute a program or application with the intent to find software bugs.
  • is an iterative process as when one bug is fixed, it can illuminate other, deeper bugs, or can even create new ones.

In general, they aim to make sure component of system under test:
  • meets requirements that guided its design and development
  • responds correctly to all kinds of inputs
  • performs its functions within an acceptable time
  • is sufficiently usable
  • can be installed and run in its indented environment
  • achieves the general result its stakeholders desire.

Defects and Failures


  • Not all software defects are caused by coding errors. One common source of expensive defects is requirement gaps, such as unrecognized requirements that result in errors.
  • Requirement gaps can alsop be non-functional requirements, such as testability, scalability, maintainability, usability, performance and security.


Testing Methods

A) Static vs Dynamic testing

static - proofreading code, using IDE for code checking, using compilers.
dynamic - test by running program; using stubs or execution from debugger.

B) "box" approach

Traditionally divided into white- and black-box testing; hybrid is gray-box testing.
These describe the point of view that the tester takes when designing test cases.

i) White box (clear box/transparent box testing) verifies the internal structures or workings of a program, as opposed to the functionality exposed to end-user.
Unit, Integration and system levels of software testing process.

Some examples:

  • API Testing
  • Code coverage
  • Fault Injection (intentionally introduce faults)
  • Mutation Testing
  • Static Testing


Code Coverage
Code coverage tools can evaluate completeness of a test suite that was created with any method, including black-box testing.
Can be reported as:
 - function coverage: reports on functions executed.
 - statement coverage: reports on number of lines executed to complete the test
 - decision coverage: reports on whether both the true and the false branch of a given test has been executed.

ii) Black box (functional testing)
Examining functionality without any knowledge or seeing the source code.
Requires thorough test cases provided to the tester.
QA Testing

iii) Gray box
Combines white- (knowledge of internal structure/code) and black-box testing (functional testing).
Tester has some idea of inner structure.

Example:
A tester may be testing links on a website. If the tester encounters any problem with these links, he can make changes straightaway in HTML code and can check in real time.

Testing Levels

There are 4 levels of testing: 
  1. Unit Testing
  2. Integration Testing
  3. System Testing
  4. Acceptance Testing

i) Unit Testing

Testing the minimal unit of components.
Usually written by developers.
Ensures building blocks of a software works independently from each other.

ii) Integration Testing

Any type of software testing that seeks to verify the interfaces between components against a software design.

iii) System Testing
Tests a completely integrated system to verify the system meets its requirements.
Also called end-to-end testing.
Testing of the user's experience with the application.
Part of black-box testing
Test component interaction within the entire system.

iv) Operational Acceptance Testing (OAT)

Evaluates whether or not an application can be deployed to a network according to IT Infrastructure Library (ITIL) standards.
OAT determines if a software will operate the way it is designed without disrupting the whole installation, network or business that uses it.

OAT focuses on resiliency, recover ability, integrity, manageability and supportability of a software or network installation. Testing performance, security and data loss/recovery are important as well.

Automation of OAT is very important, because nowadays, most software gets update periodically and it continues to function after each update; and that's what the user will expect.


Resources:

https://en.wikipedia.org/wiki/Software_testing#Overview
https://www.guru99.com
https://www.upguard.com/blog/operational-acceptance-testing


Comments

Post a Comment

Popular posts from this blog

[Redis] Redis Cluster vs Redis Sentinel

1) In-Depth Guides to Redis Cluster and Sentinel For more in-depth explanation for Redis Cluster or Redis Sentinel, please read my other posts: Sentinel:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-sentinel.html Cluster:  https://notafraidofwong.blogspot.com/2019/05/redis-redis-cluster.html 2) Deciding between Redis Sentinel and Redis Cluster Similarities : Both solutions provide high availability for your system. 2.1) Redis Cluster 2.1.1) Pros Shards data across multiple nodes Has replication support Has built-in failover of master 2.1.2) Cons Not every library supports it May not be as robust (yet) as Standalone Redis or Sentinel Setup and maintenance is more complicated 2.2) Redis Sentinel 2.2.1) Pros Automatically selects new master in case of failure Easy to setup, (seems) easy to maintain 2.2.2) Cons No data sharding; master might be overutilized. Another distributed system to maintain. 3) So how do I decide? In
Read more

[Unit Testing] Test Doubles (Stubs, Mocks....etc)

Image
In unit testing, isolation is key. The goal of unit testing is to test individual components, and not an entire system . The class/object/function you are testing is System Under Test (SUT) , and the other components of the system are Collaborators or Dependencies. Test Double  is a generic term for any kind of 'pretend' object used in place of a real object for testing purposes.  There are several types of Testing Doubles. We will start with: Fake Stub Mock Command Queries Mocks vs Stubs And then: Dummy Spies Spies vs Mocks I) Basic Testing Doubles a) Fake Fake are objects that have working implementations, but not same as production one. Usually they take some shortcut and have simplified version of production code. Note that Fake is a generic term - that can point to anything; usually mock and stubs. An example of this is an in-memory implementation of a database. This fake implementation will not access the actual database, but will u
Read more

[Node.js] Pending HTTP requests lead to unresponsive nodeJS

This is a recap conclusion to the potential problems of a NodeJS program I worked on previously. The program simulates thousands of clients navigating a website by sending thousands of http requests to a given API . The idea is to load test a particular API to make sure they can handle high traffic. Because we are simulating clients, it's important to keep track of the state of the simulated client as well. The problem with this program is it is buggy and becomes unresponsive from time to time (the only solution is to restart it). The problem was fixed by re-writing the entire program in Java, but it was regretful that I never had enough time to find the exact reason the nodeJS version of it failed. The following are potential causes I suspect: 1. Exceptions The NodeJS program was not written very neatly and stacked callbacks on top of callbacks on top of callbacks. This made it very difficult to keep track of exceptions and unexpected http responses are prone to happen. So
Read more