Testing? Thoughts? Idea? What?

Yesterday I tried a experiment I'd been toying with in my head.

I've been with a organisation for roughly 8mths now and I've not actually had a lot of time to spend with the Testers as we've all been busy and I wanted to know more about how they think and what they think about what they do.

My role has changed slightly now and I have more time to work with the Testers and so yesterday was the first of the 'sessions' I'll be running.

I had 3 Testers on the exercise and essentially just asked them to write down thoughts on testing.

We then discussed what they had written down and wrote it on a whiteboard.

I then added to it with my thoughts which we also discussed.

There were notes being taken and thoughtful nods and comments.

Mine are in red.

Francesco, a colleague who wasn't on the exercise later pointed out that we'd not written anything about 'who'.

What else did we miss?

I think the session was a success as it seemed to get the guys thinking and I learnt about their thinking.

I would like to punch it up a bit, not sure what I could add to jazz it up a little.

Have you run anything similar? Or taken part in something similar? How did you get on?

It might have worked a little better if thoughts had been written the night before and then we got together to discuss as I'm thinking of new stuff to add all the time.

Agile Practitioners meetup - 'In Theory and in Practice'

Last night I attended an Agile Practitioners meetup where Daryn* gave a talked titled 'InTheory and in Practice'.

Here are my notes from last night and the Italics are my thoughts

He took us through a recent project (for a client) to build a Excel plug-in which connected to a third party.

Didn't really go into complexity, wonder if the same approach would work with a larger team.

TDD and BDD were used

BDD details weren't really discussed but it sounded more like acceptance tests were written rather then 'full' BDD.

There were 2 Developers and Daryn acted as a sort of co-ordinator.

The Deverlopers were able to practice pair programming and found having to voice and explain/justify your ideas a little odd at first but found great benefit by doing it.

Teaching/learning and writing better code

Code reviews were carried out by Developers on other projects.

Daryn also talked briefly abou the NUMMI case study, I'm not goint to write anything about that as there is loads of stuff around.

It's a good case study and I've not researched it enough but I wonder about the variables such as if the improvements were partly due to there being nowhere else for people to work and does that matter (in terms of the fact there were huge improvements)

On the project the first thing they talked about was testing, or how much/what could be automated.

They used Specflow for automation and I think Coded UI may have been mentioned as well.

            Were other options explored?

They were given uses stories which contained impementation details and luckily they were trusted enough to re-write the stories and change them to just the what rather than the what and how.  This meant they could look at different ways of implementation and were able to simplify the solutions.

            Were they written with the people who write the original stories?

They were able to decided at the last responsible minute and Daryn shared some pointers:

* Share partially completed designs
* Colloborate
* Develop a sense of how to absorb change

            What did they do to develop that sense? Or how was it handled?

All the stories were based on business value only and nothing had been written for the implentation, frameworks, etc. Essentially all the kind of stuff that becomes tech debt.

This also meant that this work wasn't visible.

            It was mentioned that this wasn't a issue, be interesting to know why this wasn't a issue.

A couple of burn down charts were shown and generally speaking they were pretty smooth and showed improvement.

Excel was used as the overall management and data collection tool

Of high importance was the people side of things, building a good relationship with the PO and the third party.

Daryn shared some general project pointers:

* Don't do too much upfront
* Too large a context change/switch can cause performance hits, ie, work on 1 project, don't work on multiple projects.

Data, information and quotes were resourced from Jerry Weinberg, Lean SoftwareDevelopment*, The New New Product Development Game and various conferences.

*Didn't get Daryn's surname. 

*Not sure which actual book it was.

Two talks, two weeks in two timezones.

Recently I was lucky enough to be part of talks at STPCon and at The Next Generation Testing conference. STPCon was in Addison, Texas and NGT is in London, England.

The first talk was with Adrian Rapan and was a mix of our different experiences on projects, in different environments and how we dealt with them and in some cases how we would now deal with them with a bit more experience under our belt.
It seemed well received and generated a lot of questions and I believe we were able to offer some suggestions to people who were in attendance on how to deal with some situations.  I'm also pretty sure some people were expecting something different so while the majority seemed to walk away with something useful, others didn't, can't please everybody.
It was a hour and 15mins look which seemed to fly by and I liked that we could have a high level of audience participation, it was fun to be able to discuss issues and draw questions and suggestions from people.

It was also great to be able to meet a lot of people.  Pete wrote some pretty good blog posts about STPCon and the people there so I'm not going to bother, also, I'm very lazy.

The second talk was about the project I am currently on and we talked about moving from Waterfall to agile and being 6 months into it.  It was a team presentation and as such I presented with some of my colleagues; Richard Wadsworth and Andy Jutton.  As becoming agile is very much about teamwork, communication and collaboration with all areas of development I thought it a good idea to include people who didn't specialise in testing. Richard is Release Manager and Andy is the Architect.

We discussed all aspects such as physical location of desk/team mates and moving everyone closer, attempting BDD and CI to name a few.  We also talked about what worked for us and why as well as what didn't and why.
It was very much a discussion on the past and how things were, the present and how things are now and the future, what we wanted to continue improving on and what we wanted to try.
A lot of questions were asked and there was a lot of discussion after so it also seemed very well received.

I had a great time presenting both talks with some very talented and professional people who for some reason seem happy to spend time with me.

I do however probably need to plan a little bit better as I arrived back from Dallas on a Monday, went to work on Tuesday and presented at Next Generation Testing on Wednesday.  This is not something I'm used to so it was a odd couple of days and I would totally do it again.

Thanks to STPCon for accepting us and Next Generation Testing for inviting me to talk and allowing us to attempt a 3 person presentation.