Application development and testing has been revolutionised in the past several years with artifact and package repositories, enabling delivery of identical application environments in seconds. The use of Github, Jfrog and other repositories exploded with the introduction of Docker containers, and application development and testing now features containers and package repositories, as recognized best practices.
The development and testing of databases, however, remains mired in outdated database refresh and delivery processes. Backups are restored to fixed database instances, that are typically shared between multiple developers or testers. Updating databases often requires a full business day. Problems in a production database…
Okay, so that title doesn’t make complete sense. However, if you read to the end of this article, all will become clear. I’m first going to discuss some of the persistent barriers to in-sprint testing and development. I will then discuss a viable route to delivering rigorously tested systems in short sprints.
The two kingpins in this approach will be data and automation, working in tandem to convert insights about what needs testing into rigorous automated tests. But first, let’s consider why it remains so challenging to design, develop and test in-sprint.
As the Agile Manifesto approaches 20 years old…
The 2020/1 edition of the World Quality Report (WQR) highlights how the expectation placed on test teams has been growing steadily. QA teams today are under more pressure than ever to deliver quality at speed. Software under test has grown increasingly complex, while the time available for the construction and execution of tests is shorter than ever. This has increased the demand for greater automation in testing, often focused on test execution automation.
However, test automation bears its own challenges. According to the WQR, organisations are currently lacking the key skills and budget required to grow and maintain effective test…
We rarely post ‘product’ articles here at Curiosity, preferring instead to draw on our team’s thought and expertise. This article is no different, though it does discuss certain features in Test Modeller.
However, the following article is intended primarily as a guide to common concerns regarding model-based testing, discussing the ways in which we’ve responded to them in Test Modeller. All the features discussed draw on Curiosity’s decades of collective experience in building model-based solutions. Each has been designed to remedy common challenges when implementing model-based test design, shortening it’s time to value while amplifying its benefits.
The features discussed…
Remember when test automation was being peddled as a silver bullet for testing bugbears? Of course, those vendors really meant test execution automation. Automating test execution was going to increase coverage, minimise testing time, and overall reduce the amount of money being spent on testing. It would even butter your toast in the morning.
Well, those days are long gone. Organisations have now reckoned with implementing test automation and have grown wise to its challenges. They’ve discovered that automating one process within testing leaves many others untouched, while introducing many challenges of its own. …
Low-code development has created a population of “Citizen Developers”, enabling organizations to deliver IT solutions at incredible speeds. However, this has created a fresh challenge for test teams across organizations, who are now tasked with ensuring the release of quality, bug free apps at unprecedented speeds.
Test teams have become encumbered as they must now test fast-flowing low–code apps, in addition to all existing business-critical systems. Low-code app testing is in turn beginning to occupy an increasing amount of testing time, calling for an efficient and automated solution to low-code app testing.
Automation specialists. Testing, Test Data, DevOps. Inventors of Test Modeller, Test Data Automation, and VIP.