Testing in Agile teams – how to iteratively take care of project quality
- Processes, standards and quality
During this year's Testwarez 2015, we had opportunity to lead a panel discussion about testing in agile teams.
We discussed topics that have collected the most votes during a quick vote. They were as follows:
- How to fit tests in a sprint?
- Tests on the developers’ side and the Definition of Done – how to convince developers to testing?
- Regression in Agile
Below, we would like to present ideas and solutions with our comments:
- How to fit tests in a sprint?
- Pair testing – if there is a problem, it is worth trying to solve it with another tester or developer. Pairing technique isn’t new, it derives from XP principles (Extreme programming).
- Tests = tasks – tests should be treated as any other tasks in a sprint; they are as important as tasks, that is why we take them into account during planning.
- Mocking – some functionalities or services can be replaced with mocks, therefore we can start test earlier.
- Using Test Driven Development (TDD) technique gives us a better designed and – https://stage-car.webenv.pl//tdd-tests/
Test sprint– there is no such thing as a test sprint!
- Dev = Tester – every developer should also be a tester and should be able to perform tests. The objective of delivering high quality software is the goal of the entire team and not just testers.
- Definition of Done – it is important to implement clear DoD and observe whether it is respected. Good DoD should reassure us that we will get a preliminary verified task to perform test on it (high quality from the very beginning).
- Limit Work in progress – reduction in the number of simultaneously performed tasks allows us to focus on current tasks and supports quick solutions – approach from Kanban methodology.
- Retro and planning – those meetings are to plan and improve further software development and process; if we haven`t finished testing in a sprint (it was not enough time for that) retro would be an appropriate place to analyse that situation and take protective action in the next sprint.
- Limiting a number of tests – not always we should/can test everything – it is important to focus on the most crucial things and do tests where the risk is high.
- Tests on the developers’ side and Definition of Done – how to convince developers to testing?
- Common responsibility – it is worth elaborating common goal-orientation and responsibility for a project, as well as its quality. Mentoring and coaching could be particularly helpful here.
- Sick leave for a QA – if a QA goes for a sick leave, developers will have to test 😉 – the idea seems to be extreme, but in difficult situation it can turn out to be the only good solution, thanks to that a team can gain more awareness.
- Code review QA <-> Dev – review among testers and developers. Developers can assist in technical solutions and testers in spotting specific cases or from the process side. Practising working in pairs allows us to take advantage of the synergy effect and additionally, they have educational character. It often happens that an hour of effective work of two people can be compared to a few hours or days of working alone.
- Best practices – adopting best practices to the project e.g. the boy scout rules, XP practices.
- Statistics, measures and visualisation of test statuses – all of that gives us a quick look into quality of a system and enables us to spot failed tests or other anomalies. Having a quick feedback, a team will be motivated to immediately correct an error.
- Developers deliver test log to QA- a developer tests basic scenarios and proves the correctness of solutions so tester can take care of uncommon cases.
- Previously prepared test cases for developers – before the implementation starts, it is worth talking with developers and showing them how an application will be tested; it will help in mutual understanding of the application before it is written and avoiding parts of errors related to the design.
- Tests among Developers – developers can perform basic tests among themselves.
- Demo (DEV/QA) before and after implementation – a tester and a developer talk about implementation and tests, thanks to that they can share their expectations.
- A list of tests to perform by a developer – it is worth preparing a list of things to be checked by a developer; it will raise the quality threshold of the task that testers will get at the test entrance.
- Tester merges so called feature-branch to master- a tester has the final decision on when to merge a given function, so that we minimize the risk of critical errors in the main branch and an overview of changes helps us to understand how a new piece of code integrates with the old one.
- Definition of Done – we should implement clear DoD and observe if it is respected; the entire team should agree on criteria for tasks completion.
- Regression in Agile
- Automation – if tests are time consuming, it is worth introducing test automation, having in mind potential project time.
- Regression based on changes, risk, metrics – there is no need to test 'everything’, we should focus on the most important things; a matrix of functionality dependencies that will tell us what we should test, if we changed module A, should also be helpful.
- If we inherited the project, we have to start paying back technical debt; without covering it with automated testing (worth considering inverted automation pyramid), it will be growing, and there will be more and more areas for testing – it is necessary to consciously manage the debt, which should be paid off when convenient.
- We don’t force tasks closure – DoD principles should be respected rather than ignored and relieved.
- We don’t get the idea of a stabilization sprint – in our opinion, it is a perversion of Scrum, because in relation to this idea, the team will no longer provide output every sprint, but only every second one. The objective of Scrum is working in pace that allows a team to maintain working comfort in accordance with the best practices.
- Test strategy – it is worth drawing up a strategy that will point out objective and range of tests, it will facilitate reasonable planning.
The topic of testing in agile methodologies certainly hasn’t been exhausted in this short article, which is a summary of the discussion panel conducted at the TestWarez. However, we hope that it will be a good list of ideas in answers to given problems.