Test Data Management Strategies

Hello all,

Today I am going to talk about some different approaches to handle your test data when running automated tests and the trade-offs.

 

Database

Injecting the data before running the tests with SQL, mysql or postgresql scripts are one of the most common approaches. So, you can inject the data you will need for the tests and skip all the setup, which is not the goal of all your scenarios, right ?

For the scenarios that you actually need to test the creation of the data then you won’t use this kind of script. For example in javascript, you would add a setup/data management class, a @BeforeAll and then something like this:

var mysql = require('mysql');
var con = mysql.createConnection({
     host: "localhost",
     user: "root",
     password: "12345",
     database: "javatpoint"
});  

con.connect(function(err) {
     if (err) throw err;
       console.log("Connected!");
       var sql = "INSERT INTO employees (id, name, age, city) VALUES ('1', 'Ajeet Kumar', '27', 'Allahabad')"; 
       con.query(sql, function (err, result) {
     if (err) throw err;
       console.log("1 record inserted");  
     });
});

Then you can have a @TearDown, @AfterAll function to delete the data that was created to be used during the tests.

Files

If, for example, you are running some API tests you might want to have static data ready to be injected for each scenario. You can create a json file and add all the fields and values that are going to be used during your automation:

 { 
   name: "John", 
   age: 31, 
   city: "New York" 
},
{
   name: "Rafa", 
   age: 29, 
   city: "London" 
}

Then you can load this file to be used during your tests. You can create this data upfront, but then you need to make sure that this data is always going to be there otherwise you need to create it again (during your tests or manually).

 

Objects

You can create Objects with the data that you are going to need for the automated tests, so for example you can create a dictionary in Javascript:

var dict = {
  FirstName: "Rafa",
  Age: 30,
  Country: "UK"
};

Then again you need to make sure you are going to create this data during runtime, maybe in a @BeforeAll function or a Setup class, or maybe this is something you have created in the environment already and you need to make sure this is going to be there when running the tests, otherwise you need to create it again.

 

Docker

If you can control the database or the deployment of your QA environment, then it means you can also manipulate the database when running the tests.

If you use docker to create the environment you can add a Volume or even seed the database with docker-compose.

Volume

Volumes are often a better choice than persisting data in a container’s writable layer because a volume does not increase the size of the containers using it, and the volume’s contents exist outside the lifecycle of a given container.

You can push the database (json file, .db) entirely to the docker container:

 docker run -it --name my-directory-test -v /hostvolume:/containervolume centos /bin/bash

Seed

Write a small script that generates randomized and varying data and writes it to the database. Then you can wrap this script into your own Docker image in order to execute them automatically via docker-compose.

 

In this example I am using a mongoDB database:

docker-compose.yml

version: '1.0'

services:

  mongodb:
    image: mongo
    container_name: mongo
    ports:
      - 27017:27017


  mongo-seed:
    build: .
    environment:
      - MONGODB_HOST=mongo
      - MONGODB_PORT=27017
    volumes:
      - ./config/db-seed:/data
    depends_on:
      - mongo
    command: [
      "mongoimport --host mongo --port 27017 --db testautomation --mode upsert --type json --file data.json --jsonArray"
      ]

data.json

[
  {
    "name": "Peter Parker",
    "email": "spiderman@gmail.com",
    "age": 28
  },
  {
    "name": "Bruce Wayne",
    "email": "batman@gmail.com",
    "age": 48
   }
]

 

Scenarios

If you are working with Gherkin syntax, it means you can also add the data in the middle of the scenario and then use it during the automation. So, something like:

Scenario: Correct number of movies found by superhero
Given I have the following movies
| Batman Begins | Batman |
| Wonder Woman | Wonder Woman |
| Wonder Woman 1984 | Wonder Woman |
When I search for movies by superhero Wonder Woman
Then I find 2 movies

Then you can get this data from the step definitions and use during yours tests.

You might have other ways to create and manage the test data, but whatever the approach you decide, make sure the scenarios are independent and if you can clean up the environment data after (unless you have decided to have static data in the environment for now) then clean it.

 

Resources:

https://forums.docker.com/t/seeding-data-volume-containers-mongodb/2214

https://stackoverflow.com/questions/31210973/how-do-i-seed-a-mongo-database-using-docker-compose

https://www.baeldung.com/cucumber-data-tables

https://docs.docker.com/storage/volumes/

https://phauer.com/2018/local-development-docker-compose-seeding-stubs/

Developing a Test Strategy

Hello everybody,

In case you have missed here it is the link for the meetup about Developing a Test Strategy 30/07/2020.

 

If you can speak portuguese and don’t feel comfortable with english yet you can also watch the portuguese version here:

Quality? Who Cares?

Steve Watson - Musings of a Test Manager

A few weeks ago I was really fortunate enough to be involved in delivering a Unicom talk on Quality, followed a week later by a round table talk which I hosted, and was set up by Billy Senior.

The topic of Quality is something that intrigues me in the context of software engineering. Most of my career has been dedicated to checking whether the work of someone else does what it is meant to do, and doesn’t do something that it shouldn’t. It sounds bizarre when you think of testing as just that – we are validating that a software engineer has written code that meets the requirements and expectations of an individual or group of individuals. 

But quality is not just about testing to see if something works as it should – plenty of things ‘work’, but the experience is awful, or it takes a long time to…

View original post 628 more words

TestProject New Python SDK

I have adventured myself to test the new TestProject Python SDK this week and I can say it has been quite straight forward. Also, the documentation is extensive and cover a lot of different scenarios and setups.

For those who don’t know, TestProject is a Free Automation Platform that wrappers open source test frameworks (Selenium and Appium) integrating your automation scripts. It consolidates all the needed drivers to run your test automation without additional setup.

1- To start you need to get SDK token from the TestProject Portal (you can register for free here)

2- Download and install TestProject Agent

3- Run the agent locally and verify the status

4- Install the latest version of python (the min. supported Python version is 3.4)

pip install testproject-python-sdk

5- Generate and copy your developer token

6- Create your first test, for example

7- Then you can see the reports published on your TestProject account, for example

 

You can find a lot more examples on their README file.

 

Resources:

https://testproject.io/

https://github.com/testproject-io/python-sdk

Open Banking Functional Conformance Suite Test Cases

What is Open Banking ?

Open banking allows the use of open APIs enabling third-party developers to build applications and services around financial institutions. It comes to bring more financial transparency options for account holders ranging from open data to private data.

Open Banking Use Cases (for Users) | by Ştefan Alexandru Băluţ ...

Open Banking Functional Conformance Suite

To be able to get the Functional Conformance Certificate, Open Banking provides a Functional Conformance Tool to allow implementers to check if your API has successfully developed all required functional elements of the OBIE Read/Write API Specifications.

This Open Banking tool allows an ASPSP (Account Servicing Payment Service Provider) and a TPP (Third Party Provider) to test the response of any API endpoint and validate that the JSON and data formats meet the schema, permissions and interfaces against the Functional API standard.

How to identify Test Cases covered in the OB Functional Conformance Suite ?

How do you know what else needs to be covered and if there is indeed something more to cover ? After digging into the project on bitbucket, I found some useful json files where you can check the assertions for each test case, the test cases itself and another file to translate the list of the assertions.

So, you can find the asserts that are being done for each test case inside the manifests folder.

For example, this one contains the assertions for this test case: The x-fapi-interaction-id is replayed for an Account. You can find the file with the accounts transactions test cases here.

Screenshot 2020-07-13 at 17.48.08

Then you would need to check what this assertion actually means, and you can find the dictionary of the assertions on this file.

Screenshot 2020-07-13 at 17.52.47

Remember that all the tests currently assume that consent is granted at the ASPSP portal for each requested PSU Consent (Payment Service User Consent).

Also, you will find that some test cases are missing for instance what should happen when you send an invalid token to the payments endpoint, but you can see there is a test case for the accounts endpoints for when you send a token without the required permissions to get a 401 response.

In this example, you can see that for payments the consent model is a bit different because each access token doesn’t have a range of permissions, but is associated with a single payment consent id. So, in order to get a 401 response, the request can present the wrong token along with a payment call or present no token at all. The conformance tool is not sending any token in this instance.

So make sure you are aware and cover the missing test cases with another approach.

I found quite hard to have a straight answer about what are all the test cases they are covering and also the details, so hope this helps to have a bit more clarity in case you are having the same issues.

Resources:

https://openbankinguk.github.io/knowledge-base-pub/conformance-tools/

https://openbanking.atlassian.net/wiki/spaces/DZ/pages/1061716467/Functional+Conformance

https://medium.com/zoidcoin-network/open-banking-use-cases-for-users-8678d11d770b

https://en.wikipedia.org/wiki/Open_banking

Load tests: Jmeter vs K6

Hello all,

Today it’s the turn of Jmeter and K6 ! As always, remember to check your other options and see what better fits for your project.

Jmeter is a great and powerful tool, but depending on what you really need (something more lighter) then Jmeter might become an over complex, slow, hard to maintain tool.

Jmeter K6
In-built Protocols Support
  • HTTP
  • FTP
  • JDBC
  • SOAP
  • LDAP
  • TCP
  • JMS
  • SMTP
  • POP3
  • IMAP
  • HTTP 1.1
  • HTTP 2
  • WebSockets
Speed to write tests
  • Slow
  • Fast
Support of “Test as Code”
  • GUI oriented
  • Possibility to create scripts, but too complex and lack of documentation
  • Weak (Java)
  • Hard to maintain
  • Scripts oriented
  • JavaScript
  • Easier to maintain
Ramp-up Flexibility
  • Plugins available to be able to configure flexible load
  • Supports ramp-up phases and flexible load
Test Results Analyzing
  • Yes
  • Yes
Resources Consumption
  • Heavy to run tests with multiple users on a single machine, more memory consumption
  • Lightweight and doesn’t take up so much memory of your machine

Screenshot 2020-07-06 at 23.34.47

Easy to use with Version Control Systems
  • No
  • Yes
Number of Concurrent Users
  • Thousands, under restrictions
  • Thousands
Recording Functionality
  • Yes
  • No, but it allows to auto-generate a k6 script via an HAR file
Distributed Execution
  • Yes
  • Yes
Load Tests Monitoring
  • Add listeners, but consume more memory

Screenshot 2020-07-06 at 23.35.02

Jmeter is most used when:

  • You need to perform a complex load including different protocols
  • You can record scenarios
  • Robust support and training ecosystem
  • Require that a full scenario be written for every test
  • If you need to simulate specific load with some custom ramp-up patterns
  • If you just prefer UI desktop app for scripts creation, or you just do not know Javascript/YAML/JSON well enough

 

K6 solves some specific problems:

  • CLI tool with developer-friendly APIs.
  • You can use HAR files to generate record sessions
  • Checks and Thresholds – for goal-oriented, automation-friendly load testing
  • Open source, great support and documentation
  • Lightweight uses Javascript
  • Does not run in NodeJS and doesn’t run in a browser

 

Resources:

https://k6.io/

Load Tests: Jmeter vs Gatling

Hello guys,

Continuing on reviewing some performance test tools, today is the turn of Jmeter and Gatling, which looks like more and more people are using nowadays. Remember always check your other options and see what better fits for your project.

 

Jmeter is a great and powerful tool, but depending on what you really need (something more lighter) then Jmeter might become an overcomplex, slow, hard to maintain tool.

Jmeter Gatling
In-built Protocols Support
  • HTTP
  • FTP
  • JDBC
  • SOAP
  • LDAP
  • TCP
  • JMS
  • SMTP
  • POP3
  • IMAP
  • HTTP
  • JMS
  • MQTT
Speed to write tests
  • Slow
  • Fast
Support of “Test as Code”
  • GUI oriented
  • Possibility to create scripts, but too complex and lack of documentation
  • Weak (Java)
  • Hard to maintain
Ramp-up Flexibility
  • Plugins available to be able to configure flexible load
  • Supports ramp-up phases and flexible load
Test Results Analyzing
  • Yes
  • Yes
Resources Consumption
  • Heavy to run tests with multiple users on a single machine, more memory consumption
  • Lighweight and doesn’t take up so much memory of your machine

Screenshot 2020-06-20 at 14.38.36

Easy to use with Version Control Systems
  • No
  • Yes
Number of Concurrent Users
  • Thousands, under restrictions
  • Thousands
Recording Functionality
  • Yes
  • Yes
Distributed Execution
  • Yes
  • Yes
Load Tests Monitoring
  • Add listeners, but consume more memory
  • Yes, logs through the console and reports are created at the end
Screenshot_2020-06-20 Gatling Stats - Global Information

 

Jmeter is most used when:

  • You need to perform a complex load including different protocols
  • You can record scenarios
  • Robust support and training ecosystem
  • Require that a full scenario be written for every test
  • If you need to simulate specific load with some custom ramp-up patterns
  • If you just prefer UI desktop app for scripts creation, or you just do not know Javascript/YAML/JSON well enough

 

Gatling solves some specific problems:

 

Resources:

gatling.io/

Load Tests: Jmeter vs Artillery

Hello guys,

Continuing on reviewing some performance test tools, today I am going to post a comparison of Jmeter and Artillery. Most people still prefer to use Jmeter as it has been longer in the market, but it is always good to check your other options and see what better fits for your project. I have used Locust and Artillery recently and they are also great tools easy to maintain and to create your scripts.

Just to remind again:

Jmeter is a great and powerful tool, but depending on what you really need (something more lighter) then Jmeter might become an overcomplex, slow, hard to maintain tool.

Jmeter Artillery
In-built Protocols Support
  • HTTP
  • FTP
  • JDBC
  • SOAP
  • LDAP
  • TCP
  • JMS
  • SMTP
  • POP3
  • IMAP
  • HTTP
  • Socket.io
  • WebSocket
Speed to write tests
  • Slow
  • Fast
Support of “Test as Code”
  • GUI oriented
  • Possibility to create scripts, but too complex and lack of documentation
  • Weak (Java)
  • Hard to maintain
  • Scripts oriented
  • Strong (JSON/YAML – YAML is the recommended format since it allows comments)
  • Easier to maintain
Ramp-up Flexibility
  • Plugins available to be able to configure flexible load
  • Supports ramp-up phases and flexible load
Test Results Analyzing
  • Yes
  • Yes
Resources Consumption
  • Heavy to run tests with multiple users on a single machine, more memory consumption
  • Light to run tests with multiple users on a single machine, less memory consumption
  • Doesn’t take up so many of your machines’ resources
  • Multicore support

Easy to use with Version Control Systems
  • No
  • Yes
Number of Concurrent Users
  • Thousands, under restrictions
  • Thousands
Recording Functionality
  • Yes
  • No
Distributed Execution
  • Yes
  • Yes
Load Tests Monitoring
  • Add listeners, but consume more memory
  • No. Reports are only created at the end or you can check the terminal logs.

Concurrent users low than expected in the scenario · Issue #434 ...

 

Jmeter is most used when:

  • You need to perform a complex load including different protocols
  • If you need the script recording functionality
  • Require that a full scenario be written for every test
  • If you need to simulate specific load with some custom ramp-up patterns
  • If you just prefer UI desktop app for scripts creation, or you just do not know Javascript/YAML/JSON well enough

 

Artillery solves some specific problems:

  • You can write performance scripts pretty fast, there is even a “quick” mode (where you don’t need to create any script)
  • Push to your VCS and easily maintain the scripts
  • Artillery has WebSocket support out of the box and native support for Socket.io
  • Spend minimum time on maintenance without additional GUI applications
  • Simulate thousands of test users on local machine without the need to have multiple slaves as it uses Node.js is easier to install and lightweight

 

Resources:

https://artillery.io/faq.html

Load Tests: Locust vs Jmeter

Hello guys,

Today I am going to post a comparison of these two different load tests framework. I know most people use Jmeter and it has been longer in the market, but I have recently used Locust and also Artillery (which will post a comparison later) and the results are great, the team was able to improve the creation of the tests and also the maintainability.

In the end of the day you need to use the right tool for your needs, Jmeter is a great and powerful tool, but depending on what you really need (something more lighter) then Jmeter might become an overcomplex, slow, hard to maintain tool.

Jmeter Locust
In-built Protocols Support
  • HTTP
  • FTP
  • JDBC
  • SOAP
  • LDAP
  • TCP
  • JMS
  • SMTP
  • POP3
  • IMAP
  • HTTP, but ability to add a customise protocol
Speed to write tests
  • Slow
  • Fast
Support of “Test as Code”
  • GUI oriented
  • Possibility to create scripts, but too complex and lack of documentation
  • Weak (Java)
  • Hard to maintain
  • Scripts oriented
  • Strong (Python)
  • Easier to maintain
Ramp-up Flexibility
  • Plugins available to be able to configure flexible load
  • Ability to specify a linear load only (so no complex scenarios)
Test Results Analyzing
  • Yes
  • Yes
Resources Consumption
  • Heavy to run tests with multiple users on a single machine, more memory consumption
  • Light to run tests with multiple users on a single machine, less memory consumption
  • Doesn’t take up so many of your machines’ resources.
Easy to use with Version Control Systems
  • No
  • Yes
Number of Concurrent Users
  • Thousands, under restrictions
  • Thousands
Recording Functionality
  • Yes
  • No
Distributed Execution
  • Yes
  • Yes
Load Tests Monitoring
  • Add listeners, but consume more memory
  • Ability to monitor a basic load

 

Jmeter is most used when:

  • You need to perform a complex load including different protocols
  • If you need the script recording functionality
  • If you need to simulate specific load with some custom ramp-up patterns
  • If you just prefer UI desktop app for scripts creation, or you just do not know Python well enough

 

Locust solves some specific problems:

  • You can write performance scripts pretty fast
  • Push to your VCS and easily maintain the scripts
  • Spend minimum time on maintenance without additional GUI applications
  • Simulate thousands of test users on local machine without the need to have multiple slaves

 

Reducing the Scope of Load Tests with Machine Learning

Hello hello,

Today I am going to share this really interesting webinar of my friend Julio de Lima, he is one of the top QA influencers in Brazil, and in this video he is talking about how to reduce the scope of load tests using Machine Learning.

Load testing execution produces a huge amount of data. Investigation and analysis are time-consuming, and numbers tend to hide important information about issues and trends. Using machine learning is a good way to solve data issues by giving meaningful insights about what happened during test execution.

Julio de Lima will show you how to use K-means clustering, a machine learning algorithm, to reduce almost 300,000 records to fewer than 1,000 and still get good insights into load testing results. He will explain K-means clustering, detail what use cases and applications this method can be used in, and give the steps to help you reproduce a K-means clustering experiment in your own projects. You’ll learn how to use this machine learning algorithm to reduce the scope of your load testing and getting meaningful analysis from your data faster.

 

Thank you Julio 🙂