Many teams adopt agile practices without a good idea of what to do differently than traditional process methodologies. Often the team will get the direction to "go agile" as a management edict. Perhaps they'll adopt Scrum, or Kanban and implement the ceremonies and approaches prescribed by those process frameworks.
For a while, they're happy. They can go fast and cut corners and rationalize about anything because "they're agile". But then, something happens and they are unable to respond to change. They're unable to "go fast". Production issues and brittle designs which don't support change will prevent the changes they need. The words "technical debt" become part of the team's vocabulary.
The main reason this happens is drift away from the values and principles of the Agile Manifesto. Agile is, simply, a set of values and principles. Process frameworks, like Scrum, Kanban, or even SAFe (The Scaled Agile Framework) depend on intelligence, skill and approaches which support these values and principles. It's not enough to do daily stand-ups and demonstrate working software every two weeks. Teams need to proceed in a sustainable fashion, they need to pay specific attention to technical excellence.
Teams that are agile are often surprised to realize that technical excellence is an Agile Principle. Agile is not about cutting corners, or going fast, It is about delivering value to the customer, getting empirical feedback quickly from the customer and responding to change. If the code has not been designed to be easily changed. If the safety net of the right kind of test automation is not present to support refactoring and ensuring behavior developed in sprint 1 is still working in spring 10, the team begins to struggle to support change and wonder if Agile is such a great idea after all.
Many teams never realize that they're not doing anything different than they had been in the old process approaches, except that they're doing it with less discipline, less requirements and less design than they had in the past. They treat their sprints, and stories, as mini-waterfalls. In fact, some teams automatically have the same "phase gates" as they had in the old plans. They move stories from "requirements" to "analysis" to "design" and then "code", "integrate" and "test". Just like in the old days.
Many teams with QA groups spend inordinate amounts of time translating stories to "test cases" and "suites" in tools, like Rally or VersionOne. They dutifully execute their test plans but they realize that, with the speed of iterative development, the amount of time to execute these regression tests increases, sprint over sprint with no hope of catching up and with very little new information being generated by the test cases.
Teams with separate QA teams will often code new features right up to the end of the sprint and stories get accepted without a clear definition of done, no code review, no automation and with poorly designed implementations. This means the QA team has to work weekends or testing has to be scheduled in the next sprint Either way is not sustainable and creates all manner of problems for these teams. For example, what is the velocity of a team that discovers a major defect in the sprint after the story was accepted?
So what is Agile Testing and how is it different from traditional testing? Who is "The Agile Tester?"
First and foremost The Agile Tester is someone who is passionate about embracing the techniques that support Agility and incremental development. The Agile Tester recognizes that we need to do something different. We need to "cease dependency on manual inspection" as warned J. Edward Deming, more than 5 decades ago.
The Agile Tester recognizes the "whole team" approach to quality and software delivery. Specifically, we value collaboration with the business/customers to help us ensure we're building the right thing. That we share a solid understanding of what it is we're building.
The Agile Tester recognizes the significant skill a good tester will bring to an iterative development process, especially when they are a part of the process from the very beginning, at the requirements level.
Using guidelines like Brian Marick's "testing quadrants" The Agile Tester recognizes that we have test automation in our development processes at the right level for what is being automated. We recognize the value of unit tests to help support refactoring, business facing integration tests showing progress and that desired behavior stays working. We have automation around our non-functional requirements and we integrate constantly, relentlessly.
The Agile Tester adds high-value "exploratory testing" to the mix and takes advantage of what we're really good at to discover new information about the software.
Embracing the solid values and principles of "XP" (Extreme Programming) The Agile Tester supports pairing, test-first approaches, and is a student of exceptional object oriented principles and patterns.
One of the most powerful tools The Agile Tester has in his/her toolkit is "Specification by Example" (Behavior Driven Development) which is also known as "outside-in development" where ambiguity is removed and shared-understanding increased by the use of collaborative sessions which express requirements as concrete examples. This approach results in "executable requirements" which has a profound affect on our iterative processes.
The Agile Tester is someone who applies all of the above, and more, as a passionate member of a performing agile team.
For a while, they're happy. They can go fast and cut corners and rationalize about anything because "they're agile". But then, something happens and they are unable to respond to change. They're unable to "go fast". Production issues and brittle designs which don't support change will prevent the changes they need. The words "technical debt" become part of the team's vocabulary.
The main reason this happens is drift away from the values and principles of the Agile Manifesto. Agile is, simply, a set of values and principles. Process frameworks, like Scrum, Kanban, or even SAFe (The Scaled Agile Framework) depend on intelligence, skill and approaches which support these values and principles. It's not enough to do daily stand-ups and demonstrate working software every two weeks. Teams need to proceed in a sustainable fashion, they need to pay specific attention to technical excellence.
Teams that are agile are often surprised to realize that technical excellence is an Agile Principle. Agile is not about cutting corners, or going fast, It is about delivering value to the customer, getting empirical feedback quickly from the customer and responding to change. If the code has not been designed to be easily changed. If the safety net of the right kind of test automation is not present to support refactoring and ensuring behavior developed in sprint 1 is still working in spring 10, the team begins to struggle to support change and wonder if Agile is such a great idea after all.
Many teams never realize that they're not doing anything different than they had been in the old process approaches, except that they're doing it with less discipline, less requirements and less design than they had in the past. They treat their sprints, and stories, as mini-waterfalls. In fact, some teams automatically have the same "phase gates" as they had in the old plans. They move stories from "requirements" to "analysis" to "design" and then "code", "integrate" and "test". Just like in the old days.
Many teams with QA groups spend inordinate amounts of time translating stories to "test cases" and "suites" in tools, like Rally or VersionOne. They dutifully execute their test plans but they realize that, with the speed of iterative development, the amount of time to execute these regression tests increases, sprint over sprint with no hope of catching up and with very little new information being generated by the test cases.
Teams with separate QA teams will often code new features right up to the end of the sprint and stories get accepted without a clear definition of done, no code review, no automation and with poorly designed implementations. This means the QA team has to work weekends or testing has to be scheduled in the next sprint Either way is not sustainable and creates all manner of problems for these teams. For example, what is the velocity of a team that discovers a major defect in the sprint after the story was accepted?
So what is Agile Testing and how is it different from traditional testing? Who is "The Agile Tester?"
First and foremost The Agile Tester is someone who is passionate about embracing the techniques that support Agility and incremental development. The Agile Tester recognizes that we need to do something different. We need to "cease dependency on manual inspection" as warned J. Edward Deming, more than 5 decades ago.
The Agile Tester recognizes the "whole team" approach to quality and software delivery. Specifically, we value collaboration with the business/customers to help us ensure we're building the right thing. That we share a solid understanding of what it is we're building.
The Agile Tester recognizes the significant skill a good tester will bring to an iterative development process, especially when they are a part of the process from the very beginning, at the requirements level.
Using guidelines like Brian Marick's "testing quadrants" The Agile Tester recognizes that we have test automation in our development processes at the right level for what is being automated. We recognize the value of unit tests to help support refactoring, business facing integration tests showing progress and that desired behavior stays working. We have automation around our non-functional requirements and we integrate constantly, relentlessly.
The Agile Tester adds high-value "exploratory testing" to the mix and takes advantage of what we're really good at to discover new information about the software.
Embracing the solid values and principles of "XP" (Extreme Programming) The Agile Tester supports pairing, test-first approaches, and is a student of exceptional object oriented principles and patterns.
One of the most powerful tools The Agile Tester has in his/her toolkit is "Specification by Example" (Behavior Driven Development) which is also known as "outside-in development" where ambiguity is removed and shared-understanding increased by the use of collaborative sessions which express requirements as concrete examples. This approach results in "executable requirements" which has a profound affect on our iterative processes.
The Agile Tester is someone who applies all of the above, and more, as a passionate member of a performing agile team.