Agile Software Development …
Agile has let to a new approach in software development. The customer – and thus the customer requirements – are now much more in the focus of the whole development process than this was – and partially still is – the case when using traditional methods. It should be no longer the case that the customer gets “some result” at the end of the project, which probably does not match the customer’s initial expectations. Instead the customer gets much more involved in the overall process by delivering working productive software on a regular basis throughout the lifetime of the project. Of course this also leads to new responsibilties on the customer side, like participating in demos regulary. But this is for sure time very well invested and it will reduce the effort in other areas (for example when writing the target specification). In particular this intense communication between the customer and the development team leads to a much better mutual understanding of the requirements. The customer will be able to realize and announce changes early in the project and gets those changes implemented by the software team. Many real life projects have proven that discussing requirements only “theroretically” often leads to problems in the end. Using agile methods those discussions lead to much better results as the already existing and working software can be used as a basis for the discussion. This results in much better software as it helps to realize the customer’s expectations and to implement them. The quality and the amount of implemented feature it thereby a key indicator that can be measured continuously. In the end this also means more reliability for the financial side of a software project and a much better overall customer satisfaction.
… requires Agile Testing
Obviously it is not enough to just realize the customer expectations early, but it must be possible to react on them. This means that the software is undergoing much more frequent – and potentially radical – changes in comparison to traditional software projects. This leads to Agile Testing. In agile projects software is developed in so-called iterations or sprints . Normally those sprints last only two or three weeks and in the end there should be completely tested software that can be delivered to the customer and used productively. Writing testplans and executing them manually is no longer an option here as this approach cannot keep track with the required speed and flexibility of the agile development process. Thus writing automated tests is the logical consequence to be able to execute them fast and frequently. Because tests are not only executed once at the end of a sprint, but usually several times a day from different developers to test changes before committing them (see continuous integration ). In particular so called regression tests ensure that new functionality is not breaking any already existing features. Explorative Testing can be used to complete the testing. This means that different team members – or other persons – are “playing around” with the software. (Of course it is not that easy and the whole topic could easily fill a blog entry of its own.)
It must be noted that the quality of the software is heavily depending on the quality of the automated tests. This is comparable to the quality and precision of executing traditional test plans. It is very important that the automated tests are reliable and thus they must be implemented with the same quality as the software under test. Reliable here means that failed testcases really indicate a problem in the tested software and not a problem in the testcase itsself or the testing environment. Thus one should not think that just writing a few scripts is enough, even though this might be a starting point. In addition it must be considered that the initial effort of writing automated tests is higher than the effort for traditional tests and: The effort cannot be moved to the end of the project. Developing software and corresponding automated tests must be happening at the same time. When considering Test Driven Development (TDD) it is even more strict. In this case the tests must be written first.
The role of Software Testers …
The role of a traditional software tester is more and more vanishing when using the agile development approach. This is partially due to changed requirements as tests are no longer executed following some test plan, but tests must be implemented. This implementation can thereby have a similar complexity as the implementation of the application under test. Furthermore having separate test teams does not fit to the agile development approach that has a strong focus on working in a team . Therefore every developer in such an agile team should be able to write automated tests, even though there will typically be some team members focusing more on this aspect than others. This kind of specializing is what happens in other areas of software development as well. But it is essential that the function of writing automated tests is kept within the team and is not moved to some “external function” within the company. In an ideal case testcases will be developed together with the experts from the corresponding specialist department. A promising approach is writing so-called Executable Specifications. Those try to combine specifications, explanations, examples and test descriptions in one document. This is an approach that is to some extend also reflected in the tools presented in the following.
… and Testing Tools
Of course it would be possible to write automated tests and testing scripts completely manually. But there are a lot of good frameworks and tools out there that can support a development team really a lot in doing so. There is often the possibility to describe tests using some userfriendly interface defining input parameters and expected behaviour. But before this is possible there is a need to implement the underlying testing methods. The Robot Framework for example is using HTML tables for describing tests. Thereby it is possible to build a test out of several steps. As the result of executing the tests some nice report in HTML is generated. FitNesse is another testing tool that is focusing more on collaborative testing. Testcases are stored in some kind of Wiki where they can be easily processed by other members of the team. Beside those free tools there are also commercial tools like Twist . Twist also supports collaborative testing and it has support to describes testcases using normal language (to some extend). Each of those tools could easily deserve a blog entry of its own, especially as one needs to check the integration of additional tools depending on the usecase. In case of web applications this could be for example Selenium or Webtest for automated GUI testing.
Summary
Agile testing really is the heart of agile development. It enables agile teams to make changes to the software frequently and at the same time test those changes quickly and with constant quality. This is mandatory for the process of continuous integration that enables the iterative delivery of productive software. The role of a traditional software tester is moving more and more to the direction of a software developer as automated tests might require extensive implementation efforts and skills. Automated testing is supported by different tools that need to be evaluated for the individual usecase. Of course it makes sense to select one tool (or a set of tools) to reuse them in different projects and thus building strong competence on those tools. Automated testing can be complemented using explorative testing where the software is tested by using it without following any strict test plans. Of course it makes sense to use agile testing in some small project first to build required competences and evaluate the tools to be used. Afterwards the gained experiences can be used to introduce agile testing more widely. By discussing the pros and cons in applying automated testing as part of the agile retrospectives the quality and coverage of automated tests will probably increase steadily.
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.