:::: MENU ::::

Software testing enthusiast.

7 Principles Of Software Testing

Software testing is an important activity. It provides certain level of confidence with the product. That level of confidence achieved through a series of testing activities. Software testing activities is a procedures that are executed to catch bugs, errors, defects as early as possible, ensure that the product meets acceptance criteria, and the completeness of specifications in accordance with business, user, and product requirements.

To run that procedures, we need to have a strategy, so our testing activities will not take too long time but still optimum enough to reach the goal.

How can we develop a good strategy? Or Base on what we develop that strategy? One of the rules that have been proven to be used as a basis for building strategy is 7 Principles Of Software Testing.

In this article, we’ll take a look at what is 7 Principles Of Software Testing and its component, one-by-one.


7 Principles Of Software Testing

1. Testing shows presence of defects

Presence of defects

The purpose of software testing is to reduce bugs occurrence in software using various methods and techniques. By doing series of testing procedures, it detect the presence of bugs or defects . Software testing can only ensure that bugs are present, not those that are absent. Even after we execute test endlessly, it is impossible to be sure that the software is completely bugs-free.

2. Exhaustive testing is not possible

Exhaustive testing

It is a practice of testing a software using all possible inputs and preconditions. It is very difficult to test all modules and their functionality with valid and invalid combinations of input data throughout the testing process.

Imagine an input field that accept age information, we need to execute test using 1, 2, 3, 4, 5, and so on. And don’t forget to also test it using invalid value, such as a-z, A-Z. It is a very time consuming procedure and very not cost effective.

3. Early testing

Early testing

Testing should start as early as possible so that any possible defect can be captured in early stage. It is less costly to fix defect in the beginning. But how early it should be performed? Once we get the requirement.

4. Defect clustering

Defect clustering

Defect clustering state that the most bugs will detected in a small number of modules. Usually it follows the Pareto 20/80 law. About 80% bugs will be found in about 20% of modules.

5. Pesticide paradox

Pesticide paradox

Imagine a farmer that are using the same type and doses of pesticide to spray bugs, again and again repetitively, eventually bugs will develop immunity to that kind of pesticide. The same thing happened to software testing. If the same methods and approaches are used repetitively, the method will be useless to catch a new bugs.

To overcome this, the test case needs to be evaluated and replaced periodically. Also, tester need to be more creative and run the test outside the test case.

6. Testing is context dependent

Context dependent

Software testing is not a one-for-all scenarios. It is important to design tests based on the context of software development. Different strategies, methods, and kinds of testing are utilized relying upon the idea of an application. For example, software for the aviation industry requires more detailed, thorough and thorough testing than the company’s website. And e-commerce page will require different test than login form.

7. Absence of errors fallacy

Absence of errors fallacy

Although software is 99% bug-free, it is still possible that the software cannot be used at all. It is still important that the software must be practical and able to accomplish the client’s requirements and needs.

Conclusion

Based on what we have learned together, 7 Principles Of Software Testing can help us gain greater efficiency, focus, and also improve our strategy for designing testing scenario.

Follow me on

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

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

Twitter: https://twitter.com/MydoQa

Resources

[embed]https://www.guru99.com/software-testing-seven-principles.html[/embed][embed]https://www.guru99.com/software-testing-seven-principles.html[/embed][embed]https://www.guru99.com/software-testing-seven-principles.html[/embed][embed]https://www.guru99.com/software-testing-seven-principles.html[/embed][embed]https://www.guru99.com/software-testing-seven-principles.html[/embed]

One of the tasks of the software tester is to tell bug occurrences to the software developer. A bug is bad news. And just like other bad news, people tend to avoid it. Some people will feel uneasy if they hear that there is bad news in the code.

The wrong communication feedback will bring a wrong response. Of course, we are familiar with defensive responses like, — “It is working on my machine.”, “It must be from another service, go check somewhere else.” , “It didn’t happen when I follow your step to reproduce.”— and something similar. Those reactions could affect the productivity of a company.

As software testers, we don’t want to get a reaction similar to that or even worse, make it. So, what is the better communication approach? How to tell bad news without making any anxiety?

I’m proposing the use of the Situation-Behavior-Impact framework.

What is the Situation-Behavior-Impact framework?

It is a direct, non-judgmental, and widely-recognized model for delivering feedback. Situation-Behavior-Impact or SBI is proven to reduce the anxiety of delivering feedback and also reduce the defensiveness of the recipient.

The Situation-Behavior-Impact method is simple and direct: You capture and clarify the Situation where bugs occur, describe the specific Behaviors observed, and explain the Impact of the behavior of the bug on the software.


How You Can Use Situation-Behavior Impacts to tell bug occurrence?

1. Situation:

Describe the specific situation/environment in which the bug occurred. Avoid generalities, such as “in my browser…, in my machine…” as that can lead to confusion. Often bugs only happen in certain environments so it is good to be as specific as possible. Make sure to list the operating system or browser you are using, and if applicable, which version of software and hardware you are using.

  • Example: “In Firefox browser version 105.6.1 64 bit…”

2. Behavior:

Describe the actual, observable behavior. Keep to the facts. Avoid using ambiguous terms such as “not working, broken”. Be more specific, write every detail that you can get.

  • Example: “…When I click the ‘search’ button the browser is not responding.

But don’t forget to write down the expected behavior.

  • Example: “…When I click the search button, the item I’m looking for should appear.

3. Impact:

Describe the results of the behavior. Because you’re describing exactly what happened and explaining the real impact of the bug, a developer will be less likely to feel offended and react positively.

So how to state the impact of bug behavior? You can follow this example.

  • Example: “…When I click the ‘search’ button the browser is not responding. It causes memory usage to spike sharply.”

The success of the Situation-Behavior-Impact will minimize the negative reaction. If the reaction is positive, then productive cooperation can be continued. And you can resolve the bug along with the software developer rather quickly and with less drama.

Please bear in mind, writing bug reports follows a different format, I will write a format to create bug reports in a different story. This approach is useful to tell bug occurrence in a written form or verbally.

Follow me on

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

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

Twitter: https://twitter.com/MydoQa

Resources

[embed]https://www.ccl.org/articles/leading-effectively-articles/closing-the-gap-between-intent-vs-impact-sbii/[/embed][embed]https://www.ccl.org/articles/leading-effectively-articles/closing-the-gap-between-intent-vs-impact-sbii/[/embed][embed]https://www.ccl.org/articles/leading-effectively-articles/closing-the-gap-between-intent-vs-impact-sbii/[/embed]

In this article I will show how to create basic request in postman.

Basic Features

Before creating postman request, first let me show you postman basic features. I will show features like

  • Params — Allows you to add query parameter in request URL
  • Authorization — It might be basic authentication, bearer token, or just simply username and password
  • Headers — Where you will write needed header for the request
  • Body — This is where you put customization values.
  • Pre-request Script — Executed before running the request. You can add environment variables or test preconditions here.
  • Tests — This is where you put our assertion script for the test. It is important to add assertion for each request so we know whether the request is succeed or not.

Create Our Request

Now after we know Postman’s basic features, we are ready to create our first postman request. For this article’s simulation I will use demo site from dummyjson. You can access the swagger here:

[embed]https://dummyjson.com/docs/products[/embed]

For this simulation I will use endpoint “Add a new product”. This endpoint will simulate POST request and mock a create new product behavior.

Add a new product simulation
  1. Create a Collection to organize our request — Yes we can create single request without a collection, but a collection will help us to make our request more well organized. We also can group our collection into folders under the same category, such as: Setup, Positive Cases, Negative Cases, and Cleanup.
Collection creation

2. Create request — In this step we will create a request. To create a request within a collection, click triple dot from collection then Add Request. Write down Request name and Request description (Optional). Click “Save to HTTP Method”.

Request creation

3. After request is created then we are ready to make a postman request.

{
“titles”: “BMW Pencil”
}
Request body

4. Click “Send” button — After this step is executed we already get the result whether fail or success. In this simulation the request return 200 as response code and “id”: 101 as response body.

Request response

5. Test Assertion — now, after we get the response code and response body, we need to assert the test to assure endpoint returned expected response.

  • To add assertion, click “Tests” tab
  • For this simulation, create an assertion using snippets is enough. So move to snippets and choose on of them.
Test Snippets
  • I will assert this request using two snippets, ”Status code is 200" and “Response body: JSON value check”.
  • Click those snippets. Now we will have two code blocks. The first block is good enough, so we will work on the second block. String “Your test name” can be changed into any string you desire, so I will change it into “Product id is 101”. Because returned Json key is “id” and the value is 101, so we will change “pm.expect(jsonData.value).to.eql(100);” into “pm.expect(jsonData.id).to.eql(101);”
  • I think it is good enough now. Click “Send” button again.
  • In the response click “Test Results” and we will get two results ”Status code is 200" and “Product id is 101”. And both of them are PASS. Those results are from previous test block.

That’s how we create basic API test using Postman. This test is simulating positive scenario. Maybe I will write about how to create negative scenario in the next article.

Thanks for reading.

Follow me on

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

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

Twitter: https://twitter.com/MydoQa

Resources

[embed]https://dummyjson.com/docs/products[/embed]

In this tutorial I will share how to assert jwt token in the response body. To simulate API behavior, I will use dummy API server from dummyjson.com. You can access the website using the link below:

[embed]https://dummyjson.com/docs/auth[/embed]

In this simulation, I will use endpoint “Login user and get token”. This endpoint is using POST method. For how to test http method using postman you can follow the instruction from the article below:

[embed]https://dummyjson.com/docs/auth[/embed]

The figure below is the response body for “Login and get token” endpoint. We want to assert the jwt content from “token” field.

Login and get token response body

To do that we can use atob(). To use it you can write down the following script in the “Tests” tab.

jsonData=JSON.parse(responseBody);
const payload = jsonData.token.split(‘.’)[1];
const parsed = atob(payload);
console.log(parsed);

After we hit send button, postman will return log that contains the jwt content. Then we can assert tho content values.

Postman log

To assert jwt token we can add following test script:

pm.test(“Jwt should include username”, function () {
pm.expect(parsed).to.include(“\”username\”:\”kminchelle\””)
});

We can assert another field by adding pm.expect script within the pm.test block, for example jwt token should contain field “firstname” with value “Jeanne“. We can add test script as following:

pm.test(“Jwt should include username”, function () {
pm.expect(parsed).to.include(“\”username\”:\”kminchelle\””)
pm.expect(parsed).to.include(“\”firstName\”:\”Jeanne\””)
});
Login and get token test result

Thanks for reading this article.

Follow me on

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

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

Twitter: https://twitter.com/MydoQa

Photo by Rubaitul Azad on Unsplash

In this tutorial I will show you what HTTP methods are and how to test them. The methods used in this article are: POST, PUT, GET, DELETE.

  • POST is used to send data to a server to create a resource.
  • PUT is used to send data to a server to update a resource.
  • GET is used to fetch data from a specified resource.
  • DELETE method deletes the specified resource.

Dummy API

This article is using dummy API server provided by DummyJSON.

[embed]https://dummyjson.com/docs[/embed]

API Request

POST

This method will send data to the resource and create a new product called “BMW Pencil”. To do that in Postman, just create new request, ensure the method is POST, Insert the URL of the endpoint. In this simulation, the URL is “https://dummyjson.com/products/add”. In the Body tab, choose “raw” button and choose JSON, and then type:

{
"title": "BMW Pencil"
}
POST Request
  • Request

To make request using Curl you can see the following code. Just import the curl to Postman.

curl --location --request POST 'https://dummyjson.com/products/add' \
--header 'Content-Type: application/json' \
--data-raw '{
"title": "BMW Pencil"
}'
  • Response

After all necessary parameter is fulfilled, click “Send” button, then we’ll get following response body.

{
"id": 101,
"title": "BMW Pencil"
}

PUT

This method will send data to the resource and update a product “1” and change the title into new value “iPhone Galaxy +1”. To do that in Postman, just create new request, ensure the method is PUT, Insert the URL of the endpoint. In this simulation, the URL is “https://dummyjson.com/products/1”. In the Body tab, choose “raw” button and choose JSON, and then type:

{
“title”: “iPhone Galaxy +1”
}
PUT Request
  • Request

To make request using Curl you can see the following code. Just import the curl to Postman.

curl — location — request PUT ‘https://dummyjson.com/products/1' \
--header ‘Content-Type: application/json’ \
--data-raw ‘{
“title”: “iPhone Galaxy +1”
}’
  • Response

After all necessary parameter is fulfilled, click “Send” button, then we’ll get following response body.

{
“id”: “1”,
“title”: “iPhone Galaxy +1”,
“price”: 549,
“stock”: 94,
“rating”: 4.69,
“images”: [
“https://dummyjson.com/image/i/products/1/1.jpg",
“https://dummyjson.com/image/i/products/1/2.jpg",
“https://dummyjson.com/image/i/products/1/3.jpg",
“https://dummyjson.com/image/i/products/1/4.jpg",
“https://dummyjson.com/image/i/products/1/thumbnail.jpg"
],
“thumbnail”: “https://dummyjson.com/image/i/products/1/thumbnail.jpg",
“description”: “An apple mobile which is nothing like apple”,
“brand”: “Apple”,
“category”: “smartphones”
}

GET

This method will fetch phone data from the resource. To do that in Postman, just create new request, ensure the method is GET, Insert the URL of the endpoint. In this simulation, the URL is “https://dummyjson.com/products/search?q=phone”.

GET Request
  • Request

To make request using Curl you can see the following code. Just import the curl to Postman.

curl --location --request GET 'https://dummyjson.com/products/search?q=phone'
  • Response

After all necessary parameter is fulfilled, click “Send” button, then we’ll get following response body.

{
"products": [
{
"id": 1,
"title": "iPhone 9",
"description": "An apple mobile which is nothing like apple",
"price": 549,
"discountPercentage": 12.96,
"rating": 4.69,
"stock": 94,
"brand": "Apple",
"category": "smartphones",
"thumbnail": "...",
"images": ["...", "...", "..."]
},
{...},
{...},
{...}
// 4 results
],
"total": 4,
"skip": 0,
"limit": 4
}

DELETE

This method will DELETE data with product id “1” from the resource. To do that in Postman, just create new request, ensure the method is DELETE, Insert the URL of the endpoint. In this simulation, the URL is “https://dummyjson.com/products/1”.

DELETE Request
  • Request

To make request using Curl you can see the following code. Just import the curl to Postman.

curl — location — request DELETE ‘https://dummyjson.com/products/1'
  • Response

After all necessary parameter is fulfilled, click “Send” button, then we’ll get following response body.

{
"id": 1,
"title": "iPhone 9",
"description": "An apple mobile which is nothing like apple",
"price": 549,
"discountPercentage": 12.96,
"rating": 4.69,
"stock": 94,
"brand": "Apple",
"category": "smartphones",
"thumbnail": "...",
"images": ["...", "...", "..."],
"isDeleted": true,
"deletedOn": /* ISOTime */
}

Follow me on

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

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

Twitter: https://twitter.com/MydoQa

RESOURCE

[embed]https://dummyjson.com/docs[/embed]

Software Testing Life Cycle

In this article I will write about Software Testing Life Cycle or STLC model.

What is it?


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.

STLC Phases


Requirement Analysis: Requirement Analysis is the very first step in Software Testing Life Cycle (STLC). At this stage, the quality assurance (QA) team understands the requirements, like acceptance criteria or what to test. If something is missing or unclear, the quality assurance team meets with stakeholders to gain a better understanding of the requirements in detail. QA can decide whether software require manual or automation testing.

  • Entry Criteria: Requirement specification, acceptance criteria, application architectural.

  • Activity: Identify types of tests to be performed, Gather details about testing priorities and focus, Automation feasibility analysis (if required).

  • Deliverable: List of all testable requirements, Automation feasibility report (if applicable).

  • Exit Criteria: Signed off RTM, Signed off Automation feasibility report.


Test Planning: Test planning is the stage where QA manager/QA lead define testing strategy and make an estimation on effort and cost needed for the entire life cycle.

The team will decide on the required tools, roles, and training (if needed) for the project, etc.

  • Entry Criteria: Requirements Documents.

  • Activity: Preparation of test plan/strategy document for various types of testing, Test tool selection, Test effort estimation, Resource planning and determining roles and responsibilities, Training requirement.

  • Deliverable: Test Strategy, Test Plan, and Test Effort estimation document.

  • Exit Criteria: Approved Test plan document, Approved Test strategy document, Signed off effort estimation document.


Test Case Development: The test case development phase is started soon after the test planning phase is finished. In this phase, QA Team will create a test case. They also identify, create, review, and rework Test data based on the preconditions. If the test require automation test, QA team also create test scripts for the automation test.

  • Entry Criteria: Requirements Documents (Updated version of unclear or missing requirement).

  • Activity: Create test cases, automation scripts (if applicable), Review and baseline test cases and scripts, Create test data.

  • Deliverable: Test cases, Test Scripts (if automation), Test data.

  • Exit Criteria: Reviewed and approved test cases, test scripts, test data.


Test Environment Setup: Test environment setup is the critical part of the STLC. This phase aims to ensure readiness of the environment on which software is tested. QA team is responsible for the testing environment, sometime they work together with Dev team, SysOps or DevOps team. To check the readiness, QA team can use smoke test.

  • Entry Criteria: Test Plan, Smoke Test cases, Test Data.

  • Activity: Understand and prepare the required environment set-up, Perform smoke test on the build.

  • Deliverable: Test Environment. Smoke Test Results.

  • Exit Criteria: Working test environment setup, Valid test data setup, Successful smoke test.


Test Execution: After all those preparation, the QA team finally do the actual test. In this phase QA team start executing test cases based on test cases and test plans from the earlier phases.

  • Entry Criteria: Test Plan document, Test cases, Test data, Test Environment.

  • Activity: Execute tests as per plan, Document test results, and log defects for failed cases, Track the defects to closure.

  • Deliverable: Test case execution report, Defect report.

  • Exit Criteria: Execute all planned test cases, Log all defects found.


Test Closure: This is the end of the life cycle. The test is completed, test report is collected. QA team will analyze defect distribution by type and severity.

  • Entry Criteria: Test Case Execution report (make sure there are no high severity defects opened), Defect report.

  • Activity: Evaluate cycle completion criteria, Document the learning out of the project, Prepare Test closure report, Test result analysis to find out the defect distribution by type and severity.

  • Deliverable: Test Closure report, Test metrics.

  • Exit Criteria: Signed off Test Closure report.


Follow me on


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

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

Twitter: https://twitter.com/MydoQa

Resource


[embed]https://www.geeksforgeeks.org/software-testing-life-cycle-stlc/[/embed]

[embed]https://www.geeksforgeeks.org/software-testing-life-cycle-stlc/[/embed]

[embed]https://www.geeksforgeeks.org/software-testing-life-cycle-stlc/[/embed]

[embed]https://www.geeksforgeeks.org/software-testing-life-cycle-stlc/[/embed]

[embed]https://www.geeksforgeeks.org/software-testing-life-cycle-stlc/[/embed]

[embed]https://www.geeksforgeeks.org/software-testing-life-cycle-stlc/[/embed]

In this tutorial I want to share my method to iterate a request in postman collection, so it will run several times.

To simulate API response body I create an API mock using mocky. To see my mock API you can click here.

Without a further ado I will demonstrate how to loop a postman request.

  1. In collection level click Triple dot >> Edit >> Variables
Edit variables

2. In tab Variables tab, type in type in count with current value 5, then click Update. This step will create new variable in collection level.

Collection variables value

3. Create new request. For this simulation I will use request from this story. But I will modify the test script. In the test script add script as follows.

var currentCount = pm.collectionVariables.get("count")
if (currentCount > 0){
currentCount = currentCount -1 ;
pm.collectionVariables.set("count", currentCount);
postman.setNextRequest("Get books detail (loop)");
}

4. Save request and run collection. To make it works, one can’t run the test by clicking “Send” button. We must run it using collection runner.

Collection runner

5. Run it and Voila!! we’ll get another 5 request running.

Test result

Thank you for reading my story. Hope it will helps you.

Follow me on

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

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

Twitter: https://twitter.com/MydoQa

In this tutorial I want to share my method to assert array in response body.

To simulate API response body I create an API mock using mocky. To see my mock API you can click here.

As you can see; I have an API that return array that contains string value. In this scenario, lets assert that book title “API test 01” has “John Doe” as the author.

{
"storeId": 1001,
"books": [
{
"bookId": 101,
"title": "API test 01",
"author": "John Doe"
},
{
"bookId": 102,
"title": "API test 02",
"author": "Jane Doe"
},
{
"bookId": 103,
"title": "API test 03",
"author": "Foo Bar"
}
]
}

Postman Installation

To get postman you can download from their website.

Create Postman Request

  1. Create a basic request
Create new postman request
Create new postman request

2. Insert url address for the API. This API using “GET” as the method. Then click “Send”

Send API request

3. Then we will get response as below

Response body

Response body assertion

Now, for this scenario, I want to show you, how to assert that book with title “API test 01” has “John Doe” as the author.

First we will isolate each array content into separate array. Then we can do the assertion. To do that we can do the following steps:

  1. In the “Tests” tab, create loop operation to get array elements. To do that, we can use the following script
var jsonData = pm.response.json();
for (let books of jsonData.books){
console.log(books)
}

Using that script, the array contents will be divided into separated elements.

Array contents

2. After we have individual array, now we can add the assertion in the “for” block.

var jsonData = pm.response.json();
pm.test(“Status code is 200”, function () {
pm.response.to.have.status(200);
for (let books of jsonData.books){
if(books.title == “API test 01”){
pm.expect(books.author).to.eql(“John Doe”)
}
}
});

As we can see, I put all the assertion block in the “pm.test” block. That’s because postman will not treat scripts outside the “pm.test” block as test scripts.

We can clearly see below that the test is pass.

Test result

Conclusion

I will be honored if this tutorial helps you

Follow me on

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

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

Twitter: https://twitter.com/MydoQa

Find this blog interesting? Follow us