(Conference report, No Hebrew)
So, it is a recurring theme this conference that Neil manages to get a post written on the same day, despite getting terribly late to his hotel room. I think he deserves a round of applause.
this day I managed not being late to the extremely early lean coffee. Going to a such an event three times in a row, after TestRetreat’s open space made me wonder “can I come up with interesting topics?” It has really surprised me that the answer to this is “apparently yes”. My mind was blank up until the point where the event started, and then some ideas surfaced to mind. But, even if this wasn’t the case, the discussion would not have been hindered, as we had an abundance of interesting topics from other people.
Wobbles in continuous integration – It is sometimes nice to hear about problems that other people are experiencing, especially if they seem to be in a more advanced phase than I am – It helps both to avoid the unrealistic despair that comes from “Why can’t I be as perfect as they are”, as it exposes the hard work that was and is done in order to be in that more advanced state. The other reason I like such discussions is that it gives me some insight to problems I have not yet encountered, and will have to consider as I slowly reach towards my desired goal. The problem raised by Katrina was about how to deal with CI breaking due to changes done by multiple teams. Each team’s branch works fine, but it happens sometime that two teams are working on closely related areas of the code, and once both changes are merged into the master branch, some tests fail because the code checked in by team A might fail on a test created by team B. I can’t really say that anyone around had a definite solution for that, but I liked some of the questions asked and I hope we helped by providing an idea or two that can be used.
Testing infrastructure – should we test a change to the infrastructure of the code? After being presented with the question and a bit of context we tried to get of grip around “what is infrastructure in this context”, as this word can mean a whole lot of different things. We ended up with a conclusion that was not new to anyone participating in the discussion – If it matters, test around what matters to you – but I feel that the way we got there did help for the person who asked that question to find the suitable answer for them.
Training new testers – that’s kind of the eternal question, isn’t it? out of the many comments for doing that, I took three that I particularly liked, and want to try and remember:
- Help tester develop the courage to ask stupid questions – this can be done in a multitude of ways, from setting an example to having 1×1 talks with the new testers and assure them it’s OK to ask question even if it seems stupid.
- Remember that every tester is different – some might lack courage, while others should be scolded to deal with their overconfidence.
- Tell them they are in training. Setting the frame in such a way removes much of the unnecessary stress that are involved in learning to function in a new place.
The next talk was dubbed “Lessons Learned in implementing exploratory testing”, which was quite as the title promised – some stories where implementing those cool ideas we hear about in conferences simply fails. Nancy spoke about the importance of having an actual, actionable plan before trying to push for a large scale change, and about not overloading people with too many new ideas (such as the entire RST course for those who are used to work in the “old” way of running test cases.
I also liked her idea of what should a test manager do – which is to create visibility of the testing process and status to the forces that be, so that everybody will know what are the testers doing, and what takes them so long (this one is to fend of the “testing is our bottleneck” where this is not actually the case).
One thing I didn’t like is that in some parts of the talk, Nancy sounded a bit like someone who saw the light – no longer shall we do test cases, but rather use mind-maps, and all those cool RST tricks for testing. It sounded a bit like one can do whatever they want, as long as we throw “those old ways” out of the window. This lead to one of the main concerns in the talk, which to me sounds like a concern that shouldn’t exist – how to make the sort of testing that was now adopted in the test department to remain even if Nancy will leave her position and go elsewhere? The way I see it – as long as they are good testers, and that good testing is done, it really does not matter if people revert to the ways they are more comfortable with.
Next I attended a group discussion about “engaging people back home”, with the question of should we actually make some effort in order to foster professional development in testers (the global feeling was “yes”, as we do see the value in it, but that’s really preaching to the choir), and how to actually make that happen. The main theme was “give people time on the job to learn”, with one case where one of the participants told about having a designated time each week (4 hours, if I recall correctly) where no meetings are scheduled, and the whole time is used for learning. This sounds to me much better than the “we say we give you 10% to learn, but then we overload you with so many pressing tasks that you don’t actually get to use those 10%” that I see in some places, including my own.
After this interesting, yet frustrating, discussion, I moved on to the lightning talks session.
The subjects were quite diverse, and each speaker got a doll of Tina the test Toucan (which means I now have two of those – the first I got when I registered to AST at the European testing conference).
- Can’t we all get along – was a short talk about being less toxic and violent in online discussions – should we actively reprimand those who express in ways we don’t accept? or should we stay out of such muck and don’t feed them with more attention? Should we defend those we see unjustly attacked?
- Check list for test readiness – a list of things that are worth fleshing out before actually starting to test – be it a test plan or simply having all of the requirements in one place. While not everything was 100% applicable to my environment, just going over it did a little to open my eyes.
- Precognition in work – This talk put me at a certain level of discomfort, the speaker shared with us a “trick” to gain credibility and reputation – write down each time you predict something about a problem that might arise when taking some sort of an action (e.g.: “If we’ll start by building the dev environment before building the test environments, our testers will have no environment to work on for at least a month”). Then, when this prediction comes true – make sure to remind people by telling them “I think I found something in my notes about this…”. What really bothered me in this was that there is a very strong incentive to do that only in cases where I was right, and leave aside the times where I was wrong – thus creating a false appearance of “the doom prophet who’s always right”. It seems to be quite effective, but very misleading.
- Three talks about automation
- constructive objection to UI automation – was a reminder that automating UI is quite expensive and we should try not to do too much of it (the message was to avoid it where possible, but that’s too harsh for me).
- Automation is dead (to me) – Richard Bradshaw did a quick talk about his signature subject – automation in testing. What I really liked about the way it was presented, besides demonstrating how a small shift in focus can mean a lot, is that when I see “test automation”, there’s almost an underlying (and incorrect) assumption that test automation is an inferior programming task (I even wrote about it not long ago), the way Richard presented automation in testing made it very clear that in order to achieve this goal, one should posses proper coding skills. It does not exclude writing a quick & dirty script to save time on a repetitive task, but the approach is “let see what tasks we can automate” assumes a much more capable programmer1 than trying to automate test cases which sometimes lead to many “testing tools” that help in automating a very limited set of actions (record & playback are the most obvious case, but even stronger tools such as SoapUI that is quite powerful still do that). When a capable programmer is tasked with “testing”, not only test cases are targets of automation, but also is setup and teardown of environments, monitoring and various tools that aid manual testing.
- Fully automated regression testing in scale – quite a big name for an important topic – we sometime face the expectation to “automate everything” (or, in a more common name “100% automation”), where what should we really do is to identify the needs and risk the automation is addressing. The comparison I really liked was food, water and air – a person can go without food for a few weeks and still live, about three days with no water, and maybe 20 minutes without breathing. Automation should address the most urgent needs,which will not always be the same thing as the task that was specifically requested.
- The advantages of being pushy – I spoke a bit about my experience in not accepting a “no” and nudging things to go my way in order to get some credibility (and I did have this in mind when I chose the title). In short, I found out that one of the things that make the test team important in the team I’m in is that we get involved in just about everything around us – we ask about design and offer suggestions when we feel it is appropriate, we ask to be included in meetings that we were not originally invited (would it surprise anyone that there are fewer of those than they were 4 years ago?) and we seek to contribute to the product in areas that are not strictly about testing.
I think that such behavior, where we get involved in a lot, and share the information we thus get, has a significant part in making the testers in the team visibly involved and relevant. Or, as one developer who has transferred to our team once told me – the testers are really strong in your team.
And suddenly, the conference was over. A very sharp change. I did my best to say goodbye to the people I’ve met during the conference (for those I didn’t catch, I do plan on sending an email, once I deal with that terrible jet-lag that is caused by flying over 10 time-zones) and went back to my hotel to have at least some sleep before my 17-hours flight back home.
So, that was my conference in very small details. I still need to think a bit about the general picture and process some of the takeaways I noted during the conference, but all in all – a very good experience.
1 Following this post I want to make some order in the terms I use – for me, a programmer is anyone who can code. I use “developer” to denote those that chose programming as their career path, and personally I identify as a tester. Since I’m a tester that also writes code, I’m a programmer despite not identifying myself as a developer. ↩