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.