1. Surviving in an Agile Environment Markus Clermont
2. Agile Software Development (1)The Agile Manifesto states: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
3. Agile Software Development (2)Some further principles: Release early & release often Open to changing requirements. Any time. Much informal communication between stakeholders Frequent refactoring; changes in the architecture and the design of the software Teams are meant to be self-organizing Small "family-size" teams work on subsets of the problem. Functional decomposition Little communication between teams required.
4. What does that mean for QA Once the features are developed, QA is meant to make sure it works QA often starts only after the product is finished Focus on testing That makes us really QC, not QA, Relying a lot on a well-known, well-defined process, Clearly defined interface between "QA" and "dev". We tend to take ownership of quality in the traditional development. That starts too often only when the development is already finished. There is Agile Development until QA gets involed.
5. What changes need to be made? 1. Dont take ownership of quality. 2. Get involved early. 3. Review the design, participate in code-reviews. 4. Give positive re-enforcement and point out problems. 5. Make sure that your team is an integral part of the dev-team 6. Make sure your tools are part of their toolbox. 7. Make sure that the needed skills are in the team. 8. Dont do the release-process. 9. Become an integral part in the customer - developer interactions.10. Working software that satisfies the customer is the goal.
6. Dont Take Ownership of Quality Only the developers can create the quality. We should make it really easy for them to create quality: Be a consultant and suggest creative ways to solve problems Help choosing the right tools for the problem Continuous builds UI-Test tools Testing frameworks Provide customization of these tools. Be the advocate for quality towards project-management. Test-Automation is a common pitfall.
7. The Test-Automation Pitfall Short release cycles: Not enough time for manual testing Not enough time to properly automate all the tests. Lack of documentation: No deep understanding how a certain scenario should be tested. No way to find out what changed in the system that can make my tests brake. Teams start to spend more and more times on investigating and fixing breakages. Credibility of the tests suffer.
8. So, what to do? Start at the bottom of the pyramid: Test-Driven Development (Frequent refactoring) High unit-test coverage, Education & Best Practices Reduce the number of "big" tests. Make the smallest possible tests, and a few big end-to-end tests. Execute the tests at every change in the code-repository Make the person who breaks them fix them On the long run, Have those who provide a new feature write the integration- and end-to-end tests, but make it really easy to do so.
9. Get involved early Always look at the testability of new features, Early feedback is likely to be taken into account. Help to make time plans more realistic Less pressure on the developers means better quality. Time requirements for testing can be taken into account
10. Review the Design and the Code Design - Quality is an important aspect of the software quality: Re-usability, Maintainability, Testability Speaking up early can help to prevent these problems. And it makes it easier to get more and better tests. The same is true for code. Two implementations of the same feat Test-code is code, too. Is the code easy to test, are the tests sufficient, good, and adequate?
11. Give positive re-enforcement Doing quality software should be fun. Look for reward mechanisms inside your company Use them... Talk to the manager, Spend money on an offsite Do a testing-competition, with a cool prize Dont forget to point out problems, too.
12. Team Integration Agile development has a lot of informal communication, and undefined processes. If the QA team is not in the middle of that, it is almost impossible to catch up later. Allows to recognize testing / quality challenges early on and react. Giving early feedback becomes easier, too. Increases the technical understanding of the product. More valuable feedback Better solutions to quality problems. Gives a wider view on the problems a project is facing.
13. Tool Integration The organizational separation of QA and Dev-Team often reflects in separate "Tool-Worlds" "Tools" for the developers: Programming Language IDE Libraries and Frameworks "Tools" for QA: Process description Test-Automation Tools, Scripts Bug-Tracking Transferring ownership is hard if the tools are unknown. Try to speak the same language.
14. Skills Not every test-engineer is a software-engineer. Difficulties: Communication, Gaining technical respect, Finding the best way to test a product, Typically very low-level (unit-tests), and high-level (end-to-end) tests. No integration tests. Finding flaws in the design. What can be done? Train your test-engineers about software-engineering, Programming, Design, Unit-Tests.
15. Dont do the release-process In the release process quality problems show themselves in their most powerful way. Whoever is driving the release-process has most interest in following the best practices we preach If not yet, wait 2 or 3 release cycles. On-Call duty is a further incentive :) The decision to release will always be a trade-off.
16. Participate in the customer - developerinteractions. In agile development, UAT is often done by the customer (or the direct representative) The only person who really knows how the product should work, is the customer. The customer - developer interaction is the single most important source for requirements. Sitting on the same table with the customer helps to clarify requirements when they are posed figure out the pain points with the current solution understand requirements ourselves for better testing thereof.
17. Working Software is the Goal For everything we do, ask: How does that contribute to that goal? Do we need to do it? More often? Less often? Can we do it different- better, faster, more effectively? The common interest with development is to give the customer software that satisfies the needs (see the "release trade-off"). Constructive feedback.