Imagine that it is long ago in a galaxy far, far away, on a doomed planet. You are a vulcan tester. Unfortunately you have been tragically rendered a paraplegic. Your rehabilitation as a paraplegic vulcan tester in a galaxy far, far away involves a virtual self in an automated testing environment. This talk addresses evidence found in the “ark of truth” gleaned by paraplegic vulcan testers being rehabilitated by living through a virtual self in an automated test environment everywhere (come on, we all know how frakking ubiquitous this situation is.)
Truth #1;
Selenium IDE is like the People magazine of automated testing. Everyone uses it, but nobody wants to admit it. Not even Adam Goucher.
Truth #2:
Using a percentage in your prsentation slide is 602% effective as long it is large, flashing and contains absolutely no hard numbers to back up the claim you are making.
Truth #3:
Idea is so beloved that anybody who uses a text editor as lowly as Textmate, especially in their presentation will be shunned. Let’s all have a group hug on this while Idea takes it’s sweet mother-frakking time to load. Again. Ok, now let’s all go get a coffee and give the bitch a few more minutes.
Truth#4:
The wisdom of Bret Pettichord emits from the cowboy hat.
Truth #5:
The Saucelabs awesome sauce will eat the copper off of a penny and cause an explosion if added to Diet Coke. (Be the first to capture it on YouTube!)
Truth #6:
Betty Ford is launching an experimental twitter addiction rehab program and has scheduled an intervention for everyone sitting at the table of trouble.
Truth #7:
You can only have a lightening talk at the Selenium Conference if a. you’re Canadian b. you’ve already given a talk c. you’ve got pictures of cats.
Truth #8:
If 300 people show up…then Monday really *is* the first day of ur conference.
Truth #9:
If you put thread.sleep() in your selenium talk, you will get heckled.
Truth #10:
Don’t ask Simon to include anything in Selenium 2 or the answer will be no (especially if it involves Github).
The past month has been all about suitcases for me, packing them with the stuff I absolutely can’t live without, weighing them, re-packing them, getting them checked in, getting some-but-not-all of them back from Salt Lake City, Utah. (Yes, really.)
My suitcases and I have landed in Mountain View, California. I am ready to get my head out of the suitcases and back into the testing community. To do this, I’ll be attending the Selenium conference in San Francisco this week.
This will be the 2nd test automation conference I’ve attended. The first was the 2008 Google Test Automation conference. Up to then, I hadn’t thought of the scripts I was writing at work as test automation at all. It was quite a wake-up call to sit in a room filled with extremely nerdy people who had very sophisticated ideas about and experiences with testing software.
I remember going home from GTAC feeling like my eyes had been opened and that I’d found “my people.” In terms of my career path, I felt as if I had come home. As I’ve just moved back to the U.S., I am expecting that the first ever Selenium Conference will also feel like a sort of homecoming. I suspect that I won’t be alone in feeling that way either.
If you are attending the conference, please say “hi” if you see me in passing, poke me on twitter @marlenac, or leave me a comment.
In the video, Marissa Mayer asks Gaga questions that were gathered from YouTube. Questions are also asked by Googlers in the audience. Usually when a star gets interviewed with questions, it’s a mixed bag. With Gaga, I found that there was a coherent theme around something I’ve been bursting at the seams to write about: congruence.
A Very Congruent Pumpkin
I hear it now..Congruence??? What the fu**…Marlena!! What is that? Isn’t that what you test? Um…no. It’s psychology, bitches. That’s right…I said the P word. Jonathan Kohl wrote a blog post about it which is a favorite of mine. My post will expand on his, explain this concept with the help of Gaga and why we must practice it to build great software and to be great testers.
Let’s start with a quote from the interview about unlocking your creativity:
“I really encourage people to look into the darkness and to look into the places that you would not normally look to find uniqueness and specialness because that’s where the diamonds are hiding.”
Each of us is unique and special. Unfortunately, this is not always respected. In Gaga’s case, she was bullied pretty hard in school. Note that bullying can happen at school OR work. For whatever the reason, bullies can tear us down, make us feel small and undermine our confidence. When this happens, it is very difficult to expose our uniqueness or creativity because a smack-down or a slushee might be waiting around the corner.
We hide who we are as a defense mechanism. This is why people will often hide away whatever part of themselves is unique and special. Unfortunately, being human doesn’t work this way. When we try to hide who we are, when we show the world what we think it wants to see the results might be passable, but they will never be great and they will likely worsen over time.
Image via Wikipedia
Let’s think about what exploratory testers are trying to accomplish. We want to learn the software. We want to explore the software. We do this by opening our mind to the possibilities of what can happen. We learn to trust our instincts about where a user will want to take that and what can go wrong when they do.
For exploratory testing to be successful: We MUST be open. We MUST be curious. We MUST be intuitive.
(Which of these people to the right is not like the other? Answer: ALL OF THEM)
This leads me to ask:
If the everyday reality of your team or your company requires hiding from who you are and pushing away from your inner self and your intuition, how can you be intuitive about what you are testing? If you are someone who is hyper-critical of others (just a few testers in that group), are you causing others to feel that they have to hide themselves or their opinions from you in some way?
Congruence is about matching who you are on the inside with who you are on the outside. What you say to people represents what you are thinking and feeling, not what you think you should be feeling and definitely not what you think the person with whom you are speaking wants to hear.
Going back to the interview, during the section where Googlers are asking questions, a guy in a shiny, pointy hat asks Gaga how she reconciles her onstage “persona” with who she is in real life. Gaga looks him in the eye and chuckles, “Who are you looking for?? I”m right here! Stephanie’s also who I am! Gaga’s just my nickname… I really make absolutely no separation between Stephanie and Gaga. It is the absolute same person…and it is a gift I wish I could give to anyone.” You can’t get any more congruent than that.
So what have we got at this point in our post? We’ve got the Lady in all her Gaga-ness, and we’ve got me saying that it should be totally acceptable to be who you are at all times. I’m sure there are a number of you reading this and thinking, “but she is so offensive to me.” If this is how you feel about Lady Gaga, and you’re still with me in this post, thank you for giving me the room to finish what I have to say on this topic. Please stay with me just a bit longer.
Congruence doesn’t stop at being who you are on an every day basis. It also means recognizing where you stand in the face of conflict. This is where the diamond shines most brightly in Jonathan Kohl’s post: “Whenever I vocalize a small concern even when the rest of the team is going another direction, it is worthwhile. Whenever I don’t, we end up with problems. It helps me retain my independence as an individual working in a team. If everyone does it, we get diverse opinions, and hopefully diverse views on potential risks instead of getting wrapped up in groupthink.” Vocalizing big and small concerns even when the rest of the team is going in another direction is what a tester does. If we can’t be who we are and have the independence to say what we feel, we will fail in our mission as testers. Notice also that Jonathan is saying, “If everyone does it.”
This leads to another question:
How can everybody be themselves at the same time without offending each other?
In this situation it is inevitable that there will be disagreement. If we are channeling our inner-selves and letting the freak flag fly, it is inevitable that someone might get offended. This is when tolerance and mutual respect are a must ON BOTH SIDES.
1. Others should respect and be tolerant of you.
2. You should respect and be tolerant of others.
If either side fails to respect the other and someone is pushed further than they can go, there’s a good chance that the argument will turn personal and, in that situation, everyone loses along with the customer. We have to be able to argue constructively with each other and express what we’re thinking when we think it. We have to be able to do this openly and without fear. If we can’t do this, then we are effectively muzzled as testers and as people. As an illustration of the type of freedom that follows from respect and tolerance, I recently spoke with a developer who expressed his respect for bugs that simply say, “this is awkward.” Is this something you can do at your job? As testers we need to be free to express what we observe when we observe it even if it’s just a feeling that we flesh out at a later time when we are finished observing. This is the road to creativity. Another quote from Gaga: “The most important thing is to honor your creativity and don’t ignore it…It’s when you say, ‘Oh I’m too tired let me just go to bed.’ That’s when the creativity stops coming…You know, if God calls you, pick up the damn phone. Hello!”
I bet if Lady Gaga were an exploratory tester she would be pretty good.
Congruence is all about being the same person on the inside and the outside. What you are thinking and feeling are in concert with what you are saying and doing. Anything else is a compromise. Most of the time, compromise is essential for getting things done and coming to a conclusion in a respectful way, but when it comes to being the person you are, there should never be a need for compromise. Be who you are, not what others say you should be.
I’ll take you in pieces
We can take all apart
I’ve suffered shipwrecks right from the start
I’ve been underwater, breathing out and in
I think I’m losing where you end and I begin
– The XX from their song Basic Space
Down under the roots of everything we do to make software, I see a creative process. It might not involve a canvas, (although it may involve a canvas tag) but those of us working in software are often asked to solve hard problems and to answer difficult questions. At this point, I’ve had a few different job titles in software, but in each one of them, I have always needed to find enough creative space to allow my brain to work its magic on the hard problems. The ultimate goal is to decrease stress or anxiety and increase focus.
How do I know if I’m stressed? Sometimes the signs are internal. Having anxiety pain at the center of my chest or switching back and forth between lots of windows tells me it’s definitely time to walk away from the computer for a bit. Externally, if it’s right before a release deadline or the end of a sprint, I know that even if I think I feel ok, I still need to work on managing my stress level.
So, a few strategies:
Going for a short walk
My friend Gordon and I used to take short, 10 minute walks around the technical campus where we worked in Atlanta pretty regularly. He’s now a counselor, and has actually written his own article about this. We spent no money, consumed no calories and inhaled some fresh air. I’ve continued this in Sydney and plan to continue this wherever I work. It’s a great way of re-booting in the middle of the day.
Do work away from your desk
I used to install “stuff” to a production system. By “stuff”, I mean programs that decided whether or not someone would get a loan. It was messy and stressful. The only way I succeeded at installing the “stuff” correctly and consistently was to prepare for it away from my desk. I would hide in a corner of the corporate cafeteria with printouts of what I was supposed to install and go through my own personal checklist. There was no phone and no one knew where I was (or knew where I was and knew to stay away). I got the concentration I needed and had a high level of success with the installs I did.
Brain dump whatever you are thinking
There are few things more gorgeous to me than the mysterious way our brains can process several things at once and then bring them together when we least expect it in ways our conscious mind would not have put together. If I’ve got a lot of stuff on my mind, I will often take a few minutes and just write. I might write it in an email to myself or I might stick in a text file. Most of these dumps are worth saving because I never know what will turn into a great blog post or test case (or both.) I keep paper in the bathroom because I tend to get a lot of activity in the shower. I used to keep paper in my car because I would think of stuff while driving. It’s not like I action this writing right away, or maybe even ever. I find that the stuff that’s important comes back to me.
Put a relaxation podcast on your iPod
I’ve got a few of these that I listen to at different times. No matter how new age-y and lame you may say these are in public, if it’s on your iPod, nobody has to know. Here’s a summary of a quick one that I like to do at my desk every now and then: Close your eyes or lower them. Visualize what you are thinking. Think “10” and inhale. Exhale and think, “relax.” Think “9” and inhale. Exhale and think relax.
One more because I love it: Sitting at your desk, tense up as much as you can. Neck, shoulders, toes, fingers, legs, butt, everything and squeeze, squeeze, squeeze for 5. Release!
Wear headphones even if you are not listening to music
Is there any better “leave me alone” sign than a big set of headphones? (I guess maybe a big sign that says “leave me alone.”) If you wear the small headphones, and you have long hair, put it in a ponytail so people will see your headphones. If you are wearing headphones to get some space, it might also be worth turning off your chat.
These are a few strategies that I have used to create space for myself and to give my brain the space it needs to do the work I love. If you have a tip that you’d like to share please leave me a comment. Let’s take a deep breath together…inhale…exhale :)
A long time ago, I promised myself that if life offered me an interesting plot twist, I would follow it. Perhaps this is why I love working in the tech industry. The pace is fast and the rate of change is exponential (or sometimes even logarithmic). Being open to learning is required for professional survival. Personally, I’ve found that the plans and dreams I had 12 months ago, are not the same plans and dreams I have today. They’ve gotten bigger and I’m feeling ambitious. (a woman with ambition…this could be dangerous.)
Atlassian has been a great place for me to get my feet wet in Agile and to work with web-based technology. I love Confluence and the rest of Atlassian product line up. It is sad to leave, but life has given me another plot twist, and I’m going for it.
I’ve gotten a job with Mozilla’s WebQA team, and expect it to be a great challenge. Although the job includes exploratory, manual testing it will also be heavy on the writing of selenium checks and test infrastructure with python.
The automation lead for the WebQA team with whom I’ll be working is David Burns. He writes the blog, The Automated Tester, and has published a book on using Selenium. We met at the Google Test Automation Conference in 2008 and have kept up with each other through blogging and twitter. This will be my first opportunity to work with someone I’ve met through blogging which blows my mind!
To join the Mozilla team, I’ll be moving to the Bay Area in California where their headquarters is located. I will miss Sydney and the people I’ve met here. Believe me, I will shed a few tears when I board the plane to leave Australia.
It is, however, a few weeks before I leave, and I’ve got some loose ends to tie up. I’m working on a retrospective of using a wiki for software testing. I also plan to facilitate a session of WTANZ on March 20. Since I’ll be in a timezone far removed from Australia AND New Zealand, this will be the last WTANZ that I facilitate.
Does this mean it’s the end for WTANZ? Although I haven’t made plans for a handover, I suspect that it is not. I’ve been quite impressed with how different groups have taken the “what” of Weekend Testing and changed the time to suit their needs. I’ve also been impressed with the community of testers I’ve found in this part of the world. They are a rollicking bunch and I’m glad I can at least keep up with them on twitter.
Panoramic View of the Palace and Gardens of Versailles by John Vanderlyn
Google’s new museum view is fascinating. It allows you to explore the works of many art museums all over the world from your computer. Looking through the paintings, I saw some that I’ve seen at the museum or even painted for art class. There was one particular painting that made me think about my favorite art history lesson. I won’t reprise that exactly here, but I will give you a taste. The art is different, but the spirit remains.
When looking at a painting, I typically consider:
Narrative: What is happening? Who is in the painting? What is the plot?
Light: What is lit, Where is the light coming from, how much light is there in the painting? Does it set anyone or anything apart?
Shadows: Are they particularly strong? Do they inform the narrative of the painting? Is there something in the shadows?
Color: How intense is the color? Is it used to highlight anything in particular?
Brush strokes: Are they thick and texturized, or minimal?
There is always more to consider, but these are some of the basics.
Be sure to give yourself a few minutes to explore the painting. Zoom in and out, move around, explore! Aside from the aspects I mentioned above, how does the medium and size strengthen or weaken the painting?
The painting was made between 1818 and 1819. The photograph was taken in 2006. Clearly, the 2 artists had differing technologies at their disposal. I love the character in both of them and could not help but notice that they were created for very different reasons.
While the photographer has left us a note on Flickr, the story of the painting is told in the photosynth. How do you think each one plays to its strengths and where do you think they are weaker? What information do you get from the painting that the photograph does not show you and vice-versa. How does the fact that we are now looking at both of these through a computer screen change the effectiveness of their intended medium. A few years ago, the painting would have been out of luck, but both Google and Photosynth create new methods of looking at the painting that gives us a different kind of connection to what we see in front of us.
Because I’m a software tester, I can’t help but think about the technique of cross-checking which I have used time and time again and how that plays out in comparing these 2 works. How can you tell that the painting is an accurate representation of Versaille? Why did the photographer layer the 2 photographs the way he did?
Can you think of the last time you had result “a” and used a different means to come up with the same answer? I can and it looked nothing like Versailles ;)
This week, I’ve been reading the book, “The No Asshole Rule: Building a Civilized Workplace and Surviving One that Isn’t” by Dr. Robert Sutton. For the past few months, I’ve been working at building a relationship of trust with the developers whose code I test. As part of that, I’ve been exploring the divide that often happens between developers and testers. It’s so easy to have an antagonistic relationship and to forget that instead of placing focus on us vs. them (and I’m talking from either side) it should be more important to think about the “we” of the software team. The end goal is, after all, to get the software out the door.
I plan on writing more about this, but for now, I wanted to share a few bits from this quiz in the “No Asshole” book. I took this quiz, and it told me that I am not an asshole (my sister might not have the same opinion). It got more interesting when I decided to reframe it. I substituted all of the pronouns “other” and the word “people” with the word “devs.” The quiz, then, took on a completely different meaning. I’m not posting the whole quiz because the book is worth reading so I hope you’ll find at your local library or purchase it. There is, alas, no kindle version. Hopefully, Dr. Sutton will get hip like Jerry Weinberg who has begun selling kindle versions of his some of his books.
There are 2 versions here, a tester one and a dev one, although the tester rings more true to me than the dev one. Feel free to share results.
If you are a tester, write down true or false for your answers:
1. You secretly enjoy watching devs suffer and squirm
2. You have a small list of dev friends and a long list of dev enemies. You are secretly proud of both.
3. You enjoy lobbing “innocent” comments into meetings that serve no purpose other than to humiliate or cause discomfort to the dev on the receiving end.
4. You don’t make mistakes. When something goes wrong, you always find some dev to blame.
5. Devs keep responding to your email with hostile reactions, which often escalate into “flame-wars.”
6. Devs always seem to react to your arrival by announcing that they have to leave.
If you are a dev, write down true or false for your answers:
1. You secretly enjoy watching testers suffer and squirm
2. You have a small list of tester friends and a long list of tester enemies. You are secretly proud of both.
3. You enjoy lobbing “innocent” comments into meetings that serve no purpose other than to humiliate or cause discomfort to the tester on the receiving end.
4. You don’t make mistakes. When something goes wrong, you always find some tester to blame.
5. Testers keep responding to your email with hostile reactions, which often escalate into “flame-wars.”
6. Testers always seem to react to your arrival by announcing that they have to leave.
The Extremely Unscientific Scoring:
0-2: Not an asshole
3-5: Borderline asshole
6: Certified Asshole
Perhaps the lesson here is that it’s important to keep “we” in mind instead of “us” vs. “them.” This means being less concerned with our job title and more concerned with using our best skills to get the software out the door.
In which you learn why Marlena has so woefully neglected her blog.
What a heavy, freaking year it’s been. Considering that I moved to a different hemisphere, that’s no surprise, but I’m not even talking about the move itself. One of my goals for the year that I don’t think I ever articulated even to myself was that I wanted to work on a paradigm shift for my own approach to visualizing data. My effort to write a treemap application in Processing with Java was the last straw. I guess my experiments with Erlang and Scheme corrupted me. They showed me that there is a way to break free of the loops within loops with loops. Aside from language choice, I had a “Gone with the Wind” moment of deciding that I would never use a spreadsheet as part of a visualization process again. I don’t want to be stuck with static data forever. It’s time to get closer to working with real time feeds as they are the best way to suck in extremely large amounts of data. The sum total of these decisions has been a year spent building new skills. I’ve learned how difficult that can be in the midst of new job that requires my full attention, growing Weekend Testing in my new corner of the planet and enduring my husband’s experiments with Australian cuisine (He doesn’t read my “nerdy” blog, so don’t y’all tell him I said that.)
Part I of the Epic Visualization Quest: A language (or two)
For most of this year, I’ve been on a quest for a new language. I tried on Python and attended Pycon which happened to take place in Atlanta a couple of weeks before I moved. I’ve done a lot of work with ruby which felt more comfortable for me than python (who knows why, I certainly can’t explain these things.) At the end of the year, I started learning javascript. When I predicted, at the beginning of 2010, that functional programming would show up on my doorstep, I had NO idea that javascript is a highly functional language. This really hit me hard when I sat down to write a javascript program with a colleague of mine and we both stared at the screen for 5 minutes before uttering a bunch of sentence fragments that went something like, “well you need a class…” (ain’t no classes in javascript.)
I’m a fan of not just learning a language, but of understanding the headspace of that language. This makes it harder to get started, but ultimately means that I won’t be trying to force java concepts that don’t belong into a javascript program. I’ve also tried to understand which parts of javascript I might not want to use. David Burns, The Automated Tester, suggested I give Douglas Crockford’s Javascript: The Good Parts, a read. I’m halfway through, and while it’s not as hands on as some programming books I’ve read, it’s showing me the headspace I should be in to take better advantage of what JS has to offer. It’s taking me some time, but I have more confidence that what I write will be better code.
Part 2 of the Epic Visualization Quest: Data Access
Most of the experiments I’ve done with data viz have involved spreadsheets, comma delimited data or tab delimited data. I’m completely over using all three. I can’t tell you how much time I spent schlepping data files from application to application in order to get my data in good enough shape to import into a visualization app. Since the files were usually pretty big this turned into going and getting some coffee while Excel would open the file. It was SO annoying. When I attended the Writing About Testing conference in May, Chris McMahon did a short presentation on REST and it opened my eyes. Over the rest of the year, I gradually built up my knowledge of REST and JSON which culminated in an example Ruby script you can use to pull data from JIRA, the Atlassian Issue tracker.
Part 3 of the Epic Visualization Quest: A Visualization Library
Just as important as choosing a language is choosing a graphics library. The 2 major libraries used with javascript, specifically for data visualization are Processing.js and Protovis. Previously, I’ve worked my way through all of the examples in Ben Fry’s “Visualizing Data.” This was the book that initially introduced me to data visualization and convinced me that I needed to read everything by Edward Tufte. Since Ben Fry is one of the creators of the processing language, the code in the book is processing and java. This makes processing.js a no-brainer, but then I took a look at protovis. I’m so intrigued with their example of a parallel coordinate plot that I have to give it a try. I also think that their syntax will be slightly easier to use.
This has been a lot of change on top of change to digest and it’s made the year frustrating. I am still horrible at writing javascript, but I’m also determined to be patient. Good visualization takes time. It is all about details and refinement which requires patience. This patience means that my blog will probably continue to suffer but I’m hoping it also means I’ll have my visualization stack in order which will lead to better focus for 2011.
Btw…next Weekend Testing is on Sunday, January 23. This month we’ll be pushing further into critical thinking.
One of my favorite aspects about being a tester at Atlassian is working with developers who love pushing the envelope by trying out new technology as soon as they can get their hands on it. Recently, I’ve been testing a feature that uses HTML5. Before my testing, I had heard of HTML5 as the apocalypse of testing because of the canvas tag. Canvas is, to be sure, controversial
BUT…
There is much more to HTML5 than the canvas tag.
I’m always tweeting about “dev-nial”, but if all we do, as testers, is scream bloody-murder about the canvas tag, we’re going to miss some bugs as HTML5 creeps into the web applications we test. I was pointed, in a work training session, to Google’s HTML5 Rocks web pages. This post is about the new functionality revealed in the HTML5 Rocks slides and my thoughts about testing features made with HTML5.
If you go through the slides, do yourself a favor and use a browser that has some IDE-ness to it, so you can see what happens with storage or you can inspect elements. The slides were intended to be very hands on and the site, itself, includes a playground.
Web Storage & Web SQL Database
Remember google gears? I remember when it came out and thinking that having the ability to save at least some content offline would make web stuff much more fun. Now that I live in a country with download limits, I see the ability to view web content offline from a completely different perspective. For a feature exploiting offline web storage, I would test that content is still there even if my internet connection is turned off. If you’re looking through the JS you have to test and you see “localStorage.setItem” it’s an indication that something is being stored on the client side.
Security testing is also a consideration. On the html5rocks page explaining the “web sql database” I was originally able to store an unescaped xss string in the web-storage. To be fair, on this page, the user is entering the value to be stored on their own computer, BUT this is implies that it could be possible to insert xss in a user’s web-storage without telling them. (Cheers to the html5rocks team for fixing this possible exploit…y’all might want to have a look at what happens after session timeout ;)
WebSockets bring networking up to browser-level
I’m still wrapping my head around this one, but I think it will be quite important to understand WebSockets thoroughly wherever they are used. In my brief experience with sockets, which was a few years ago, I noticed that it’s really easy to leave a socket open or to get confused about which socket is sending/receiving data. I would want to know where this is used so I can test that the sockets are open when they should be and closed when they are no longer needed.
Concurrency hits browser based testing
When I was choosing a master’s thesis, one of my possible topics was testing and concurrency. I floated this topic in conversations I had at the Seattle GTAC and got crickets (The only person who cared was a guy working at, surprise, Google). I’m guessing that since HTML5 includes “web workers” known to me in Java as “threads” concurrency will become an issue. That means race conditions, contention, etc.
Geolocation
This is something I have absolutely no experience testing. If it’s more available to developers, are they more likely to use it in applications they haven’t before? If I had to test something with this feature, I’d have to figure out how to mock a location. This would be interesting to test as it related to offline storage. If you have part of the application that relies on coordinates, but then the app goes offline, is there a way for the user to type in their coordinates?
Device Orientation
Whatever computing device you are using to read this, iPad, laptop, desktop…yes, even desktop, tilt it. If you are on a mac, you will see interesting things happen. If you are on windows, not so much. Since I’ve already noticed a difference in the behavior of the same browser on different operating systems, this is definitely something I would test across devices and operating systems. So if I’m lost in the urban jungle with my laptop, I should be able to orient myself with google maps on a mac, but if I have a Windows 7 netbook, I’ll just be screwed? [Update: I submitted this as a bug and the HTML5Rocks team pointed out that it’s because my netbook does not have an accelerometer. I’m kind of surprised that the MacBook has one. #learnsomethingneweveryday]
There are many more slides to digest at HTML5 rocks. If you look through the slides and have some thoughts about testing, I encourage you to leave a comment or, even better, write your own post. If you find a few more bugs, I’m sure Google would absolutely welcome and cherish any bugs reported. When the next version of Confluence is released, I’ll write more about my own exploits with HTML5. I was taken by surprise at how quickly it showed up for testing and very impressed by the dev who decided it was time to make use of it. If you use Confluence, I think you’re going to like the next release, and I’m not biased at all ;)
In the past week, there have been two blogposts one about testing and one not necessarily about testing. Both, in their own ways, dealt with a theme of caring.
The first is a post on the Thoughts from the Test Eye blog from Martin Jansson titled, Turning the Tide of Bad Testing. The centerpiece of Martin’s post is the Broken Window Theory which you can read about in his post. He ties it to testing with a thought provoking list of how broken windows manifest in software testing. To me, the list is a masterpiece. There are a couple of items on that list that stand out in terms of this post:
“How do we see Broken Window Theory affect testing?…
When you have stopped caring about how you test.
When you have stopped caring about how you cooperate with others.”
The second post is Alan Page’s post on Leadership and Caring. It’s one of his shorter posts and he wrote without the intent that it was about specifically about testing. He writes that, “Leaders care about making progress in their work and in sharing their results. More importantly, they care about the work and progress far more than they care about their popularity.” His post seemed to strike a testing nerve which is revealed in some of the comments of that post.
Both of these posts were well-timed for me as I have just finished reading a very interesting book, The Sociopath Next Door. As the title suggests, the book is about Sociopaths. These are people that lack the ability to care. They have no conscience. Every move they make is merely to make themselves more comfortable even if it requires looking like they are helping others. The book illustrates several examples of sociopaths including the so-called “Captain of Industry” whose sole goal in life is to win, regardless of the pain and chaos it creates for other people.
As I read this book, I kept thinking about testing. At times, I have felt that, as “the tester” I am the conscience of my team. The truth is, I work on a great team where everyone cares about what we release. The more interesting question is, could someone who has no facility for caring about others make a good tester? What if a tester works on a team with a leader who has no ability to care? What happens to the testing?
Before I read Sociopath, I had never stopped to carefully consider the role conscience plays in testing. Critical thinking is great, but it’s equally important to understand people’s motivations. Caring sits in an under-layer that is easily forgotten or dismissed as being yet another “personal” or “soft” topic (I call them hard topics). Perhaps it’s more of a foundation than an under-layer. If so, what does that mean if it’s missing?
