Thursday, October 31, 2013

Slow progress and patience - getting devs to test more

Torn between my two completely different teams, this is a story from the one that makes me impatient. When I joined - already 1,5 years ago - I negotiated on "test-fix-finalize" week where the whole team would do 'testing' - except we would not do testing, we would do code changes to make automated tests possible. We would fix bugs that we really would not want to document in our tests,. And we would add automated tests, unit-level first.

The allocation to "test-fix-finalize" has stayed, leaving a small window of exploring how the system works before it goes live. And we do need that window since we have not managed to get very good at small incremental changes or test automation on any level. Or, some might still argue that 2-3 weeks of developer work is small.

Quite recently we have moved into introducing Selenium tests. After the first examples and the discussion about "can't we just outsource this to some testers somewhere", the team has been adding those. There's been workshops, first one day and this month two days, where the whole team sits together and codes tests together. We don't do this for anything else except tests, so I'm kind of happy to contribute to that.

When adding tests, we've also been changing the product. And that again, to me, in some small scale, is a plus on the list of why I wanted the work to stay inhouse, with this team, to not get yet another round of tests that no one maintains, runs or feels any ownership of. Yes, we did that once or twice, before I joined.

Having people sit together has also other positive impacts. Like this week, while they were doing the tests and I was spending time on my other project, they started talking about how they want to do things. I get an email telling about their "decisions", where the most relevant to me was this: they decided to plan their effort so that it includes testing - well, their idea of testing - and do trade with other developers on tasks to get fresh pair of eyes on their own code. Kind of nice step, I just wish still the system testers would be part of that cycle too. But this did not exist before so its definitely progress. 

I was thinking about what actually brought this change: visibility and sharing the pain. A month ago we moved the system testing backlog into the same Jira-project where all developer work is tracked, because the time was right. And since then, the team had to see how the single tester was getting piled with three times the work that could be completed. And being the nice people they are, they are actively thinking how to help.

I wish it would help immediately, but I guess I need to work on my patience. Step at a time, never give up. If things don't feel right, there's a way to change them. Sometimes finding the way is just taking quite some time...


Monday, October 28, 2013

Reading specifications with thought

There's a rock I've hit hard too many times recently and the pain I feel is clearly telling me there's a need of changing. As part of me processing this, I thought I'd blog. After all, it's been too long.

Starting with an example, simplest out of the selection. We've been adding a feature to our product, which is about printouts. I've seen the spec, read it as thoughtfully as I did in that time, and waited a little to get the feature implemented to do some testing.

It turns out that the feature was nice in isolation of other surrounding similar features. It turns out it was nice on picture and text, but when put together with live scenarios, there's more than first meets the eye.

So I log a bug on that. We eagerly discuss it with the team and decide on a change to what we had thought previously. Implement and again comes testing...

It turns out that we missed yet another scenario. While the first issue was that printouts of two sorts worked differently on main view, the second one is that there's more than the main view and again inconsistencies that would lead us to a different design.

I'm frustrated, as I did not see these coming looking at the spec. Then again, anyone else did not either. But failing twice in a row, with very similar pattern, is just painful. And we keep failing with a similar pattern.

So thinking about what to change, I realize I'm puzzled. I could take more time to test the specifications, since I seem to have some touch to seeing the problems with the live product. Then again, someone else could do that too.

Positive side: no one in the team is initiation discussion whether these are bugs / should be fixed. Just frustrated with the inability to remove the root cause that keeps us stomping on similar issues again and again.

For anyone handling tester's issue reports - there's usually more than the one described symptom. Removing a symptom without addressing the underlying problem isn't taking us where we'd want to be.

Off to reading the next specification, with scenarios I just defined to support my thinking. Perhaps these will help the others see problems too, time will tell. Reading with thought is quite different from just reading. So many things between the lines that make us waste everyone's effort.