And you know what? he is right, and I'm going to tell you a story.
When I started in peerTransfer, the team was doing scrum and I was the first tester they ever had. The stories where written in Pivotal and devs used to push to staging once every week. As every dev was developing in local, it made sense to put me to test in staging environment, along the product team, but this had some drawbacks.
- If a feature was finished on day one, it had to wait all the week to be released to staging, and since having developed features waiting for being tested is a form of waste, this was no good.
- For my point of view, I was always one week late, because I had to wait, when bugs started to arise, the devs had to go back to the code and try to patch whatever came out before it went to production.
- As I had one week to test, I needed to prioritize my testing, the more risky the feature, the sooner I had to start, and guess what, sometimes bugs came out because the features that had less priority had less time to be tested.
- If the pass to staging got delayed one day, for whatever reason, I had one day less for testing, because product team wanted to have the features rolled out to production on time.
- If one of the features went really bad, the whole release could be impacted because of this delay, adding pressure to the team.
We could do better.
So the devs implemented a board available on our site, because the one with post-its was not suitable, being half of the team in Boston and the other half in Valencia. Then we moved the Pivotal stories that where ready to develop... and we deleted the rest of them as the future is yet to define!
Now, every story gets developed in a branch. this branch is deployed to a clone environment so I can test the feature. Then we merge and then we deploy.
I get stuff to test right out of the oven, and if I need some help, the devs are ready to pair test the features, because they still remember what they just done, and they still have not started with anything else.
We deploy several times every day, so if one feature needs more time, because of bad requirements or bugs being found, we still can roll out the small features or patches and keep testing the features that are giving us trouble.
We develop out own tool for the kanban board so we don't have to pay license for it, and we are able to develop whatever product or business people needs to keep working, we are a software developing team, and that is what we do!
As a tester, I must have some principles, some rules to follow. The ones that I know that make sense for me, are James Bach's Testers Commitments . And since we do kanban, we all do better, even I do.
and still, we all know we can do better :)
 |
| Hacknight at peerTransfer |
