I've gathered up a list of blog posts related to the London #TesterGathering Workshops 2013.
I'll keep adding as I come across any but If I've missed any please let me know.
Pre:
Carlos Ble - London Tester Gathering Workshops
@webcowgirl - The Cheater's Guide to Levelling Up
Post:
Stephen Janaway - London Tester Gathering Workshops 2013
Simon Knight - Focussed Awareness
conferize - Attend any conference online.
R B's Prezi
Dan Ashby - Lessons from the Black Ops Testing LTG Workshop!
Showing posts with label ATDD. Show all posts
Showing posts with label ATDD. Show all posts
Thursday, 31 October 2013
Friday, 14 June 2013
Weeknight Testing: Is ATDD perceived to be the next silver bullet?
The next Weeknight testing session is on the 19th June at Skillsmatter
We will hold a workshop to demonstrate:
Register here
We will hold a workshop to demonstrate:
- why software investigation is needed even if you have acceptance criteria.
- the difference between checking off acceptance criteria and investigating the software with exploratory testing sessions.
- how you can strengthen your acceptance criteria checks with information gathered through exploratory testing sessions.
Register here
Wednesday, 6 February 2013
It doesn't make sense.
I stole this, I changed two words:
People work with one set of ideas about how the software is. Everything they do, be it experimental or theoretical work, is informed by, and framed within, that set of ideas. There will be some evidence that doesn't fit, however. At first, that evidence will be ignored or sabotaged. Eventually, though, the anomalies will pile up so high they simply cannot be ignored or sabotaged any longer. Then comes crisis.
13 Things That Don't Make Sense - Michael Brooks.
To me, this is a pretty good explanation of software development, although of course, not in all cases of software development.
It's also a pretty good reason why things like agile, devops, devs, bdd, etc have come about.
We do approach things with a set of ideas and we do frame things with that set of ideas in mind.
We stick to our own ideas, even though some of our ideas have been born out of others' ideas and thoughts and words and we've blindly made them our ideas and thoughts.
- For more on this train of thought refer to Leprechauns of Software Development or various kinds of certification.
When we have ideas that we have actually conceived it can be a good thing because we all have different experiences, we all have different thoughts, we can all add something.
I think the problems occur when we don't let go of theses ideas (when beneficial) and learn from others experiences and listen to others ideas.
A lot of time we don't conceive ideas together for something we are supposed to be working on together.
What's wrong with us?
Doesn't make sense to me.
Make sense to you?
Continuing with the excerpts from 13 Things That Don't Make Sense The next paragraph starts with the sentence:
Crisis, Kuhn said, is soon followed by the paradigm shift in which everyone gains a radically new way of looking at the world.
Does it? Not for software development, not as much as needed.
In the context of software development the sentence would read:
Crisis, Kuhn said, is soon followed by a attempt to throw more people at, work longer hours to stem and follow the procedures that caused the crisis in the first place until the next crisis arrives.
What's wrong with us?
Wednesday, 2 January 2013
London Tester Gathering - Tues 15th January - The Shooting Star
The January London Tester Gathering will be on Tuesday 15th January at The Shooting Star.
Address:
125-129 Middlesex St, London E1 7JF
The plan:
We have a room from 6:00pm onwards
Talks:
Weeknight Testing Q&A
Net-A-Porter are hiring.
Sponsorship:
Net-A-Porter
http://www.net-a-porter.com
Hope to see you there.
http://www.meetup.com/agiletesting/events/95777622/
Cheers and Kind Regards
Tony Bruce.
Address:
125-129 Middlesex St, London E1 7JF
The plan:
We have a room from 6:00pm onwards
Talks:
Weeknight Testing Q&A
Net-A-Porter are hiring.
Sponsorship:
Net-A-Porter
http://www.net-a-porter.com
Hope to see you there.
http://www.meetup.com/agiletesting/events/95777622/
Cheers and Kind Regards
Tony Bruce.
Friday, 2 March 2012
Re-Regression Checks + Regression testing = Regression testing?!
Sharath recently wrote a blog post to which I decided to write my own post in response.
Sharath's post is here.
Sharath mentioned being slightly confused by BDD and ATDD which I see a lot, however the confusion I see is based on my ideas of what is what, make your own up and decided.
I've included some stuff from Liz as she writes better than me do write as well as my own 2 cents.
ATDD vs. BDD, and a potted history of some related stuff
Acceptance Criteria vs. Scenarios
What is interesting to me though is that as far as I've seen, ATDD doesn't include the business as much as BDD does. I see a lot of Testers and Devs getting together for ATDD and for BDD alot of everybody getting together like PO's, BA's, business people, etc. That is where I personally see a difference. I prefer BDD and getting as many people as I can involved.
On the other hand, call it whatever name works for you.
Back to Sharath's blog.
One of the things that can (and in my opinion should) be done is that every time a bug/issue is reported automation is written that would find that issue before the issue is fixed - essentially creating a regression/consistency suite/pack/whatever.
As well as automating any useful information gained from the ET.
I've also tried to use a test points reference (idea from paper by James Lyndsay and Niel van Eeden) with little success, mainly as I didn't push it hard enough.
What I have done is similar to what Sharath has done and created a mind map with areas for further investigation/automation. Had slightly more success with that.
If you don't have people to automate you can essentially use your regression doc (mind map, doc, whatever it may be) to cover off areas, splitting it between the whole team.
I also try and push the idea of a demo before check in, together we can spot anything obvious before it gets checked in (and therefore a bug/issue).
There is really no one answer, is a case of finding what works for you with the people you have.
Sharath's post is here.
Sharath mentioned being slightly confused by BDD and ATDD which I see a lot, however the confusion I see is based on my ideas of what is what, make your own up and decided.
I've included some stuff from Liz as she writes better than me do write as well as my own 2 cents.
ATDD vs. BDD, and a potted history of some related stuff
Acceptance Criteria vs. Scenarios
What is interesting to me though is that as far as I've seen, ATDD doesn't include the business as much as BDD does. I see a lot of Testers and Devs getting together for ATDD and for BDD alot of everybody getting together like PO's, BA's, business people, etc. That is where I personally see a difference. I prefer BDD and getting as many people as I can involved.
On the other hand, call it whatever name works for you.
Back to Sharath's blog.
One of the things that can (and in my opinion should) be done is that every time a bug/issue is reported automation is written that would find that issue before the issue is fixed - essentially creating a regression/consistency suite/pack/whatever.
As well as automating any useful information gained from the ET.
I've also tried to use a test points reference (idea from paper by James Lyndsay and Niel van Eeden) with little success, mainly as I didn't push it hard enough.
What I have done is similar to what Sharath has done and created a mind map with areas for further investigation/automation. Had slightly more success with that.
If you don't have people to automate you can essentially use your regression doc (mind map, doc, whatever it may be) to cover off areas, splitting it between the whole team.
I also try and push the idea of a demo before check in, together we can spot anything obvious before it gets checked in (and therefore a bug/issue).
There is really no one answer, is a case of finding what works for you with the people you have.
Monday, 25 July 2011
ATDD is like a fight in the playground.
Does anybody else find that ATDD is like a fight in the school playground?
I've had limited experience with ATDD but from what I've seen you have to be there from story creation (picking a fight) or at least you have to be very nearby (standing near the fighters and therefore at the front of the crowd) otherwise you'll miss it all (because you're stuck at the back of the crowd).
I've found that everybody is willing to get involved with writing the examples but not always together.
If you're not at the front or involved in the fight directly then you have to fight your way through to get involved.
I've found that sometimes before Dev or Test get near a story the AT's are already written. This might be because of a easy to use DSL or having BA's that can code.
Either way it means that the sharing of knowledge and shared understanding of the requirement that happens when people get together to write the AT's is missed out.
It also means there's no discussion. Why would you discuss what is already there and waiting?
It also means that the AT's are written to one person's perception rather than the team.
Which means there is potential for things to be wrong.
I've also found that sometimes Dev's are so eager to code (like kids to candy) that they write the AT's and are off coding and Testers have no idea what's in the AT's and may have to edit and/or add to them.
So how to you handle that? Is there a way? Unless you're monitoring what everybody is doing I don't think there is, all you can try and do is open up communication and ask to be involved in the AT writing and keep asking otherwise you'll be forgotten.
I think ideally the AT's should be written together and Dev's start coding, Test have a longer, deeper think and add more AT's and BA's have a longer, deeper think about whether things are heading the right way.
Sound crazy? What's your experience?
I've had limited experience with ATDD but from what I've seen you have to be there from story creation (picking a fight) or at least you have to be very nearby (standing near the fighters and therefore at the front of the crowd) otherwise you'll miss it all (because you're stuck at the back of the crowd).
I've found that everybody is willing to get involved with writing the examples but not always together.
If you're not at the front or involved in the fight directly then you have to fight your way through to get involved.
I've found that sometimes before Dev or Test get near a story the AT's are already written. This might be because of a easy to use DSL or having BA's that can code.
Either way it means that the sharing of knowledge and shared understanding of the requirement that happens when people get together to write the AT's is missed out.
It also means there's no discussion. Why would you discuss what is already there and waiting?
It also means that the AT's are written to one person's perception rather than the team.
Which means there is potential for things to be wrong.
I've also found that sometimes Dev's are so eager to code (like kids to candy) that they write the AT's and are off coding and Testers have no idea what's in the AT's and may have to edit and/or add to them.
So how to you handle that? Is there a way? Unless you're monitoring what everybody is doing I don't think there is, all you can try and do is open up communication and ask to be involved in the AT writing and keep asking otherwise you'll be forgotten.
I think ideally the AT's should be written together and Dev's start coding, Test have a longer, deeper think and add more AT's and BA's have a longer, deeper think about whether things are heading the right way.
Sound crazy? What's your experience?
Subscribe to:
Posts (Atom)