And we are back for day three, the final day of the STP Online summit for "Agile Transitions".
Today's focus is, again, meant to help give some "How's" to play with, and today's panel will be real personal. How so? I'm one of the panelists!!! Henke Andersson is first up, so let's give him the floor.
Henke's talk is focused on "Excelling as an Agile Tester". What's cool about this is that we get a glimpse into how Agile is practiced in Sweden. According to Henke, the best way to do this is to start with the following principles:
- Take Responsibility
- Trust Each Other
- Solve Problems
- Think Independently
- Espouse Creativity
- Have Open Communication
- exploration
- discovery
- investigation
- learning
A valuable tool that we can use in this process is Session Based Test Management (SBTM). SBTM provides us with time boxed and focused test cycles. We create a focused mission and then develop specific testing charters. These can go a long way towards giving us the ability to dig in and learn more about the product. Since the checking is the automated component, that means we need to dig for much more rich information, and SBTM will often help give us that boost. It allows us to visualize our testing challenges differently. It also gives us a specific and measurable way to show what is being done while we test.
The overall goal of SBTM is that it provides very tangible benefits. We can determine our testing velocity (to go along with the development velocity, of course you'll need to track points to really get a handle on that), it provides valuable communication, it can give us a gauge as to the health of the product testing process, and it allows for a tangible way to bring testing out of the dark; we can truly point to the time we really spent testing and how much our testing was effective.
My talk is next, and I focused on what it means to be a Lone Tester in an Agile World. I'm not going to be able to blog and present at the same time, so I'm giving a greatly condensed version of my talk right here.
Being an embedded tester, a lone tester, in an agile team is a common reality. While I consider it my specialty, it's something that a lot of people deal with. I only made my transition a year ago, so I'm very familiar with the discomfort and the strange sensations associated with becoming part of an agile team for the first time.
The Agile Manifesto gives a lot of time to how to make quality software. It doesn't say anything about testing. It's not meant to. It's meant to help software developers create better quality code. They have many tools at their disposal to do that. They use Test Driven Development, Acceptance Test Driven Development, Behavior Driven Development, and a number of other tools to help them develop better quality code than what was developed using traditional methods. It's sliced way thinner, and the featured are added one by one, often rather quickly. There's a lot of tips and techniques that talk about testing... but where are the testers?
Testers are not excluded from the process. We are not "old fashioned anachronisms", we are still needed and we offer a great deal of value, but we are not there to do the Status Quo "testing" of yore. Theres' much less of a need for a "last tackle on the field", the "bug shield", the "guardian of quality". Many of the simple things that used to slip through are handled with TDD, ATDD, BDD, and Continuous Integration. Many of the "obvious bugs" are weeded out in these early stages, and we should rejoice. So much of the grind of testing is taken over by automation and unit tests. This is a good thing. Be happy, because there is *SO* much we can still look at and focus on as testers! We can ask the hard questions of the product, the ones that require an active and engaged brain to interpret and consider. No automated test will ever take the place of that! Also, we have the chance to be any number of things to our teams. We can be anthropologists. We can be journalists. We can get the whole story (or as much of the story as we can find).
Finally, along with the Agile Manifesto principles, I believe being familiar with and actively using context-driven testing principles will aid significantly in you effectiveness with an Agile team. The Agile Manifesto and Context-Driven Testing principles complement each other very well.
...and now I'm done.
Our final session is "Scott's Top Ten Takeaways" and a Q&A panel with several of the presenters. Note, not every takeaway is going to be specific to Agile Transitions. These are what Scott felt were the most valuable takeaways. A lot of us covered many of the same areas, so it should be no surprise that several of the top ten were things that we all mentioned.
10. Agile implies being guided by the principles of the Agile Manifesto.
9. In Agile, "Developer" refers to all of us who help deliver the product. Yes, that includes "Testers"!
8. Testing is Testing, Agile is "Context"... and checking is checking, independent of context.
7. In Agile "traditional testing formalities" may not be necessary. If there's value in doing them, then we will. If there isn't then we won't. If there's something in between that makes sense, then do that.
6. In Agile, like in healthy families, everyone pitches in! Everyone needs to step up to the plate and learn and try new things.
5. For Agile to succeed, you can't just "do" it, you have to "be" it.
4. Change is uncomfortable, big change even more so... even good change.
3. Successful Agile demands a collaborative, whole team culture. The team is responsible for success and failure. There is no "us" vs. "them".
2. Successful Agile demands that the whole team share the same vision and values.
1. At the core, Agile is about PEOPLE forming a culture around shared vision and values.
The presenters panel is now underway. Our first question is about Acceptance Testing, and who is responsible for it an who does it. I answered that it's important for the tester to put an emphasis on acceptance testing to make sure that we are doing what the people paying for the work want. The product owner is the one that ultimately accepts the stories that are created, but it's up to me to make sure I have given them as much information as I can to make sure that they can make the final decision to accept the stories.
Another question was focused on pairing and when testers can pair, when they should pair, and how to approach the subject. I'm lucky in the fact that one of our founders gave me some good advice. If I need to learn whats going on and I need to pair test or pair learn, just go and do it. Sit and become a third wheel if pairs are already determined. Borrow a developer to look at something you have discovered. Work in with others on the team where it makes sense. If you do your homework, you'll likely be able to find plenty of helpful hands and lowering resistance to the process.
There were a lot of questions about tools and which tools are appropriate and work. Ultimately, I would suggest working with the stack that your development team uses. If you are automating testing, the best approach is, where possible, to see if you can come up with a format that works for you and that you feel comfortable using. You may have to make a stretch to do that, and you may have to learn a tool to make that happen. You may need to make your own tools, but ultimately, it comes down to solving problems, not "solution probleming".
Testing vs. Checking: what a loaded phrase (LOL!). The truth is, we do both, all the time. Let's make sure that we are focusing on what's important for that particular period. If we need to automate, then do so. If we are doing SBTM, then do so. Do what is necessary for the time and the need.
Well, that's it. This was fun :). I'd definitely do it again if asked.
No comments:
Post a Comment