Quality at the Speed of Agile & DevOps

Archive for the ‘QA’ Category

Quality at the Speed of Agile & DevOps

Posted by KISHORE | Posted On December 24th, 2020 | QA, Quality Assurance

quality-at-speed @ QualiTlabs

Quality-at-Speed #QualiTlabs

Projects using waterfall often have release cycles measured in months (some even years). Agile and scrum revolutionized so much in software by being able to ship at the end of each sprint – it could be anywhere from weeks to days, even to hours in some projects. DevOps often has automated deployments scheduled multiple times per day. This means the rate of change to production code can be orders of magnitude faster in DevOps than even agile. This sets the stage for delivering Quality at the Speed of DevOps and Agile.

In an Agile world, teams are being asked to move faster — reducing the length of time to delivery while continuing to improve the quality of each release. At the same time, they are faced with increased pressure to reduce testing costs.

“testing at every step” and not “QA” at the end.

Testing is a lean process of quality at every step. It includes quality user stories, quality environments, quality test data, quality unit tests, quality functional tests, and quality performance tests. It is “testing at every step” and not “QA” at the end.

We Don’t Compromise Between Speed And Quality

As digital disrupts business, we’re seeing an unprecedented demand for speed, while quality, of course, is a given; as a result, old ways of testing don’t cut it anymore. we at QualiTlabs, do never compromise on quality to achieve the ‘speed’.


At QualiTlabs we achieve Quality at Speed by implementing the following

Shift Left Testing

Our testers involve from the very start – join design sessions to ask questions about how customers work, try to find gaps in requirements in the user stories, which ultimately leads to design changes. Some team members can work closely with back-end developers to ask questions and create test ideas and ‘what if’ type scenarios. Others sit down with the API developers and stub out tests for new services while they were being developed. And yet others find themselves pairing up with the UI and API developers to test something new on their machine before it hit a build.

Actual testing still happens at the end, but it will be smaller and faster because of the problems you can find earlier on. Shift left doesn’t exactly move testing closer to the beginning of a release cycle. It sprinkles it over each step and each iteration.

In this approach, we have test cases ready by the time new code moves into the QA environment; we just executed the test cases related to the features/stories of the current sprint, while we run the automated tests for all regression testing of the already released features. This helps us find bugs early in the sprint cycle, thus gives more time for the developers to fix the bugs.

Test Automation

Test automation is undoubtedly no longer an optional idea in quality assurance. Increasing the adoption of DevOps and Agile are some of the key factors driving the growth of the automation testing market. As more businesses adopt the latest Agile and DevOps processes to fulfill the demand for Quality at Speed, test automation has become an indispensable component.

We create reliable and maintainable automated tests for all regression areas of the past sprints using the latest test automation tools. We have implemented Test Automation for more than 95% of the clients.

We create automated tests for the UI end to end test cases, API (REST, GraphQL, Microservices) layer, and DB layer.

To expedite the development of the automation tests, we use the in-house developed automation frameworks, this also improves the reliability of the test execution results and maintainability.



Quality Assurance Sees Changes in DevOps Transformation

‘DevOps’—a set of software development practices that combines development (Dev) and information technology operations (Ops). The goal of DevOps is to shorten the systems development life cycle (SDLC), while teams can focus on building features, fixing bugs, and pushes frequent updates that are in alignment with business objectives. DevOps bridges the collaboration between developers and business operationalists.

In the same spirit, QAOps helps increase the direct communication flow between testing engineers and developers by integrating software testing into the CI/CD pipeline, rather than having the QA team operate in isolation. In short, QAOps is defined in two key principles:

  1. QA activities should be incorporated into the CI/CD pipeline
  2. QA engineers should work in alignment with developers and be involved throughout the CI/CD process.

QAOps in Continuous Integration/Testing

We integrate the Automation scripts into the CICD pipeline (using DevOps tools) and leverage the cloud platforms (web and mobile testing platforms) such as BrowserStack, LambdaTest, Sauce Labs, Kobiton, AWS Device Farm, etc. to execute the automated tests on a huge variety of device and browser combinations.

This helps us execute the automated tests early and more frequently during the sprint cycles, this helps us find the bugs at the early stages of the testing cycle.

QAOps for Continuous Reporting

With help of the DevOps tools and Test Automation, we publish the test execution results into different platforms based on the client requirements –

  1. Inbox – a most convenient option for many of our clients
  2. Jira-XRAY – we integrate automation tools with XRAY GraphQL API to post the results in real-time, so that the entire team will have access to the test reports any time, anywhere
  3. PractiTest – we integrate automation tools with PractiTest’s REST API to post the results in real-time, so that the entire team will have access to the test reports any time, anywhere
  4. TestRail,
  5. qTest, the list goes on …

Test automation along with continuous testing to lead by helping teams perform repetitive tasks, detect bugs faster and more precisely, provide continuous feedback loops, ensure test coverage. Therefore, implementing test automation and QAOps in the QA processes can save a significant amount of costs, time, and human resources while achieving the Quality at speed.

QAOps can help detect errors faster and resolve way ahead in the development process. If the QAOps approach is not followed, it will take stretched periods between integrations, which makes fixing up these gaps a longer and an exceedingly stressful task. It will further reduce constant back-pedaling to identify issues and focus more on building various features.


This approach is helping our clients goto Market Fast, to be a market leader


Encrypted REST – API Performance Testing using JMeter

Posted by KISHORE | Posted On October 15th, 2020 | API Testing, Performance Testing, QA



The Problem Statement

It’s becoming more common practice in developing end-to-end encrypted REST APIs or Microservices (i.e. request/response body, headers, and even request URL paths are being encrypted) to enhance security, especially, in the industries such as finance, banking, insurance, healthcare, legal tech, travel, etc.  Now, let’s imagine a scenario where API is being completely encrypted for additional security. Then the ultimate question arises – will you be able to handle this encryption scenario and still perform the testing using JMeter? The answer is YES!!

Possible solution

User JMeter JSR223 PreProcessor and JMeter JSR223 PostProcessor to encrypt or decrypt request/response body/headers/URLs.

You can also achieve the same using other API/Performance Test automation tools, such as Katalon Studio, SaopUI, Postman, Load Runner, etc.

Encryption/Description Algorithm to be used

create aeslib.groovy file with the following code

def  encrypt (def plainText) {GroovyShell shell = new GroovyShell()

def cipher = Cipher.getInstance(“AES/CBC/PKCS5Padding”.getBytes(“UTF-8”), “SunJCE”)

SecretKeySpec key = new SecretKeySpec(“put your secret key here”.getBytes(“UTF-8”))
, “AES”)

IvParameterSpec iv = new IvParameterSpec(“put your IV key here”)

cipher.init(Cipher.ENCRYPT_MODE, key, iv)

def result = cipher.doFinal(plainText.getBytes(“UTF-8”)).encodeBase64().toString()

def ivString = cipher.getIV()

ivString = new String(ivString, “UTF-8”)

return result


def decrypt (def cypherText) {

byte[] decodedBytes = cypherText.decodeBase64()

def cipher = Cipher.getInstance(“AES/CBC/PKCS5Padding”, “SunJCE”)

SecretKeySpec key = new SecretKeySpec(“put your secret key here”.getBytes(“UTF-8”), “AES”)

cipher.init(Cipher.DECRYPT_MODE, key, new IvParameterSpec(“put your IV key here”.getBytes(“UTF-8”)))

return new String(cipher.doFinal(decodedBytes), “UTF-8”)



AES encrypted Request / Parameters / URL / Header

Let’s take a real-world scenario to solve this problem, Let’s assume the following scenarios exist in your project, then how do we go ahead with the API automation

HTTP Request Body (JSON) is encrypted

HTTP Response Body (JSON) is encrypted

HTTP Request Headers are encrypted

HTTP Response Headers are encrypted

HTTP Request URL is encrypted


How to encrypt Request URL

In JSR223 PreProcessor  write the below code

   def aesLib = shell.parse(new File(“${System.getProperty(“user.dir”)}/scripts/aeslib.groovy”))


sampler.setPath(“${aesLib.encrypt(<URL path here >)}”)

How to encrypt Request Headers

In JSR223 PreProcessor  write the below code

sampler.getHeaderManager().add(new Header(“x-access-token”, aesLib.encrypt(“your token here”)))


How to encrypt Request Body (POST request)

def requestPostData = ‘{“param1″:”Value”,”param2″:1234,”param3″:”en”}’

def requestPostDataJOSN = ‘{“data”:”‘ + aesLib.encrypt(requestPostData) + ‘”}’



How to decrypt Response Body

def encryptedResponseData = ctx.getPreviousResult().getResponseDataAsString()

def JSONResponse = aesLib.decrypt(encryptedResponseData )

def jsonSlurper = new JsonSlurper()

def jsonParsedObj = jsonSlurper.parseText(JSONResponse)

def is_success = jsonParsedObj.success

log.info  “success: ” + jsonParsedObj.success

vars.put(“dept_id”, “${jsonParsedObj.data[0].dept_id}”)



you get some ideas on how to encrypt the entire API request body in AES encoding. AES encryption is touched upon in this article.

JSR223 Pre-processor is comfortable with any of these 5 languages – Groovy, JavaScript, JRuby, Jython, and Kotlin.

Another alternative for JSR223 Pre-processor is to use the BeanShell.

BeanShell is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript.