Skip to main content

What is Agile Testing?

So, what is this Agile Testing? It’s kind of fancy term and everybody use it in software development and QA world, but do we really understand it? What is different in agile approach to testing than in classic ones?

I will try to highlight core concepts, that stands for Agile Testing approach. Please don’t consider this as any kind of manifesto, rather that I want to summarize list of good practices for testers and QAs working in agile teams.

Continuous Quality 

We’ll look down on whats’s in my opinion the most important part of the concept. In stardard – let’s say – waterfall aproach, testing is just another step in the process. When development is done, here comes the test stage, and usually some kind of QA branch is responsible for testing the product of preceding development stage. This approach have been prove correct in case of large systems, with stable and well know requirements. 

However, today’s way of delivering software differs from this. There is huge demand for networkbased, distributed systems, delivered as quick as it’s possible. Going further, business requirements tend to change more often. As well as software development methodologies changed, turning into lighter, agile methodologies like Scrum or Kanban, software testing needs to change also. There’s no room for separate stage. Rather that, testing should be done at each stage of the process.

Gathering Requirements: Starting from gathering requirements, ones should validate them in terms of consistent, logic or comprehensibility. 

Development: Through the development stage, testers should continuously test smaller pieces of the feature, working close (or pair) with developers. 

Testing: During dedicated test time, features needs to be validated in terms of acceptance requirements. I believe our role here is to be bridge between product owners and developers, checking correctness of the implementation with business guidelines. 

Continuous Integration/Continuous Deployment: Nowadays, when software delivery introduced CI/CD and DevOps, there’s huge demand for test automation. I’m far from saying that manual testing is dead and I think will never be, but in my opinion – test automation is the future, whereas manual testing would become limited verification of some narrow test cases. Having said that, automated test should be part of the CI/CD pipelines. Of course there is no need to run for eg. all selenium acceptance tests (which are usually slow) while building every pull request, and in those cases we can limit automated test scope to unit and integration test. However, full blown test suite should trigger at least once a day, could be in separate job, and also ideally before every deploy on production. 

Maintenance: Obviously, bugs will always happen – also when our feature is on production. Depending on organization of your company, usually product owners are the ones who enter them to backlog. Role of the tester here is to analyse bug reports and provide product owners necessary technical knowledge, to make issues fully understandable both to business and developers.


IT is a domain that constantly needs to adapt to more and more demanding industry requirements. Agile movement have had huge impact on software development, like so on testing and quality assurance. In order to test well and deliver reliable software, we also need to adapt to these needs, and improve our work methodology. In my opinion the key concept of agile testing is to treat testing not as a stage that start and ends with a test stage, but as a continuous process.

Popular posts from this blog

Test Automation: Good, Bad and Ugly

The modern approach to software quality and software development life cycle requires that business guys, developers and testers understand that the long manual test phase, although often still necessary, must be reduced to a minimum and replaced by test automation. Working in continuous delivery and continuous integration environment requires us to create automated tests that run on demand, checking our application integration and it’s core functionality correctness. However, there are still many problems with designing and writing automated tests, resulting in their costly maintenance or abandonment in favour of a return to manual processes.
In this article I will focus on describing common good practices of test automation. This post is more than an overview than complete reference guide. Broader aspects, such as the Page Object pattern or Page Factory will be described in detail in a separate article on this blog. Although most practices apply for every types of automated tests, thi…

REST-Assured framework overview

In modern software development, REST services becomes most popular choice for implementing distributed and scalable web application. They are light and easy to maintain, which results in faster and more effective implementation and system integration.
I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks: REST-Assured: going deeperBuilding microservices testing framework
With the increase popularity of RESTful services, there is a need for fast and lightweight tool for REST webservices testing automation. One of the most popular choice is Rest-Assured framework from Jayway. It introduces simplicity of testing web services from dynamic languages like groovy or ruby to java. In this post we will get our hands dirty and write automatic test in Rest-Assured framework.
In order to create complete implementation of automated tests in Rest-Assured framework, we need to write our code against some example API. We’ll use standalone Wiremock m…

REST-Assured: going deeper

In my previous post I described the basic REST-Assured usage – the lightweight framework for testing RESTful services. Despite the fact that described range of functionalities would be enough in most cases,REST-Assured has a lot more to offer. In this post I would like to bring some more advanced examples of the framework usage.

I recommend you also my other posts about REST-Assured and building microservice’s test automation frameworks:

REST-Assured – framework overviewBuilding microservices testing framework
Object Mapping Sending request’s body as string is easy and straightforward, but it can be inconvenient in the case of more complex operations on request / response properties. Proven solution for this is a good-known serialization of request/response body to objects. REST-Assured supports object mapping to (and from) JSON and XML. For JSON you need either to have Jackson or Gson in your classpath and for XML you need JAXB. Here is an example of request object serialization using J…