It is not just unit tests and integration tests that run automatically within a few minutes in every build. We train your team so they learn how to write system tests parallel to feature development and, therefore, are able to successfully use “Test First” in the system testing. Your team will also learn how to automate system tests in such a way that all the necessary system tests will additionally run automatically, as part of continuous integration or in the nightly build.
The “Team Charta” is the document used by the team for laying down the rules of the game. Also the rules concerning QA and testing are laid down in the chapter “Definition of Test” here. For example, how and where the team documents the test cases and test results, which testing methods and tools are used, which test coverage should be obtained and so on.
This “Definition of Test” should be checked and – if needed – updated sprint by sprint so that it meets the team’s demands as well as the changing requirements and risks of the product at any time.
Backlog Items are evaluated from a test perspective from the very beginning, and their usability for the test is ensured. One point to determine here is how the acceptance tests at the end of the sprint will be designed. The testability is considered at an early stage, and the test can have an effect on the creation of the acceptance criteria. The realisability and the intrinsic value of the user stories are also checked at this stage. In this way, the team can avoid including incomplete or untestable stories in the sprint, which could put at risk the successful completion of the sprint.
We demonstrate how testers and developers plan backlog items together in the development and testing tasks, how they estimate the scope and how they make the realisation using pair programming, pair testing and the principle of “test first”. The appropriate test methods and test tools are necessary here in addition to training and coaching.
In the DoD, the common perspective of the team is adhered to in order to determine which criteria have to be fulfilled so that a story can be demonstrated to the product owner as “done” at the end of the sprint. This includes implementation tasks as well as documentation and testing in a scope that is individually agreed on each occasion and determined by the team charter and the definition of test. The common understanding of “done” provides a reliable basis for planning, constructive collaboration and a high level of product quality.
With the agile approach, the team is in the foreground. For every team member, it is not only necessary to demonstrate specialized and technical skills, but also to personally develop his or her skills with regard to collaborating, understanding roles, taking responsibility and communicating. We help you to turn your team into a winning team with tailor-made training courses and workshops as well as accompanying coaching for team members.
A potentially deliverable product has to be available at the end of every sprint. We ensure that the result of each sprint is really “shippable” on every occasion by using “test non-stop” and by systematically recording, evaluating and predicting the occurrence of defects.
Book your workshop now on the subject of “agility” at the imbus Academy, or arrange a non-binding information meeting with us.
We would also be delighted to have the opportunity to make a free presentation at your location, in one of our offices, or at one of our events.
Just arrange an appointment with us!
Give us a call: +49 9131 7518-0 or send an e-mail to info(at)imbus.de.
"Testing software in an agile development process".