Since my last post went into quite some detail of sessions at the Agile Testing Days, I wanted to write a bit more about this conference to live up to the large variety of different sessions it offers.
QA, Dev and Ops
One thing the conference revealed to me is that not only should teams be cross-functional, but also the members should have knowledge in multiple fields of the development process. Bringing QA and Dev closer for more effective development and improved quality is old hat. However at this conference I heard about the term ‘QaOps’ for the first time.
I myself, getting more and more engaged in the DevOps activities, realized that operational knowledge can help you when working in test automation. For one thing DevOps skills can be helpful improving your test setup itself and no one knows how to improve the test suite better than someone working with it on a daily basis. Additionally, I think it has some advantages if you know about implementation details of the systems you are testing. Being aware of its weaknesses makes finding bugs easier. I believe that goes not only for knowledge about the software development, but also on the operational implementations.
To give an example of how DevOps principles can affect your test automation, I’m going to pick out a section from Carlos Sanchez’s talk about Continuous Delivery. After an introduction on Continuous Delivery in general, he introduced some of the tools he uses for achieving a high order of automation like chef, puppet, vagrant and of course … docker. Later on Carlos described how he dockerized his test suite. This approach somehow reminded me of one of my projects I wrote about. What I really liked on Carlos’ solution was that his test environments also started containerized. I love the idea of having ephemeral environments for running your automated tests on. With docker it’s even possible to save your container’s state if tests failed and then debug what went wrong. If your test suite is green just throw the environment away. That way there is no need to clean up your test data, which is important to keep for debugging in my opinion.
In contrast to the previous paragraph I’d like to present one of my personal insights AgileTD gave me. When working in QA, although I was functioning as a test engineer most of the time, some sessions showed me that learning more about manual testing could enhance my QA skills. First of all, finding bugs in a new feature manually will probably be much faster than writing an automated test. Fast feedback from testing is really important for a high-quality development cycle. Also I realized that it takes some time for me to get into a certain piece of a system. Thus starting with some Exploratory Testing first could save me from throwing away too much code and planning my automated tests better. Another reason that speaks for improving Exploratory Testing skills is learning to look at a system from a different, user-centric perspective.
I attended two workshops Black Ops Testing and Agile Exploratory Testing. Learning about techniques for structuring tests with a good test design, managing activities in timeboxed sessions or documenting and reporting the outcomes of a session, made me want to know more about Exploratory Testing. Sounds like some good new years resolutions.
Needless to say various sessions, especially the keynotes, dealt with agile development methodologies and compatible corporate cultures. For covering this topic I want to share one session which was held, in part, by a kreuzwerker employee. Fanny was sharing a keynote slot with Alexander Schwartz. They told us about some Insights From Happy Change Agents. I guess this talk was kind of special for three reasons.
First of all there are not too many pair talks aside from Lisa Crispin and Janet Gregory of course.
Furthermore most of the talks at AgileTD deal with success stories. Fanny and Alex talked about changes they realized in teams they had worked with which failed. Fanny introduced some serious LEGO play in the SCRUM planning. Alex wanted to get rid of a testing tool which was superfluous in his opinion. However, their teams didn’t accept the changes they established and their visions to improve the collaboration didn’t work out. Fanny and Alex identified that the problem of their approach for implementing ideas was deciding changes on their own. Involving the team in the decisions would have obtained more acceptance.
Also involving the audience made this keynote unique in my eyes. While preparing their presentation Alex showed Fanny some exercises he learned when practising on aikido. They came up with the idea to adjust the exercises slightly to demonstrate what happened when they forced their teams to accept their amendments. So they instructed the audience to pair group and perform the first exercise. One had to close his eyes and the other one had to bring the partner to a place of his choice. In the second exercise the leader shouldn’t drag the partner, but lead him or her by moving together. After these exercises Fanny and Alex asked the audience which exercise was more effective and comfortable. Figure out which was the answer.
Forcing the team to change causes frustration for the team and for the coach, whose team didn’t accept the change, as well. So the give-aways Fanny and Alex wanted to share is not to avoid amendments, but planning and implementing them together with your team. Fanny and Alex published their slides for those who are interested.
In conclusion I would say AgileTD was a great conference with excellent talks and workshops, and nice attendees who create a quite familiar atmosphere even when there are around 500 participants. Also there are nice activities offered around the conference. Hope we see you there next year.
P.S. You may be curious about the cover image. It shows some happy testers just successfully completing the scruminc eXtreme Manufacturing Build Party with the aim of screwing together a car in less than a day. Oana summarized her key learnings and the real world associations at her blog very well.