
Yesterday, after the last keynote I went to look at the car building party, which looked awesome and chaotic at the same time. People were really into it, and looked sweaty and excited. I went to the bar with a colleague of mine to have a nice talk over a glass of Talisker.And that was the only alcoholic drink I had that evening. One hangover a conference is enough, thank you very much.
OH, and I had my copy of “More Agile Testing” signed by Janet & Lisa, woohooo đ
Then I went to bed at the most reasonable time ever, but I have my own consensus talk today. I wanted to feel rested for that… Nerves will kill me later today.Â
Keynote Antony Marcano – Donât Put me in a Box
I havenât read anything about this talk up front and the title makes me really curious!Â
He goes around in a public asking them âWhat do you doâ, and people will answer with âI am aâŚ[x]â. And youâve already put yourself in a box. It limits the agility in our teams. When you say I am an agile tester you probably say that because you are proud of your identity.Â
#noslides. Makes it harder for me sometimes to do the liveblogging. Oh well.Â
Your salary is partly based on how awesome your job title is. âGrand wizard jedi software guruâ. That would cash pretty well.Â
If you tell others you are a tester, theyâll expect you to do the testing. But what if you do stuff that doesnât relate exactly to your job title? Antony prefers not to have a title. He wants to be part of a group that shares a single responsibility. âI kind of do stuff in software-likeâ. People want a short answer, that fits in a box. People like to make assumptions and want clarity. When in reality, people do (are?) many things.
In the past your role would be clearer. Antony gives the example about parenting in the fifties. Fathers would work and mothers would take care of the children and the house. Roles have become much more dynamic since then.Â
Antonyâs first XP experience was when he built a computer programme with his dad that helped his dad do a part of his work much faster. But then he went to uni and they told him that Waterfall was the way to go.Â
Then he experienced Rapid Application Development (I have never heard of that, Iâm only 28 excusez-moi). He wanted to become a system analyst. But first he had to be a Junior Analyst, aka a Servant. He does whatever the manager doesnât want to do. When he went to look in the code, the manager didnât approve because that wasnât his job title! He wasnât allowed to touch code! (I really think itâs insane that things like this happen in the world and Iâm glad to have skipped that phase). The manager wasnât even happy that he finished his job in a couple of days (cleaning data), because he automated it.
He then went to work as a tester on an XP project in a law firm. But still, he wasnât close to the developers. And of course, IT was stationed in the BASEMENT (Hello, Office Space?). He found bugs, but it would take a lot of time before anyone could pair up with him because the developers were somewhere else. And they went to the pub without him because of that. He decided to move his desk: awesome! It helped tremendously on everything: communication, pairing, codingâŚHe became more of a test lead, and also developer. His team moved past the whole âyour job is xâ and everyone did more parts in the process.Â
He just wants to do awesome stuff. He can do more than one thing, so whatâs the big deal. Screw those boxes (job titles), people have more than 1 skill. He dislikes the idea of âputting people into projectsâ. Well, I AGREE. And talking about people as ârecoursesâ, HORRIBLE. People arenât dispensable. Â
The mindset shift, paradigm shift, is really important. I find it very nice to hear his (his)tory. I missed this history because I am still young, and Iâm glad I missed it. Iâm glad that I have a manager who trusts me and not tells me how to do my job.Â
I love the energy from this talk, really good. He seems so relaxed when speaking, awesome!
A Test Management Christmas Carol, The Ghosts of test management, past, present and future – Ben Williams & Tom Roden
I have talked with these guys at the bar and during the diner on day 1 and theyâre really nice. I think their presentation ought to be fun!Â
We all got cards, which are obviously shameless publicity, but we also need them for voting later on, apparently. *wink*
They start of with a video of the test management past. Omg this is too hilarious to write down. Words fail me here.
âTests at least a 100 steps long, you know, quality tests!â. That sums it up pretty well.Â
Test Management Past in a nutshell: Utterly Immovable Live Date
We were trying frantically to estimate our testing efforts, given that they had to be performed in a time box (if you were lucky). And even when you said â80 daysâ to the project manager he would put 20 in the project plan.Â
Smoke testing = smoking a cigarette
Exploatory testing = going out in a boat
Stress Testing = FUUUUUU
Penetration Testing = yeah, lets not go there.
Stay on the target, was very important!!
Step 1> Remove Brain. Step 2> Login to QC Step3> follow 67 steps test script Step4>test fail because test step wasnât doable Step5>Is it a bug, because it didnât follow the script.Â
Funny stuff, partly true, but lets get serious!
Agile is still on the increase, more people are trying to start working that way. But still a lot of fallacies about agile testing exist. In none of the agile frameworks a âtest managerâ exists. So what does this mean?Â
Where are all the test managers going, they arenât vanishing into thin air right? The roles have changed! They did a survey at a population of IT-people and 90% said that responsibilities have changed. Decrease in: Planning, Reporting, Test Strategies, Project Admin, Project Management, Reviewing Documentation.
No Change in: budgeting, training, reviewing tests, metrics.Â
(again, I see a parallel to my own talk, where I will breach upon the subject of test strategies).
How can test management change into the future?
– role will stop to exist
– managers need a different role, broader scope and different skill set
– teams need to be accountable for their test activities (more so than in the past)
Now weâre going to play a game: Inside or Outside the team!
Defect Management: everybody said âinside the teamâ. Although I hate the term âdefect managementâ. In scrum, there is no such thing as âdefectâ, you either have a âuser storyâ or you fix the defect immediately. If you need defect management, you are either doing things wrong or you are working with many teams on the same product (thatâs harder).
Test Automation: almost everybody said âinside the teamâ. Also a bit harder when youâre working with more teams, sometimes I see a team specifically focussed on automation in large projects. Tom and Ben show us a version of the agile testing quadrants and their practices when it comes to test automation. Seems familiar to me, and I agree wholeheartedly with their approach.Â
Test Tool Selection: 50% said inside here. I waved my card to both sides, because again, if youâre working on a large project itâs not really feasible for every team to decide which tools they want to use. You need a general agreement on that. If youâre working in a small project, you might be lucky enough to wield complete power over your tool selection.Â
Principles & Strategy: most people said âoutside the teamâ. That surprises me, because I think agile is all about giving TRUST to the team. So trusting them to be able to figure out HOW they want to test. I personally want that responsibility to be in my team.Â
Tom gives us the âPrinciples of Testingâ, which seems like a sort of framework for an agile test strategy. It looks really good!
Teams are responsible for more! Is that a good or a bad thing? Itâs a good thing if people have the right motivation, not if they hate their job. Iâm thinking about the book âDriveâ here.Â
Chris George – Easing the Pain of Legacy Tests
Talked to Chris earlier on the day, he seems a nice bloke, and legacy tests ARE a pain in the a**. So Iâm curious to know more.Â
âOnce upon a timeâ (thereâs the unicorn again), a project had 250k lines of code, more than 10k regression checks and CI in place.
Now, the REAL story. The automated test were SLOW, 16 hours runtime! (OMG). They never all passed, they had random failures. This created a lack of confidence, so it would take longer to release.Â
In his project, the testers were mostly responsible for the test code. It ended up being a little bit like a house of cards, it would fall apart easily. Instability was the reality.Â
They came up with a plan to shorten the release cycle. The original planned time was 6 months. A guy with 30 years of experience thought it would be easier âitâs only code at the end of the dayâ. But Chris thought it would be better to not dive into the code. They started to analyse the failing automated tests (checks) to see if there was a pattern. It ended up being 3 categories of failures: infrastructure (issues with the databases, network), resources the tests required werenât there, potential product failures.
He first went for the quick wins: 50% was easily solvable in the end. He was able to fix the resource problem first. 50% improvement already in 2 days!
The next challenge was infrastructure. The tests talked to a lot of databases and there seemed to be a critical number. Whenever more than 70 databases were involved the performance dropped.Â
Also, if there were more than a thousand objects in the database a comparison test took more than 2 hours! Crazy shit. It took 1 week to improve this challenge, but 95% of the tests now passed! Great work, although the sceptic person in me asks âdid you look at the value of the tests first?â.Â
Now the developers could go back to coding, run the tests after they were finished and have quicker feedback. The release cycle would shorten (? no answer on that).
(was the goal to make the tests pass or to make sure you have valuable tests?)Â
The developers started to care about the tests. They became leading in development. But 6 hours runtime is still a lot. The next goal was: get it to run in 1 hour.
Geez, this guy has BEAUTIFUL slides. Awesome drawings!
Now, they started looking at the actual value of the tests. Do you need to test everything all the time?? No, maybe not. They unshackled the tests from the database by mocking the database stuff they needed.Â
Next step was to visualise the test progress reports for anyone to see. Chris was very proud of this achievement.Â
â And then nerves hit me. I was up for a consensus talk at 2:30 and Iâve never presented at an event as great as this. So I had some lunch (couldnât eat much), and then skipped the keynote to practice a little bit in my room and make some last tweaks based on the new info I had since this morning (Donât put me in a box, test manager stuff).Â
15 minutes before me talk I felt like I was dying. Then I actually delivered my talk, and David Evans, Ben, Tom, Eric and many more people were in the audience supporting me. I really so much appreciated it!! I think my talk went âokayâ, could be better, but for a first time I was very happy to have survived it with a little confidence. I hope that next year I can make it as a âreal speakerâ at the conference. Â —Â
Keynote Alan Richardson – Helping Testers Add Value to Agile ProjectsÂ
Ok, heâs beautifully dressed, letâs be honest. He looks like a pirate, which is awesome.Â
Also, his voice is so relaxing!
On to the topic: When we donât impact reality the way we want, we feel disillusionedâŚSo what can we do? Work with the reality, rather than an ideal!
Testers adopt different belief systems, so we notice different things each time when working with a system.Â
A tester makes other people look good! Lol đ
But donât think that bringing donuts to your team is adding real value. We add value by doing stuff related to testing. We find problems, check acceptance criteria and so forth. We get comfortable working with the system under development.Â
He survived Waterfall projects, omg!! He tried to remove waste, explore, not make huge test scripts etc. Waterfall teaches us how to work around the process. (SO true!)
âIf I can handle Waterfall, I can handle any of this stuffâ.Â
Ugh, I notice that Iâm waaaaaay to tired to give you a summary of this talk that actually does it justice. Iâm going to just pay attention and enjoy it for now.Â