Agile Development and Testing - An Introduction
Waterfall Development - The Old World
Development in the old world (a few years ago) was a long process. Named “The Waterfall Model”, development and release took place in long, successive steps. First, spec creation. In this step, Product defined what the product was supposed to include and look like. The next step was R&D, who wrote the code. After that, the code was sent to QA for testing, and only after further corrections, the new version was released. Sometimes, release included another step, a code freeze, to ensure the product was stable.
This tiresome process could take months and even years, and the result was that the customer or end-user received the product very, very late. By this time, customers might have said that this actually wasn’t the product they were looking for, that they lost their budget or that your competitors had already provided them with what they need.
Agile Development and Testing - A Whole New World
Agile development and testing is a solution to these problems. By implementing incremental releases, developers create an incremental product that is adapted to the quickly changing market and dynamic customer needs.
Agile development is based on smaller steps that take place inside a sprint. Each sprint is followed by a release. Instead of R&D getting the specs from product, taking weeks/months to understand them, passing the code between Dev and QA a few times in a long bounceback, redesigning and developing and only then releasing - in an agile world, a release cycle is usually 1-3 weeks, and that’s it.
Working in Sprints
Before each sprint, dev is assigned what they need to do and they plan how to work on the assignments throughout the sprint. During the sprint, developers and QA work on the same tasks together, to avoid surprises and errors. Product sample the work as it is being done, to ensure it’s in line with the plan. At the end of the sprint, whatever is ready is released, and whatever is not is pushed to the next sprint. (Some companies encourage dev to rush to finish the last assignments before the sprint ends, but this is not necessarily the best approach).
The advantages of sprints are:
- Faster releases, which is in line with customer and market needs
- Less errors and surprises as everyone is working together on the same tasks
- Errors can be fixed quickly, in the next sprint and not in weeks/months
- There is less stress to accomplish many tasks, so each task is performed better
- Faster reaction to user feedback after using the new product
- Smoother reaction to errors - developers still remember the code they worked on. In longer releases it will take developers time to remind themselves what they were working on, or they might not even be working in the same company anymore.
- Integration problems between teams can be fixed quicker
Ideally, over time sprints become shorter, and releases become faster. Instead of waiting two weeks for a release, releases could happen every week, and then days, and then a few times a day.
To be able to shorten sprints, dev needs to ensure that their releases are easy and quick. If a release takes a day or two, or they have errors, it will be difficult to shorten the sprint.
One way to shorten release time is by Regression Testing. Regression tests can be manual or automatic, functional or for a load, and they test everything about the system.
Manual regression testing is more thorough and enables tester discretion. However, it is slower and more prone to mistakes. Automatic regression testing, on the other hand, is quicker, but it takes time to write and to maintain, and some things are difficult to automatically test.
After the regression testing, dev fixes the bugs that were found, ideally another regression test is run, and release is set. In the case of clashes between newly developed features, product prioritizes and decides which should be released. This is also true for bug fixes.
Regression testing was born because the code isn’t perfect, and because the interactions between new features might cause problems, as the code was gathered for two weeks. Two features might each work with the old code, but together they might crash the system. In a pure agile system, regression isn’t necessary, because all tests are run perfectly in a Continuous Integration process and everyone is coordinated, resulting in better code of better quality. But on the way to agility, in a sprint system, regression is the price to pay for each sprint.
The Testing Triangle
Regression testing includes many types of tests, and they are usually presented in a testing triangle. This testing triangle is well-known among developers and a subject for many philosophical debates (I recommend you start here).
From the bottom up (which is also the test flow) -
- Unit Tests (bottom) - Test the inside logic of the system and are written in the same language as the code. They are easy to write, small, fast and limited to what they can check. Thousands are run each sprint.
- Integration Tests (middle) - test the logic of the system, as well as databases (like MongoDB or Redis), integrations between servers and APIs. Hundreds are run each sprint.
- System/E2E (top) - check the complete system by simulating a customer. They are very hard to write and to maintain, they break easily and they are very slow. Tens or hundreds are run each sprint.
One of the challenges in creating these tests is to avoid duplications between tests. These are obviously hard to find.
Agile development also changes the R&D structure, from separating developers, QA and Product to scrum teams. Scrum teams were created as a means to sync between everyone in a sprint, and as a way to cooperate on a certain aspect, be it an element, feature, end to end scope, and so on. Scrum teams also encourage mutual responsibility, which is a huge advantage for companies and people.
The scrum team is built of:
- Scrum master - the leader who ensures everyone is working in an agile form. The scrum master syncs inside the team and between teams.
- Product manager - decides what each team works on and prioritizations.
- Members - write and test code. The scrum master is also a member.
One of the challenges of scrum teams that release together, is clashes between teams on features as well as a blame game that might occur between them when problems arise.
Achieving Agility and Continuous Delivery
To achieve agility as well as continuous integration and continuous delivery, the system needs to support it. This starts with a quick release, scrum team cooperation and proper testing. Don’t forget that tests don’t only need to be written, they also need to be good. (In fact, there is no way to check a test’s quality, except when it shows bugs).
But it’s not only the technical system that needs to adjust, it’s also the working culture. As part of the agility culture, dev needs to learn to build small things. Instead of features or screens that take a few months, tasks need to be broken down into smaller parts. Agile is built of small steps with good tests and a lot of protection and security.
Finally, companies need to be active to get agility, because it’s a long process that requires a lot of technique. It takes time to study methods, implement tools and learn from mistakes. Trial and error are important and shouldn’t be rushed through or frowned upon, because they ensure a stronger team that works better in the end. Going agile is like running a marathon - you have to start gradually to achieve your goal. It takes a lot of work, but it’s definitely worth it.
Continuous Testing with BlazeMeter
By running your performance, functional and API tests automatically in BlazeMeter, you can bring your development closer to agility. Ease of use, multiple open source tools support and integration with CI tools like Jenkins and TeamCity, as well as insightful reports, makes the testing and release process shorter, resulting in shorter sprints and faster releases.
To try out BlazeMeter, request a demo, or put your URL in the box below and your test will start in minutes.