Category Archives: Random musings

750 Tweets

So this was fun. While spending a rather hungover Sunday afternoon following Silicon Christmas, immobile on the couch and learning about Angular.js, I happened to tweet the following:

I received this reply:

I spent almost 750 words forming a semi-coherent answer, until I gave up and James gave me the answer:

To which I of course responded:

A short time later, James sent me a prezi which looked like this:

750words

Inside the “O” was written:

A tweet has 140 characters which divided by 6 for average word length plus space gives about 23 words per tweet. But that will lead to hard to read text. So if we say an average of 18 words per tweet you can comfortably reach your goal in 42 tweets.

I was a little slow.

Of course I did. An hour and a half later, I got this:

Man-clapping

One simple suggestion to encourage more women into IT

Last week I wrote a blog post about a conversation I had with a young girl about women who work in technology. I did not anticipate such a massive response! #1 on Hacker News and almost 40,000 page visits in 24 hours. I’m encouraged to know that so many people are thinking about this topic.

In case a few people are still listening, I have one suggestion to make. Now, I know that this is a complex issue and there isn’t an easy solution. So instead of offering a solution, I would like to offer a small, positive step.

So here it is.

If you are a person – of any gender! – who works closely with technology, make friends with a woman who does not know much about technology.

If you are a woman who does not know much about technology, make friends with a person who works closely with technology.

My hope is that this will encourage more women to talk about technology. Then perhaps their daughters and your daughters will see this interaction and it will become ordinary for them. Then maybe one day it will become ordinary for women to talk about technology. And one day maybe it will become ordinary for women to work in technology too.

And hey, even if it doesn’t end up solving the big issue, at least you’ve made a new friend! I’m sure many of you will say that you already have friends like these, which is wonderful. I do too. I could use a few more.

I knew exactly how she felt

I went to a Women in IT event last night at Google Campus London designed to connect professional women in the IT industry to high school girls. Most of the girls I talked to were either interested in a different field, or were toying with the idea of computing as a backup plan. Then at the end of the evening, one girl pushed through the crowd to talk to me.

“Hi! You said you were an engineer?” she asked. I said yeah, a Test Engineer at Google. “That’s so cool! Have you ever seen Star Wars?” I looked really shocked and said of course I had. “Oh! I didn’t mean to offend you!” she said. I said I wasn’t offended, it’s just that nobody had ever asked me that before.

“I’m so glad to meet an engineer,” she enthused, “all the other women I talked to here were in marketing or law or something. I thought it was meant to be about IT.” I said that’s what happens when we hold events for women in IT when there aren’t that many women in this industry – we tend to broaden the definition of women in IT.

She then talked to me about robotics and physics and programming and how none of the other girls in her class understood anything she was talking about. They thought she wanted to build the next Terminator or hack into Government systems, when she just wanted to build self-driving cars.

All the other girls would talk about fashion labels and gossip and she would be bored out of her mind, wondering why nobody else watched Doctor Who. None of them understood the joke on her Darth Vader t-shirt. One of them listened to her podcast and asked her what “Marvel” was. One of them told her to stop making them feel stupid all the time.

She said that she really feels at home with other geeks, so she ends up hanging out with other geeks and they’re all boys at her school. I told her I knew exactly how she felt. I introduced her to a friend of mine who’s a software engineer and we told her that if she went into IT that it would be full of our people and that it’s great. She was really happy about that.

It’s funny because the evening started out with a lady giving a speech about how the IT industry is alienating women. But for some girls, it feels like women are alienating the girls who want to be in IT.

Testing Positive

I gave a talk at the Sydney Testers Meetup last year called something very New-Age-sounding like “The Power of Positive Testing”. It was a short talk with a positive message so I thought I’d spruce it up a bit and present it to the London Tester Gathering now that I live on this side of the pond. The old slides looked a bit boring though, so I decided to make them look a bit more interesting.

Then I had a mad idea. Hey, how about I code my presentation!

So I dug up an old Smashing Magazine free HTML5 parallax effect template and several hours and one small coding tantrum later, I had this little beauty. Pretty cool, right?

Those of you who are viewing it on anything other than a standard 13″ Macbook Air resolution can already see the hilarious flaw in my plan.

Yes, of course I tested it and I knew it would have issues in different screen resolutions. But like a true laidback Aussie stereotype, I thought she’ll be right, MVP mate, I just need to get it working on my laptop and mirror the screen on the projector. At least, that’s what I’d do if any of the screen output adaptors I had worked with the projector. In the end it wasn’t such a disaster though, as I’d already uploaded it to this web server and could access it from someone else’s laptop which had a working converter (thanks Deri!). It just looked a bit wonky in the different screen resolution and didn’t scroll so smoothly on Deri’s Compaq.

Anyway, valuable lessons learned about giving presentations:
- Adaptors are cheap, just buy tons of them and bring them all. Why not.
- If you’re giving a presentation about software testing or development and you’ve coded your presentation, make sure it works properly.
- Actually just don’t code your presentation, it’s probably not worth it. With the time you save, you could be rehearsing! Or learning a second language. Or watching TV. Or doing just about anything else that’s better than coding your presentation.
- Stock photos be damned – all that Instagramming has finally paid off!
- Have a backup plan. Make this backup plan involve a USB thumb drive. Do not make this backup plan involve the internet. Especially do not make this backup plan involve Github.

Who am I kidding – I had fun with this, and I got to tell a funny story too. Plus I learned a little bit more about HTML5 and CSS in the process. Overall the presentation was well-received, and that’s the important part.

If you’re interested in what the talk was actually about, Dan Ashby has written a great blog post about it.

For my next act, I’ll be speaking at the Selenium Conference in Boston in June. With sensible slides. Probably. :)

A lesson in exploratory testing

Okay, I think I finally get it. I’ve been looking at exploratory testing all wrong.

I was trying to break down exploratory testing into a set of learnable techniques that can be followed by anyone to get them to be better testers. But exploratory testing isn’t like that. I was getting really frustrated because there were significant elements to it which were hard to define. But that’s because exploratory testing isn’t a series of set definable techniques.

It’s like learning the guitar. You can learn the chords if you want, but that’s not how you become a good guitarist. At some point you have to start figuring out how to make the guitar work for you, how to get it to do what you want. And learning the chords is not the only way to learn the guitar. If somebody gave you a guitar and you had no idea what it was, given enough time you could still learn how to make it play beautiful music. And if someone asked you how you did that, and asked you to teach them, maybe you would struggle to find an effective way. They could mimic exactly what you do, but it wouldn’t help them understand how to create music for themselves.

I used to learn piano. I’d show up to the lessons and practice the same songs over and over again, but I never enjoyed playing the piano, or even making music in general, until I started experimenting with my own methods of learning. In order to become better at something, you do need practice, and practice helps, but you also need to take an active part in the learning process. Practice will only take you so far.

Testing is the same. Like James Bach says, testing is a craft. It’s not something that you can teach as a series of steps. It’s something that you need to practice, and then take an active participation in your own learning and growth towards becoming better at it. That’s why it’s hard to measure if someone is a good tester. To go back to the piano analogy, I did AMEB (Australian Music Examination Board) exams for piano and I achieved grade 5. I put absolutely no emotion into my piano playing, I just followed the notes and directions on the sheet music. I learned a few scales. My knowledge and technique was probably grade 5 standard. But I was not a great pianist. Music is not a mindless, step-following activity. Nor is programming. Nor is testing.

I think what I wanted was an effective way of teaching testers how to be better testers. But showing them techniques will only take them so far. They need that interest and drive to learn more, otherwise they’re just doing what I did when I was learning the piano – following a series of steps. They’ll never become great testers, or great at anything, if they don’t take an active interest in their learning experience. I can’t wrap a process around a people problem.

Ultimately, in order to teach something, it’s more valuable to inspire a desire for learning than to transfer knowledge.

To that end, it’s important to acknowledge exploratory testing as a skill that requires practice. Some people say they are naturally “bug magnets”, but natural talent without dedication to self-improvement will only get you so far.

The test of cool

I remember three things that made me think testing was cool before I was a tester.

The first one was when I was a high school student and I was reading an article online that a tester for LucasArts games wrote. It was a funny “day in the life” piece, and described how he got to play the game before it was finished and found bugs that would make Guybrush Threepwood’s head fly across the screen. He described the glee he felt in waiting for the optimum time to tell the developer about the one flashing white pixel in the bottom of every frame, and watching that developer burst into tears. He sounded like a man who loved his job.

The second one was when I was a university student and I was studying human-computer interaction as a subject. The textbook had a piece describing how Microsoft conducted usability testing. They had usability labs, and brought in real users and observed them while they used the software. It sounded like an interesting way to gain insight into how people used software, and a way to help make software easier to use.

The third one was when I was fresh out of university and working for Microsoft as a developer. My boss Gary had been working there for about thirteen years and he loved to tell us stories about Microsoft. One story he told us was about a group of testers in Microsoft who would walk around in packs wearing black trench coats, striking fear and awe into the hearts of developers as they passed by. They’d walk up to a workstation, click a few buttons, crash the system and coolly walk on their way, while developers scrambled to fix the error. They sounded like badasses.

Conversely, I remember the first time I met a software developer. I was in my first year of university and had told my uncle that I was studying IT and wanted to be a programmer. My uncle was a manager in a bank. He was shocked. “What? You want to be a programmer? Aiyoh. Come with me, I’ll show you a programmer.” So he took me to the bank and showed me his huge, beautiful office. It had a separate lounge area and an ensuite bathroom. Then he took me down a corridor to a black unmarked door, punched in a combination into a keypad and there, in the middle of a windowless room, sitting in a pod of cubicles, sat four men who looked like they’d lost the will to live. “Look at these guys” said my uncle, gesturing to a despondent-looking programmer. “Look at their faces. Is this the kind of job you want?”

When someone meets you for the first time, having never met a software tester before, what will they think of software testing when they walk away?

Quality is alive

I’ve talked to a lot of unhappy testers – smart, talented testers who always feel like they are working at odds with their teams in order to advocate quality. In this kind of situation, it’s easy to believe that quality is dead. In my last post, I speculated that perhaps it just isn’t cost-effective anymore for companies to have a primary quality focus. In which case, as an advocate for quality, how could a tester ever have real job satisfaction?

Software isn’t just a “see who can make the most money” game. There are people out there who believe in making good products.

The quality of the product is limited by the quality goal of the company. Testers, developers, designers – we all help the company achieve that goal. If the goal doesn’t align with our own personal ideas of quality, then we will not have much job satisfaction.

Whether you like software to look beautiful, or produce huge profits, or be driven by beautiful code, or make your customers love you, you want to build something that makes you proud.

Jerry Weinberg famously said that quality is value to someone at some time. What is quality to you, at this time? Are you working at a place that has the same quality definition as you? If not, then you have two choices – adjust your personal definition of quality to match the company’s, or find a company that has the same values as you do.

Every successful company is making quality software, by some person’s definition of quality. If we want to have real satisfaction in what we help create, we need to find or create a company with quality values that align with our own, and then work out how we can best serve to help achieve that goal.

The death of quality

“Quality is dead,” declared Goranka Bjedov. And I thought to myself, I knew it.

For some time now I’ve been concerned about this. I’d always seen specialised testing as a way to turn a mediocre-quality product into a high-quality product. But the evidence before my own eyes is that the market is full of buggy software. The worst part is, people accept buggy software as the norm and learn to live with it.

We say that nobody can ever be “done” testing, because there is always more than can be tested. There comes a point in any project where the cost of continuing to test outweighs the benefit in releasing earlier, but with unknown bugs.

“The truth is, bad software makes more money” – Goranka Bjedov, STANZ 2011.

I recently watched a project going through a fairly difficult stabilization phase. Too much change towards the end of the development cycle and not enough testing at the start meant that most of the bugs were being found at the end, so the team was looking at a few more weeks of catch up time to find and fix all of the bugs. But, for reasons that I still don’t completely understand, all of the bugs were postponed and it was released anyway. The next two weeks were a mad scramble to fix production bugs, followed by several weeks of less frantic fixing. I was ready to label the project a colossal failure. But the product was actually very well-received by most customers. By the end of the first week, customers were singing praises for the new feature and the project was hailed as a success.

It left me wondering what the point was of having testers on that project at all. I was told that, without testers, it would have been a whole lot worse. Is that rewarding though? Working to make something “not as bad as it could be”?

After STANZ, I stayed with my friend Richard for a few days. Richard is a medical doctor, training in radiation oncology. I asked him if it was depressing being in a job treating cancer, which is a condition that’s difficult to treat and not completely curable.

“Oh not at all” he said. “There are some practical things you can do, to improve quality of life”.
“But,” I pressed, “when people think cancer, they usually think that’s it for them. It seems like you’re just fighting an uphill battle.”
“Everyone dies eventually, of something,” he explained. “But I know that there’s things I can do that means they’re not going to die today. And the quality of life they have in the meantime can be made a lot better.”
I nodded. “I guess that’s true.”
“Once you accept mortality, medicine’s not that hard. It’s actually quite rewarding.”

Perhaps we need a mentality shift, and a different way of seeing our role. If we see ourselves as the cure for bad software, then we’re going to be repeatedly disappointed.

I emailed my friend James Martin for his perspective, and he offered this one:

How about working to make something ‘better’. What if all any of us did, regardless of job title, was try as hard as we could to make the best stuff possible, accepting the fact that even the best of us has only a fragile grasp of what it takes to make something that another person will be delighted by.

Personally, it helps me to think that my whole job description is ‘to make things better’. That way I can solve problems using whatever tools feel right for the task at hand and I don’t feel constrained by someone else’s opinion of who I should be and what I should do.

As usual, the people setting the ‘standards’ for our ‘profession’ do so without knowing our context. But we can set our own standards for ourselves and play by our own rules. I like to think that you and I did that last year. I still think of what we did at Campaign Monitor as my best work.

If quality is dead, what are we doing here?
If we are adding value, what is it and how do we measure it?

XML conundrum

(A conversation snippet from the hogfish.net archives, circa 2007)

Trish says:
aw man

Trish says:
/me tries to remember what the file made yesterday was called

Trish says:
/me sifts through files called things like jam.xml, ponymeat.xml, pork.xml, raisins.xml, great.xml, jelly.xml

Trish says:
oh scone.xml

Trish says:
it’s all so obvious now

Dewi says:
/me laughs

Dewi says:
I hope you’ve got test cases to ensure they are always well-formed and conformant to their schemas!

Thoughts on using mind maps

I’ve heard that people can identify with either visual, auditory or tactile methods of learning, or some combination of the three. This is called Fleming’s VARK model of learning. The concept is pretty simple. Visual learners learn best with visual aids, like diagrams, pictures and books. Auditory learnings learn best when they’re listening to things like lectures and discussions. Tactile learners learn best when they’re doing things, like experiments and demonstrations. Most people will probably use a combination, but show a preference for one method more than the others.

I know from experience that I’m a very visual learner, so I love drawing diagrams and writing very structured documents to visualise information. Tactile learning works well for me too, but I usually struggle with audio information. So mind maps are a really useful tool for me. I can create mind maps very rapidly because each node already has the context of the previous node.

When I’m using mind maps for requirements analysis, I’ll make initial nodes for each main component, then break each component down into smaller feature nodes. I’ll add nodes for any questions or test cases that I think of along the way. I used to make the questions and test cases a different colour, but I found that it was a waste of time because I’m really just capturing raw data, which forms the basis of my questions and test cases. Once I’ve written test cases, I don’t really look at the map again.

I think this is because mapping isn’t so much an information capturing exercise as it is a learning exercise. Visualising requirements helps me to form a more complete mental model of the system under test, which helps me to work out scenarios based on this understanding.

I tried to use mind maps for mapping out functional areas of a system, but it didn’t work because mind maps only allow a tree hierarchy so they can’t show an adequate level of interconnectedness between functional areas.

I think that at their best, mind maps will be a visual representation of the author’s own thought process. For this reason, they may not be useful to anyone other than the author (especially non-visual learners). This has been my experience, but perhaps others are finding it useful in collaboration if they are using them in a different way.