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.

Summary 

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

Testing Asynchronous APIs: Awaitility tutorial

Despite the growing popularity of test automation, most of it is still likely to be done on the frontend side of application. While GUI is a single layer that puts all the pieces together, focusing your automation efforts on the backend side requires dealing with distributed calls, concurrency, handling their diversity and integration. Backend test automation is especially popular in the microservices architecture, with testing REST API’s. I’ve noticed that dealing with asynchronous events is particularly considered as challenging. In this article I want to cover basic usage of Awaitility – simple java library for testing asynchronous events. All the code examples are written in groovy and our REST client is Rest-Assured. Synchronous vs Asynchronous  In simple words, synchronous communication is when the API calls are dependent and their order matters, while asynchronous communication is when the API calls are independent. Quoting Apigee definition: Synchronous...

REST API mocking with Wiremock

Probably every developer or tester have used mocks at least once in their daily professional work. Functionality mocking is an excellent way to improve development process of integrated systems production, or testing heavy dependent application functionalities. With the growth of popularity of REST webservices, API mocking is becoming hot topic. In this article I would like to introduce a simple getting-started tutorial of setting basic standalone REST API mock server with Wiremock on your local machine. Wiremock is a simple library written in Java for mocking web services. Installation  To run standalone wiremock server, download jar from here and run: $ java -jar wiremock-1.55-standalone.jar you should see: This means that wiremock has started an empty mock server on localhost on port 8080. After you navigate to http://localhost:8080/__admin/ in your browser, you should get empty mappings entity: You can also change default port by adding --port...

Rerun Flaky Tests – Spock Retry

One question I get asked a lot is how you can automatically rerun your test on failure. This is a typical case for heavy, functional test scenarios, which are often flaky. While test flakiness and its management is crucial and extensive matter itself, in this post I want to give a shout to the extremely simple yet useful library: Spock-Retry. It introduce possibility to create retry policies for Spock tests, without any additional custom-rules implementation – just one annotation. If you are not a fan of Spock testing framework and you prefer JUnit – stay tuned! I will post analogous bit about rerunning JUnit tests soon. Instalation  If you are an maven user, add following dependency: <dependency>       < groupId > com.anotherchrisberry < /groupId >       < artifactId > spock-retry < /artifactId >       < version > 0.6.2 < /version >      ...