Pete Walen asked this question: For software testing professionals/craftspeople, what is it that differentiates Agile Testing from any other testing?
My reply:
- I have wondered the same myself. And as with most things, it seems like it is contextual. It depends on what you're working on, who you are working with, what is available to you, who is available to you, etc.
It also depends on your mindset and behaviours. I think it's a openness and a willingness to learn and working together closely, perhaps closer than people from some environments are used to. You need awareness of yourself, and whether or not it is a place for you, things move quicker and you can't hide.
In some agile environments some of the Testers will be very technical and focus on automation and knocking up tools, frameworks, etc to help with the testing. But that doesn't mean that a Tester with different skills won't be able to add value. And ideally it's good to have a mixture.
I also think it's not so much what differentiates A/agile Testing from from any other testing. It's that Testers who have been doing the bare minimum are more exposed in a agile(ish) environment. Issue with that is that some people don't realise they are doing the bare minimum because they are doing what is asked of them.
People who have tried to change things, or looked for ways to improve things will probably be able to adapt easier to agile.
Those who have not been increasing their skill set, learning new things, etc can find it hard when things are moving quickly. Those who are used to spending days/weeks/months knocking up test scripts to follow may find themselves a little lost when they don't have that security blanket.
You need to be able to manage yourself and get on with things and in a more agile environment you are able to do so.
The thing is, there is no one, true, right answer because both 'agile' and 'testing' mean different things to different people so you get my rambley answer :-)
Huib Schoots has a excellent post about agile testing.
Sunday, 31 March 2013
Saturday, 30 March 2013
Wednesday, 27 March 2013
No time left at the end of the sprint for proper testing
In the Agile Testing Linkedin Grp the following was posted:
No time left at the end of the sprint for proper testing
Designers tend to add and change code
until the end of a sprint, not leaving enough time to do all the agreed
testing. At the start of a sprint, we assign rough time estimates to
user stories, taking both design and test activities into account. Some
tests are automated and run during the night.
However, other tests need manual preparation of data and partly manual execution and result analysis. There is also some amount of exploratory testing involved. During the sprint, there always seems to be a reason not to deliver yet to test: fixes, improvements and design updates. At the end of the sprint, little time is left for manual testing, far too less for running the tests, analyzing and repairing eventual bugs, retest and results logging.
What advise do you have for me, so that I can claim and really use a fair amount of the sprint time for testing?
However, other tests need manual preparation of data and partly manual execution and result analysis. There is also some amount of exploratory testing involved. During the sprint, there always seems to be a reason not to deliver yet to test: fixes, improvements and design updates. At the end of the sprint, little time is left for manual testing, far too less for running the tests, analyzing and repairing eventual bugs, retest and results logging.
What advise do you have for me, so that I can claim and really use a fair amount of the sprint time for testing?
With a follow up post of:
What I called
'delivery' is not a heavy weight process wall. It is just a oral
notification in the team stand up meeting that some story is ready for
test. Our way of working is pretty much in line with all points you
mention: except for point 5. "Testing is a fair amount of the sprint if
done well". I think 1 day left for testing out of a 2 week sprint is not
this 'fair' amount. The pattern that I have to cope with is: several
user stories are coded in parallel and they tend to be 'ready for test'
all at the same time, that is: 1 day before sprint end. The tester is
involved in functionality and architectural discussions during the
sprint and prepares test data and test scripts, ready to 'push the
button' when a story is ready.
My (currently unpublished) comment (with minor changes):
So, based on the info you've provided I'm going to make a bunch of suppositions along with ask a number of questions.
1. Is there a definition of 'done'? Does it include testing? If so, it seems like it's being ignored?
* If it is being ignored are there retrospectives held? What happens when this is brought up?
* Is the issue being recognised by the rest of the team?
* Is it being recognised and cared about?
* Are the powers that be aware?
2. Are the stories broken up into tasks? If so is it possible to test the tasks?
3. If what you are working on is broken up into (small) stories and setting aside the late adjustments there should be a constant stream of stories coming through, if not, has this been looked at? If so, what was the outcome?
4. Is it possible for team members to pair? IE testers and devs, ba's and testers, ba's and devs, etc.
5. Is there a visual representation of story process? Visible by everybody?
6. Is this way of working new to the team/company? Was there help making the transition? If there was, were they any good? Were any new people with more experience in this way of working hired?
7. Are you/the testers prepared to play hard ball? You can't possibly test a sprints worth of work in a day, so don't try.
8. How are the late adjustments getting into the story? They should be judged on value and as a team decided on whether or not they get into the sprint. Failing that then a story/stories can be dropped to allow for changes.
9. Is there a scrum master type role? Is he/she someone who has gone and gotten the CSM or are they experienced?
* Experience is very hard to judge, how is it done?
10. Is there a way to prepare test data through automation?
11. Is there any skill sets lacking in the team in general?
It doesn't seem like you have a testing issue, you have a team/culture/mindset issue.
1. Is there a definition of 'done'? Does it include testing? If so, it seems like it's being ignored?
* If it is being ignored are there retrospectives held? What happens when this is brought up?
* Is the issue being recognised by the rest of the team?
* Is it being recognised and cared about?
* Are the powers that be aware?
2. Are the stories broken up into tasks? If so is it possible to test the tasks?
3. If what you are working on is broken up into (small) stories and setting aside the late adjustments there should be a constant stream of stories coming through, if not, has this been looked at? If so, what was the outcome?
4. Is it possible for team members to pair? IE testers and devs, ba's and testers, ba's and devs, etc.
5. Is there a visual representation of story process? Visible by everybody?
6. Is this way of working new to the team/company? Was there help making the transition? If there was, were they any good? Were any new people with more experience in this way of working hired?
7. Are you/the testers prepared to play hard ball? You can't possibly test a sprints worth of work in a day, so don't try.
8. How are the late adjustments getting into the story? They should be judged on value and as a team decided on whether or not they get into the sprint. Failing that then a story/stories can be dropped to allow for changes.
9. Is there a scrum master type role? Is he/she someone who has gone and gotten the CSM or are they experienced?
* Experience is very hard to judge, how is it done?
10. Is there a way to prepare test data through automation?
11. Is there any skill sets lacking in the team in general?
It doesn't seem like you have a testing issue, you have a team/culture/mindset issue.
I'd like to know what I've missed?
Wednesday, 20 March 2013
Sunday, 10 March 2013
Inbetween talks - Agile Dev Practices 2013
So #agiledevprac has been and gone.
I had a great time.
During the Monday my fellow speaker Ant and I had a chance to hang out with Maik Nogens.
Maik's a great guy, if you see him (you can't miss him, he's 8ft tall, although everybody looks 8ft tall when they are standing next to me) say hi.
We had a walk around Potsdam and sampled a couple of Bratwurst. This is my second time in Potsdam and I think it's a great place, nice, quiet and picturesque.
On the first night there was a speakers dinner at Walhalla.
Jose stood up and gave a short speech welcoming everybody.
The food itself was OK, the company was great.
Ant and I had both chosen a fish dish which came with bacon sauce. BACON. SAUCE. How could you not?!
We'd been waiting and looking forward to it for weeks. We'd been imaging all sorts of amazing creations.
It was one of the biggest disappointments ever. It is a cream sauce with bits of bacon in it.
Ant and I shared a table with a number of people and we spent the most time talking to Ray Scott and Vagif Abilov.
I've come across Ray and Vagif before in my travels but have never had a chance to sit down and have a proper talk.
It was great to do so.
After dinner there was a short visit to the hotel bar and then off to sleep.
Over the next few days there were:
- Pop-up coding dojos.
- Conversations all around with people from the world over.
- I would love to list the names of everybody I had a conversation with but there are too many.
- Ant drank his first ever full pint of beer, followed by his second, and third, etc.
- A social dinner event complete with improv comedy troupe.
- Ant and I were on the same table and again had a number of diners with us. During dinner we spoke mostly with Ray Scott and Krystian Kaczor.
- After the meal we spoke with a few more people.
- A group of us went for a meal, sat down and realised none of us speak German.
- We had 2 English guys, 1 Hungarian, 2 Spanish guys and 3 Russians.
- Luckily, one of the waiters spoke Russian so we were able to get a meal organised.
Unfortunately I didn't get the names of two of the (Russian) guys at dinner, the rest are:
In my opinion, over the next few days there were some good talks, some OK talks and some talks that didn't quite work.
Conferences are essentially a meeting of people who want to contribute, teach, learn and share.
It's not just attending the talks.
Make the effort to meet new people and talk and you will get untold value from a conference.
Saturday, 9 March 2013
London Tester Gathering - Tues 19th March - The Shooting Star
The March London Tester Gathering will be on Tuesday 19th March at The Shooting Star.
Address:
125-129 Middlesex St, London E1 7JF
The plan:
We have a room from 6:00pm onwards
Sponsorship:
Guest:
Michael Bolton
RSVP.
Hope to see you there.
Cheers and kind regards
Tony Bruce
Address:
125-129 Middlesex St, London E1 7JF
The plan:
We have a room from 6:00pm onwards
Sponsorship:
Guest:
Michael Bolton
RSVP.
Hope to see you there.
Cheers and kind regards
Tony Bruce
Reasons to be at TestBash 2.0
Program
Check out Make The Most Out Of TestBash 2.0
Don't miss out, you'll be grumpy if you do!
- I'll be there!
- Talkers from all over the world.
- Attendees from all over the world.
- You can share.
- You can learn.
- You can teach.
- Did I already mention I'll be there?
- You can meet.
- You can discuss.
- Ministry Of Testing put on good events.
- You can talk authors of a number of books:
- Agile Testing: A Practical Guide for Testers and Agile Teams
- The Secrets of a Buccaneer Scholar: How Self-education and the Pursuit of Passion Can Lead to a Lifetime of Success
- Bepaal je koers! Toekomst en Trends in Testen
- Brighton is a great place to visit.
- It's cheap!
- There's a get together the night before.
- Apparently some people feel the need to run (for no reason) so there's a joint run in the morning.
- There's a leancoffee.
- There is a chance to do some really short talks.
- Good way to do your first talk.
- Good way to raise a point.
- Good way to start discussion.
Check out Make The Most Out Of TestBash 2.0
Don't miss out, you'll be grumpy if you do!
Subscribe to:
Posts (Atom)