Agile Testing in
Software Development
The agile way to more quality and efficiency
With the introduction of agile methods, user requirements are the focus of software development. Future users are more involved in the development process and ensure through their input that important issues are actually implemented and that the application is easy to use and perfomant. To verify this, functional and bug-free software must be delivered often and continuously. The high demands on the non-functional part of the software also have to be tested continuously: has it been coded cleanly, does the application meet the security requirements, does it function stably and is it easy to maintain? In one sentence: constant, frequent and error-free code delivery is a question of quality.
What distinguishes agile from classical testing
In classical test management, development and testing are clearly separated and all four test stages run one after the other: the test phase begins with the completion of the product. First the individual components are tested (component test), in the next stage, the integration test, the interaction of the individual components is checked, and finally the functions of the entire product are put through their paces, first internally (system test) and finally by the customer (user acceptance test). The roles are clearly distributed. The development team develops, the test team tests and the test management controls and steers.
If you want to deliver stable and error-free software continuously (with each iteration) in an agile environment, tests must be carried out continuously. In the long run, it is not feasible to run through one test stage after the other according to classical test methods, because the iterations are short and things have to be done quickly. Agile testing also has component, integration and system tests, with the difference that these do not run one after the other, but in parallel within an iteration, and are sometimes even embedded in the development. The agile approach also does not know any clearly distributed roles: Ideally, software developers and architects as well as testers, test and quality managers are part of the development team and support each other. The team has a common goal: high quality through high test coverage, efficient test execution and documentation. This can only be fulfilled through a balance between a high degree of automation and few manual tests.
Efficient distribution of tests: The test pyramid
A look at Mike Cohen’s test pyramid shows how an efficient test strategy can be designed, how the distribution of tests to the individual test levels should be planned and which areas make the most sense for test automation.The broad base of the pyramid is formed by a high number of component tests in the form of automated unit tests. They are relatively easy to create in parallel with application development, can be carried out quickly, are correspondingly inexpensive and guarantee a high level of test coverage. They ensure that most errors are already detected during development.
The middle level of the test pyramid is formed by integration tests (API tests). API stands for Application Programming Interfaces. Automated API tests ensure that components work together as specified. API tests are very well suited for test automation because they are usually subject to few changes and are easy to maintain. At this point, it should be noted that non-functional tests such as load and performance tests are not considered in the test pyramid, but are important for user acceptance and can also be automated very well in some cases. System tests (GUI tests) are at the top of the pyramid. GUI (Graphical User Interface) is the term used to describe the graphical user interface. Automated GUI tests check whether all functions run as desired. Their automation is quite feasible due to a selection of tools, but the choice of tests to be automated should be considered very carefully, as they are more complex to create and maintain and thus cost-intensive. As a rule, GUI tests require considerable rework to keep up with frequent changes.
It is advisable to automate only as many GUI tests as necessary and as few as possible and to introduce them successively, for example by securing existing functions sprint by sprint using automated regression tests. Exploratory and end-to-end tests are hardly suitable for test automation. The latter because of their complexity. Explorative tests because of their degree of freedom. The explorative tester explores the application without having previously determined exactly which test steps are to be executed. One advantage is that less preparation is required, documentation is kept to a minimum and errors are found away from existing test scenarios.
Quellen: Buch: Agile Testing: Manfred Baumgartner, Martin Klonk, Helmut Pichler, Richard Seidl, Siegfried Tanczos (2018): Der agile Weg zur Qualität
Content:
Test automation
An indispensable part of agile development
Agile work promotes flexible, dynamic and uncomplicated work with as little bureaucracy as possible. The focus is on people and communication. Results mean more than documentation. Establishing a direct line to the customer and always reacting flexibly is more important than stubbornly sticking to a plan. Agile software development means constantly improving the end product in short iterations, together with colleagues and customers. In this article I would like to explain why automated tests are an integral part of software development.
The importance of testing
Testing occupies an important position in software development. A high-quality product must go through different levels of testing, such as component tests, integration tests and functional tests. In Agile work, as mentioned above, the focus is on short development iterations, which also require short test iterations. In order to be able to carry out the various test stages without getting into a time crunch, it is necessary to execute various tests faster and with easy repeatability. The more complex the software, the greater the importance of test automation. Test automation alone can ensure that both test coverage and test depth are within a satisfactory range once the development reaches a certain complexity.
The fallacy of automated tests
The pitfall of automated tests is that they can only take over the manual task part of a software tester. Behind clean and reliable tests, however, there is just as much creative intuitive thinking and clever action. Under no circumstances should test automation be seen as a rationalisation of a tester’s work, but rather as a tool for the tester that can hardly be imagined without. While he no longer has to spend hours working through new developments of his company through automated processes, he has more time for the intellectual part of software testing. He can test better and in a more concentrated way instead of getting lost in a huge amount of tests. Of course, test automation does not always make sense, such as with small transitional programmes. However, the longer-lived and more complex the software, the more costs and effort test automation saves in the long run.
Selenium as a general-purpose tool
There are many tools for test automation. Selenium is probably one of the best known, especially in the area of websites and their user interface. Selenium offers various tools for projects of different sizes and requirements.
Selenium as a browser plug-in
The Selenium IDE is a browser add-on that allows you to record clicks, keystrokes and movements on the website. Later, you can replay the recorded actions and thus obtain a test that can be executed as often as you like. However, since the recording is very time-consuming manually, the add-on is only available for the browsers Chrome and Firefox and there is no possibility to document the tests, the browser plug-in is only suitable for smaller projects or for beginners.
Selenium WebDriver - When websites suddenly become self-sufficient
The Selenium WebDriver, on the other hand, acts as a programming interface for the browser, is compatible with the most common browsers and supports many different programming languages, including JavaScript, Python, Ruby, and many more. Tests can be programmed in any code editor, e.g. Visual Studio, and the browser is then addressed via the WebDriver. Each time the written test is called up, a new window opens in which the website runs itself through the test. A major advantage over the add-on is that the test can be parameterised. The test coverage can be increased much more quickly and easily.
Cucumber, anything but a cucumber
Since this testing does not provide a clear documentation of the work done, there is a tool for various programming languages (Ruby, Java, C++, …) called Cucumber, which makes it very easy to write and read the test cases and also produces easily readable documentation when the tests are executed. In Cucumber, tests are written in the language Gherkin and then translated into the corresponding programming language. Gherkin essentially contains the commands Given, When and Then, through which the optimal functionality of the software is described by conditions (Given), executed actions (When) and desired result (Then). Since the desired behaviour of the software is directly formulated, Cucumber is a very good tool for Behaviour-Driven-Development. The documentation then contains the simple sentences of the Cucumber programming and is thereupon comprehensible for everyone.
Selenium-Cucumber a reliable double pack
The Ruby extension Selenium-Cucumber takes over the translation of the Cucumber tests into the corresponding programming language. Instead of arbitrary sentences, as previously in Cucumber, there is now a defined set of commands that is independently “translated” into an executable test case. The writing effort on the part of Cucumber naturally becomes greater and more incomprehensible, but the programming elsewhere is omitted altogether. Through this interaction of Selenium-Cucumber it is possible to write automated test cases without in-depth programming knowledge. This way, product owners can pack the requirements for the end product itself into the test without any loss.
Our first steps are done
The combination of Selenium WebDriver, Selenium-Cucumber and Ruby or others allows us to take the first steps towards test automation. Besides the easy writing of the tests and the good documentation in html format, the Selenium WebDriver also allows a wide test coverage in different browsers.
What's next: test automation a must
Test automation is a must in an agile environment. The simpler the tests and the more frequently they have to be performed, the more important automation is. However, automation does not replace a tester but facilitates and improves his work, giving him more freedom for tests that cannot be automated (e.g. UX/UI tests). In the course of continuous improvement, every software company should use automated tests. This is the only way to succeed in meeting the high demands and time pressure of today’s world.
Sources: Buch: Seidl, Richard/Baumgartner, Manfred/Bucsics, Thomas (2011), Basiswissen Testautomatisierung (2. Auflage), Heidelberg, dpunkt.verlag
