"How to adopt agile techniques while testing software?"

IndicThreads >> How do you go about the task of adopting Agile techniques on your testing projects?

Jonathan Kohl >> I learn the most by doing, by trying and failing, trying and succeeding. I work with smart people with a lot of skill, and if we find a particular technique works well, Ill try it on a testing team as well. I have found that there isnt necessarily a direct-correlation, but I regularly focus on communication feedback loops, which is something I learned from Scrum. Ill have a daily Scrum standup with a testing team, even if we arent on a Scrum team. That is one practice that seems to work well just about anywhere. Ive also adopted using 3x5 story cards for testing tasks, which was a habit I developed on XP teams where we logged bugs on those cards. I also like testing in pairs  there is a spark of creative learning and thought that occurs in pair-testing, which is something that XP taught me a lot about.

"The developers on one project discouraged me from doing anything but manual Exploratory Testing..."

Contexts and Collaboration

Some test automation practices I learned from Agilists were a lot of fun, but they didnt provide the information decision makers on the project needed. The developers on one project discouraged me from doing anything but manual Exploratory Testing at one point because that skill was something I could bring to the project that was missing. We can automate the tests, but we cant test the way you do. They said to me: We love your Exploratory Testing. I was doing virtually none of the generally accepted Agile Testing practices at this point, and this was working with hardcore XPers. We finished this story, do your magic and show us where the problems are theyd say. I took that as a glowing endorsement of how skilled software testing can work on an XP team. Those are the moments you shoot for.

"Do your magic and show us where the problems are..."

IndicThreads >> Agile and Extreme Programming are often confused, so is there a difference between testing using Agile techniques and testing using Extreme Programming techniques?

Jonathan Kohl >> Extreme Programming has excellent execution guidelines, and a vocal community of practice, so it can be hard to distinguish Agile Testing using another methodology from XP. This is one reason I wrote about testing on a Scrum team. Extreme Programming focuses a great deal on automated testing. Early on when I started working on a Scrum team, I didnt have pressures against manual testing, or towards automating all tests. When I started on an XP team, I was discouraged to do anything but automate tests. Testers will find it difficult when they start on a team that expects them just to program, or work on test automation. I have found that demonstrating skill using other testing techniques quickly overcomes the initial suspicion of a tester role.

"On an XP team when someone said tester, they often meant programmer doing testing,
and test was almost always an automated test."

There is a lot of confusion though because a lot of what we do involves vague words. I deliberately made a distinction between conventional software testing and what you might find on an XP team because I was finding there was confusion. On an XP team, when someone said tester, they often meant programmer doing testing, and test was almost always an automated test. Testing usually meant developing and executing automated unit tests or automated user acceptance tests.

Jonathan and Elizabeth

Now if you ask someone like me who has been a software tester for a while what these words mean, you will probably hear a different perspective. Test will include automated and manual tests in all sorts of forms; tester will mean anyone who is doing testing, or someone who works as a professional software tester. Testing, as James Bach would say is asking questions of software so we can make an assessment of it. We can express those questions in tests in all sorts of forms. Automated testing is just part of the picture, and like any technique, it comes with its own pros and cons.

As I started working on more projects, and writing and speaking about agile projects, more people started coming up to me and asking for help. On one project, agile developers and dedicated software testers on another team would have meetings, and they would use a seemingly shared language. They would agree, leave the meeting and work on tasks, and then get frustrated. A development lead on this team pulled me aside and asked me what was going wrong. I asked him to start clarifying what the testers were agreeing to, and to avoid jargon. Within a couple of days they found the source of the problem was miscommunication. Once they realized what each other were talking about, and what they needed, they were all able to meet the needs of the team.

" If I end up testing in a new environment that feels uncomfortable, I remember that good communication and skilled testing always prevail."

I have a rule of thumb: If I end up testing in a new environment that feels uncomfortable, I remember that good communication and skilled testing always prevail. If as a software tester Im not adding value, Im completely willing to move on to a different project. In my experience, skilled testing seems to transcend the various methodologies and stand on its own.

"Skilled testing seems to transcend the various methodologies and stand on its own..."