It has been nearly 3 months since I joined Pivotal Labs and the Pivotal Tracker team. So far, the experience has been great. While most of my time is spent writing email replies helping people get to know Tracker, I’ve also done plenty of testing and even committed a tiny fix. In short, I’ve been doing whatever the team needs done and it has all been fun.
There is plenty to write about with Tracker. Aside from selling what I personally think is a great tool for managing software projects, there is how the Tracker team operates. Obviously, we use the tool we make, but there’s another layer that is firmly grounded in the culture of trust I have found at Pivotal Labs.
Starting with this blog post, Tracker on the Agile Continuum, I am working along with my teammates at getting the Tracker Team’s story out. You might want to follow the Tracker blog because I’m not sure how often I plan to do “content pointers.” This is because I am more of a fan of having actual content in my posts, and besides, If you like my post, you might like some of my Teammates’ posts as well.
There are some phenomenal writers on the Tracker team, and next week, we’ll be welcoming another great writer and tester, Lisa Crispin, to our team. Tracker’s collaborative energy is ever rising and I hope that by combining the building of an awesome tool with writing about our experiences, we can disseminate even more of that energy. Working with it every day has been invigorating and I’d like to say thanks to all of my teammates for that.
Although the question in the title frames this post of how it’s going for me at Tracker, I’d love to hear about how it’s going for you with Tracker. If you send an email to tracker at pivotallabs dot com, chances are, I’ll be the one who replies. Send me your questions, your frustrations and your bugs!!
I have wandered into an oasis in the middle of a desert…
Water!!!!
O wait. I’m at The Mirage in Las Vegas. I’m presenting tomorrow at the Better Software Conference in Ceasar’s Palace.
The Mirage in Las Vegas
I’m here to wrap up my credo series by presenting my credo and the steps others can use to create their own at the Better Software West/Agile Development Practices Conference.
But first, it’s time to really shake out my credo. I’ve been adding to it for quite a while now and it’s been good to see it grow. Writing down things that I believe has been a great confidence builder. Now it is time to go through each part of it and edit.
As a nomad in the desert can pack up all of their belongings and carry them from place to place, my credo is supposed to suggest ideas and values that are so core to who I am that I can take that they survive even among the shifting sands of the tech industry. They should be succinct and easy to remember. In fact, Bret Victor in his talk, “Inventing on Principle” suggests paring it down to one and only one guiding principle. (His talk is worth setting aside an hour and contains some amazing UX technology guided by his one principle).
This editing down of the credo is the “so what?” test and it involves looking at the credo through the lens of clarifying values. I really like the list of clarifying values listed in “Building Your Own Theology” and found them to be a great guide. After all, if I am willing to say I believe something, I should be willing to affirm it in public in front of my peers, act upon it and practice it consistently.
“Values, meanings and convictions are:
1. Freely chosen
2. chosen from among alternatives
3. chosen reflectively and deliberately
4. prized and cherished (you feel good about them)
5. willingly and publicly affirmed
6. acted upon
7. part of a consistent pattern of behavior”
It is also worth asking for each statement in a credo if “you practice what you preach” and rating that on a scale from 1 to 7.
I’ve written about the concept of congruence before. This is matching what you think and feel on the inside with what you do and say on the outside. Going through your beliefs and asking yourself if you practice what you preach is a great way to assess your congruence. If something is out of whack, maybe there are some changes you can make to bring yourself more in line. I realize that this is much easier said than done, but following through on that is necessary for building self-worth and confidence.
Here are a few more questions that round out the so what test:
How do the statements in your credo interfere with your career today?
What are the main obstacles for living your professional values?
What plans can you make to bring your professional life more in line with your values?
What will you do differently after today?
If you’ve been reading my blog, you may have noticed that I made a rather big change recently when I switched jobs from Software Engineer in Test at Mozilla to Support/QA for Pivotal Tracker. That was a direct result of noticing that I wasn’t living out my beliefs and values. My life has been fairly nomadic in the past few years and if there is one thing I have learned it is that life is too short, too precious and too wonderful for me to spend even a minute of it with my values out of whack with the way I live.
Tomorrow, I’ll post my credo here after I have unveiled it in my session. If you are at Better Software West/Agile Development Practices, you can catch my session at 4:00pm in Florentine Ballroom III.
The Cathedral & The Bazaar (Photo credit: Hades2k)
Even though the software credo I am writing is a personal thing, I’m not writing it in a vacuum. We are all writing the history of software and, at this point, the history of computers and software is big enough and old enough to have it’s own corners and back alleys.
In this post, I’ve researched into some questions about computer & software history. I’ll be writing about some events that were important in my corner of computers, some of moments which were not the best, and the event I would most like to have witnessed. Who are some of the important people or events in your particular area of software and what did they contribute.
I’ve already blogged about The Ultimate Nerd and my ultimate nerds so I’ll be focusing mainly on the events in computer and software history that has meant the most to me.
The fight between Internet Explorer and Mozilla
I may have just left Mozilla as a corporate employee, but Mozilla and its mission are still very much alive to me. If you don’t understand what the whole fight for the open web is about, it is worth Investing 40 minutes of your time to watch Mitchell Baker talk about the history of Mozilla.
Back in the nineties, I remember listening to NPR every day for news about how the lawsuit between Microsoft and Mozilla was proceeding. I hope that, at some point, a book is written about the history of Mozilla and some of its projects. I had chills more than once as I watched Mitchell Baker give this talk on the history of Mozilla. A lesson she learned from the Mozilla project and her most memorable quote from this talk is something I will carry around with me until I die, “Leadership depends on who will follow you.” (It’s at 11:30 if you wish to listen for yourself)
The blossoming of the open source software movement
The theology of the open web and open source software is deep water which I’m not expecting to plumb in a couple of paragraphs, but if you give yourself the time to really dive into the history and its ideas, you will be rewarded.
If you wish to wade into these waters, I highly recommend reading through The Cathedral and The Bazaar by Eric Raymond. It is beautifully written and I think I must have highlighted half of it. Although there are frequent references to the creation of Linux, the paper itself is timeless like K&R or Unix Shell Scripting.
Reading through this paper, I could see some of the groundwork for agile being laid. There is a spirit of egalitarianism coupled with a “need for speed.” Raymond mentions in a few places that it is important to “release early, release often.” He also writes about the very inclusive development philosophy of Linus Torvalds which was counter to the more exclusive “cathedral” model of isolating a few geniuses and letting them polish the software creating a longer release cycle.
This actually deserves a longer post and critique in the context of what we know about open source today.
Looking at the number of people who were present for this event, I will never understand how they were all able to agree on the document itself. It appears to me to be one of the greater examples of consensus. The fact that what’s in the manifesto meant enough to these guys to get together and agree on it sends a strong message. I consider myself lucky to swim in this every day at Pivotal Labs and I hope my blog helps you push further with it in your own professional life.
Historical Software Defects
These are the moments in software history that are not the greatest but they have valuable lessons to teach.
Therac-25
The, “primary reason should be attributed to the bad software design and development practices, and not explicitly to several coding errors that were found. In particular, the software was designed so that it was realistically impossible to test it in a clean automated way.”
The Therac 25 was designed to automate the delivery of radiation therapy to cancer patients. Tragically, it sometimes injected patients with levels that were too high, even tragically high.
My software engineering teacher, Dr. Susan Duggins, first introduced me to this in our software engineering class. It’s important because it highlights that testing should be involved earlier in the software process and that building software is not just about typing out the code. I am in love with the idea of ecosystems as they apply in software and in open source. This legal case points the way towards software occurring in an ecosystem.
The Mars Rover
Imagine that you’ve spent months working on a small vehicle that will land on Mars. Imagine the pressure of knowing that many millions of dollars has been spent for you to do this work. It’s a crowning achievement involving your team and other teams as well.
Imagine that the Rover lands and doesn’t work because you’ve been programming in standard measurement units, but an external team you’ve been working with has used the metric system. I would have cried for days.
The failing of the Mars Rover demonstrates the power of good communication and how major defects can occur without it. If you are a tester and you sometimes feel like the team therapist because you’re trying to get developers to talk with each other, I have news: You are not alone in feeling like a therapist. If you ever wonder if you are doing the right thing or sticking your nose where it doesn’t belong, think of the Mars rover team.
If you could only witness one moment in computer or software history, what would it be and why?
For this question I am brazenly cheating. I’d like to watch one of the great visualizations being drawn just to see the tools that were used and the place where it was being drawn. These had to be hand drawn as there was no machinery to produce them. I’d like have a look at the instruments used to make the measurements and the drawing implements. I’d like sit in the chair that William Playfair sat in or watch Charles Joseph Minard explain his visualization of Napoleon’s March.
This concludes my look at software history for my blog post, but it’s brought up some threads I’d like to push further. I’m not quite finished reading and writing about “The Cathedral and the Bazaar.” I’m also not finished with “Leadership depends on who will follow you.” It’s a funny thing about these credo posts. They tend to open more doors and windows than I have time to close. I don’t mind leaving them open, however, as this is letting in some fresh air. Wherever you are, I hope that when you get to the end of my post, you take a minute and just…breathe.
In a few weeks, I’ll be joining Pivotal Labs to work on the Pivotal Tracker team. I’ll be mainly handling support requests and helping with some testing as well.
What drew me to Pivotal? After all, I’ve got a job as a Software Engineer in Test at Mozilla working with Selenium tests all day every day, what more could one possibly want? Judging by the number of recruiter emails I get, a Software Engineer in Test working with Selenium all day can pretty much right their own ticket, can’t they?
Well, yeah, and I <3 Selenium, but it’s just one part of testing. In fact, writing Selenium tests is just one aspect of making software. I’m ready to own up to being a specialist who knows a lot about testing and automation, but I’m also a generalist who helps make software. At one point, I thought I only wanted to work on test automation infrastructure, but I’ve since learned that I prefer working with a product team.
This all came about while writing the credo posts that have pre-occupied me since January. I’ve learned that I love writing more than any other occupation and that participating on a team making software is more important to me than identifying as a tester.
This change will move me into a world where I toss out my own self-imposed label of “tester” or “automator” and throw my bucket of skills at a highly collaborative software team. In letting go of being “the tester,” there will be other skills that I now get to exercise:
Being a great teammate. While this is important at Mozilla, I expect even more emphasis on this in the tightly coupled, rabidly agile environment of Pivotal Labs.
Since Tracker support is 100% email (plus whatever y’all throw me on twitter), I get to use my communication & writing skills as a primary part of my job.
The x-factor skill which isn’t an obvious skill in software, but will be crucial for support is having a developed sense of “mindfulness” or non-judgmental awareness.
This is all in addition to flexing my technical skills at bug isolation.
Despite leaving Mozilla, I still have quite a fondness for the company, its mission and my teammates there. As a parting gift to them, I have stolen the following anonymized excerpt from deep within the bowels of irc. I hope it gives you a chuckle and some encouragement to, “whisper to the fox:“
FirefoxLvr404: come to think of it sweatsbac0n, I’ve seen you blogging, but I haven’t seen you blogging about how opensource html5 makes you opensmile
FirefoxLvr404: how much more delightful canvas web technology do you fucking need?
sweatsbac0n: *laughs*
sweatsbac0n: what the hell are you talking about?
FirefoxLvr404: I’m talking about firefox enriching your happiness & defending your freedom by exposing webgl & websockets APIs on top of a lightning-fast javascript engine
FirefoxLvr404: and all you do in return is treat their animonsters like DIRT
FirefoxLvr404: I hope you feel <yourself proud=”true”/>
FirefoxLvr404: I bet you assumed that blue mass was the world
sweatsbac0n: You mean it’s not?
sweatsbac0n: Is it an egg of some kind?
FirefoxLvr404: it’s the cold lonely heart within all of us
FirefoxLvr404: that can only be warmed by having a fox wrapped around it
sweatsbac0n: *laughs*
FirefoxLvr404: a firefox, warming your chest cavity.
FirefoxLvr404: making you whole again.
FirefoxLvr404: whisper to the fox, sweatsbac0n
FirefoxLvr404: wind your arteries gently through its fur
sweatsbac0n: Wow. I’ve never felt closer to a browser before.
FirefoxLvr404: I should hope not.
FirefoxLvr404: You deserve better than any other browser
sweatsbac0n: it feels so wrong. and yet….so right.
Indeed…don’t forget to update your Firefox today and did you know that Pivotal Tracker let’s you have as many public projects as you want and 5 private ones as an individual for free?
Through this process of building my own software credo, I’ve been taking liberties with the Unitarian process of building your own theology. For this post, I’m taking an ultimate liberty and switching the chapter on examining my personal theories about “ultimate reality” to examining my concept of the ULTIMATE NERD.
To begin this exercise, I’ll examine my take on the stereotype of nerd and “ultimate nerd” during these various phases of my life:
As a child
As a young adult
As a Computer Science major
Now
As a child
Let’s just get this out of the way, because we all know it’s coming: If you grew up in the U.S. during the ’80s, it’s highly likely you share a youthful vision of a definitive nerd with me.
It’s quite difficult *not* to associate “nerd” with the nerds portrayed in the movie “Revenge of the Nerds.” The stereotype was pretty abstract for me and didn’t change that much for a long time. As I got older and went through high school and college…well…the first round of college, a nerd meant an unattractive man with glasses who liked computers. There’s no depth to this stereotype, but that was to change…
As a young adult
If you lived in Atlanta or even possibly other places in the Southeast during the 90’s, chances were that your ISP was Mindspring. This had a big impact on my ideas about nerds. As I began to cultivate a healthy respect for computers and even began dabbling in programming, Mindspring became it’s own cultural nexus in my hometown of Atlanta. I swear they must have blasted the lunchtime 80’s radio show, House of Retro Pleasure, at lunchtime in their offices since half of the song requests came from Mindspring employees. Calling their tech support was fun!!! Nerds were no longer the cardboard cutouts of my youth. They were now friendly, vibrant people with enough intelligence to work with computers. My vision of the ultimate nerd switched to a guy my age, slightly gothy with a dark sense of humor.
As a CS Major
AND THEN…I enrolled in a CS program. Did I think of myself as a nerd in my Programming 101 class? Not really. I was learning C++ and conquering Computer Architecture but there was always that guy in the class who had owned a Mac or Commodore since he was 4 years old. It is really hard to claim street cred when you are the only girl in a class and struggling to make a B (sometimes I made A’s but not always). This eventually changed when I attended a Grace Hopper Conference and saw a presentation on what we see when we think of “nerds.” I realized, I had assumed for many years that to be a nerd, you have to be male and/or have snuggled up to a computer like it was a security blanket every night since infancy. It took this presentation to help me let go of those particular stereotypes.
Now
“Nerd” is definitely a stereotype and a label. As with any stereotype, it can be used for good or for bad, but in my case, I see it as a positive label and one that I’m happy to own.
I believe a nerd is someone with a deep understanding of technology, but it doesn’t end there. A nerd is someone who has a deep understanding of technology and who also understands the connections between technology and real life. As for “deep understanding of technology,” that can be parsed forever and I’m sure there are plenty of nerd fights about what’s more technical. I’d rather focus on the second half of this because it means wanting to share technology with others. What good is all of the technical knowledge in the world if you’ve locked yourself away, sneer at everyone you see as “less technical” and refuse to explain anything to them. Good luck with that.
A nerd is someone who gives their Mom an iPad or who loves making crazy websites and having their friends play with said crazy websites. They might wear glasses or they might not. They might be transgendered or they might be a family guy who wears khakis and a plaid shirt everyday. They might live in Silicon Valley, Conyers, Georgia or Mozambique, and keep in mind, this is just my version of a nerd. Yours might be different. The Ultimate Nerd
An ultimate nerd is someone who embodies these qualities I consider to be “nerdly,” and takes them further. Ultimate nerds not only have a deep understanding of technology and a willingness to share it, they change what’s possible and they don’t have to put people down to do it.
This significantly narrows the field, but that’s ok. There are plenty of asshole nerds out there who have dazzled us with one thing or another while treating the people around them horribly. I demand more than that from anyone I consider a leader or “ultimate” anything.
While “nerd” is a label and a stereotype, it holds relevance for me because it describes something I found in myself at the end of a wild and uncertain journey. The idea of an “ultimate nerd” points me towards places I want to go in my career but haven’t yet reached.
In my next credo post, I will indulge in labeling a few people as “ultimate” nerds. Hopefully, they’ll be ok with that.
We are always on a journey in our lives and in our careers. The journey takes us through sands that shift sometimes more quickly than we can move or even dream. If you have ever walked on sand before, you know the feeling of uncertainty that comes with each step no matter how sure you may be of the direction in which you travel. Although the ground is solid, it feels as if it will slide out from under you at any moment. It is difficult for a human body walking through sand to retain balance as the ground is constantly shifting underfoot. In fact, there are some places in the world made up of so much sand that the entire landscape will shift in a matter of weeks or months. Welcome to your career in software.
In the outside world, there is little that humans control. Eventually storms overtake us, the hail rains down and the locusts swarm around us. There are, however, things we can control. On a trip that I took through the American desert a few years ago, I had a good tent and a sturdy pair of boots.
Now that I’ve torn down my own world in software and in testing, I’m ready to rebuild. California is a new place and, as Patrick Welsh describes it, a “State of Consciousness,” so I’m embracing a new perspective.
In this world of shifting sand,
What is worth keeping around?
What is it that keeps me upright and moving forword?
When I’ve gone astray, what or who has helped me right myself?
What has endured in the software industry and in my own career?
These are some pretty deep questions I’ve decided to probe in an effort to understand myself in relation to the fantastic mess that is the tech world. Although I am still moving forward, I’ve decided to build a tent which will move along with me, but also be my own personal sanctuary. In this new year of 2012, I will be working on my personal software credo. It may appear very hand-wavy at first glance, but my intention is to connect what I find in my exploration to the value I bring in the workplace.
A credo is a set of personal beliefs or a personal mission statement and is a counterpart to a “Creed” which is more formal and typically created by “experts.” These are mostly written in the context of theology, but I’ve noticed more than a few “creeds” in my professional life. We have rules, “guidelines” and “mission statements” thrown at us whenever we join a new org, attend a conference or affiliate ourselves with a professional group.
Personally, I’ve tried to keep myself unbound from any of these as I prefer to define my professional life and, indeed, life on my own terms. As such, I’ve noticed that there are certain people, places and mission statements that ring true for me. Going through the process of writing a software credo is my way of integrating all that I’ve learned about the raw stuff of my own personal existence and making software. My guess is that it will help guide me in making decisions and choosing my future directions.
I will be blogging what I do along the way and plan on unveiling my credo next June at the Better Software/Agile Development Practices conference in Las Vegas. It is no accident that this is a joint dev/test conference experience, but it feels quite serendipitous that this is taking place at a man-made oasis in the middle of a desert.
My first step has been to work on my software autobiography. I couldn’t help but notice that Michael Larsen has been doingthe same as the rock star that he is. Stay tuned…
This post is a wrap-up of some of the things I’ve been learning about performance. It includes some follow-up from my last post on isolating performance problems with Firebug
One of the comments from my earlier post suggested that this is also baked into Chrome. Although I work for Mozilla which means I spend most of my time using Firefox, I have no problem duly noting that Chrome contains some excellent tools for looking at performance as well. In this post, I’m actually going to show how Chrome can be used to get a sense of front-end performance. (If you think that Mozilla and Google are adversaries, you might want to have a look at this and this.)
Let’s put some definition around front-end and back-end performance. In my previous post, I was looking at calls going to the back end server and how long those were taking. That’s back-end performance. When we talk about front-end performance, we’re concerned with HTML, Javascript and CSS performance. Admittedly, I knew absolutely nothing about this side of performance before attending an HTML5 conference in September aside from some googling I did which resulted in this guerilla post. Note that I wrote that post before I saw this talk by Steve Souders, creator of YSlow. The talk itself was quite an awakening, and afterward, I knew I had lots more homework to do. (This link is to a similar presentation done by Steve at a JS Meetup a week or so later.)
After the conference, in addition to hunkering down and learning more about CSS, I started looking through both of Steve’s books, High Performance Web-sites and Even Faster Websites. Both of these show that there is a lot which can be done for performance on both the front-end and the back-end. Since he works for Google, there is some cross-pollination of his ideas and the information you get out of Chrome’s developer tools. An example of this cross-pollination is Chrome’s ability to do an audit of front-end performance. To get to this functionality, open Chrome, click on the wrench in the top right corner (I hear this is a spanner in the UK) -> tools -> Developer Tools. This will open the Developer tools, from there, click on the “Audits” tab. If you are already on the page you want audited, you can select select “load page and refresh browser” to get more accurate results.
Here’s a screenshot of an audit for addons.mozilla.org.
A Chrome Audit of Addons
Some of what I noticed in here maps to suggestions in the book, “High Performance Web-Sites.” For example, one of the suggestions is that some of the components being downloaded need to be gzipped. This is the same as zipping files so that they are small enough to send through email only in the context of a web-page and http request. There is a header which can be added to http requests so that the response you get back from the server is zipped. Who knew!!!
Although the Google Chrome Audit will catch some things, there are other suggestions Souders makes that it doesn’t mention. For example, it’s worth understanding which images on a webpage should be included in a sprite. Sprites are used to aggregate several images into one. They are laid out in a grid and are accessed by coordinates. Here’s an example of a sprite used for the addons.mozilla.org details pages. If you’d like to see it in action, have a look at this page. The icons are on the top right where it says, “add to this collection” and “share this addon.”
An example of something I plan to question more in the next quarter, is the usage of CSS expressions in addons. Even though CSS is used to control the layout and style of a page, it is entirely possible to include “if” statements in CSS via the expression method and the ternary operator. Rule #9 in “High Performance Websites” advises against using this because the expression will be evaluated when the page is rendered, resized, when the user scrolls or even moves the mouse over the page. I’d like to understand more about the tradeoffs when I see them used such as here.
An early observations about looking at performance is that this is an area awash in tools and it would be easy to just keep trying new tools without digging deeper. Opening Chrome or Firebug and pointing them at a page is easy enough, but I’m ready to look through some of the front-end code, talk with the devs and begin approaching performance in AMO with more precision. More to come in the new year…
This is one of those posts that simmered in the back of my mind for months until I read Scott Barber’s blog post 10 Things about Testing that Should Die. Scott’s post is one of the most memorable posts I’ve read about testing in a long time and reading it created the mental tipping point I needed to write things down. (and, yes, I suggest you read it too. If you are a conference organizer, it would make a great keynote.)
One of the awesome contacts I’ve made through the Writing About Testing group is the editor for Techwell, Joey McAllister. When Joey saw me tweeting that I might have to blog some stuff, he asked if I wouldn’t mind writing it up for Techwell.
Last week, I isolated a performance problem that started with the failure of an automated test. I’m blogging it because the bug has an interesting story which highlights some of the weirdness I’ve typically found when isolating performance bugs.
A teammate of mine, Alin Trif, noticed one of our automated checks failing. It writes a review for an add-on. He replicated the failing test manually and wrote up the bug. Since a few others in our group couldn’t replicate the problem, it was subsequently closed. In true tester fashion, Alin mentioned it to me anyway. I thought “what could it hurt to try reproducing it.” So, after opening our staging site, addons-dev.allizom.org, I went through the steps…and reproduced the problem.
Note that I did not just re-open the bug. Personally, I think re-opening bugs is a great way to alienate people who are ready to move on from a particular issue and make testing more irrelevant on your team. This doesn’t mean dropping the ball on a problem. It means that it’s time to uncover more or better information which would likely result in a different bug being opened anyway. If you read to the bottom, you’ll find that this was, indeed, something else entirely.
Two of my favorite web testing tools are Firebug and Skitch. Although I generally use Firebug for inspecting web pages and finding the locators I need for writing Selenium-Webdriver checks, it will also show metrics for requests and responses. To access this, open Firebug and click on “net”
Firebug -> Net
In this case, while the request was off in never-never land, I opened Firebug, switched to the net tab and took a snapshot. When the request eventually finished, I took another snapshot. This time, the culprit is pretty clear.
Although I was testing the addons staging site, the bug is actually for Browser-ID, Mozilla’s new solution for single sign-on.
With the screenshot in hand I logged this bug against browser-id.
Interesting take aways from this bug:
Unless you are actively looking for performance bugs, they are extremely easy to dismiss. In this case, it looked like it wasn’t reproducible. These are also easy to miss unless you are hyper-sensitive to slowness. (Every tester ought to know their physical triggers of impatience for slowness. Do you tap your fingers and/or roll your eyes and/or cuss at the screen?)
If you’re frustrated about one of your bugs getting closed or marked invalid, it’s time to talk to someone about it vs. only leaving a comment.
Using Firebug and your screenshot tool of choice makes it fairly painless to document these bugs. I’ve caught bugs like this before and ended up installing a third party tool for looking at the time taken for requests and responses. This is now much easier if you download the Firebug add-on because the tool is right in your browser.
The next time, something “feels slow” or “slower” to you, give this a try. You might find something you weren’t expecting.
Hat tip to Alin Trif for finding the bug and asking about it even after it was initially closed. That’s good testing.
The organizers of this year’s GTAC, are attempting to get us nerds at the conference to socialize with each other. When I checked into the conference this morning, a fistful of buttons with a yellow “A” were shoved at me. Before the keynote, James Whittaker let all of us know that we were given the buttons specifically so that we would trade them and “be social.” If we get all of them, they spell out “GTAC” and then there’s one button which has a picture of the cloud. Rumor has it, that if we want the cloud button we should find bugs in the GTAC android app and tweet them.
The gtac app is intended for use by conference attendees for viewing the schedule, making tweets, taking notes about the conference etc.
My former Atlassian partner in testing crime, Mark Hrynczak and I decided to pair on looking for bugs. We had a great time testing Confluence together so we decided to pair on breaking the GTAC app. If this a test automation conference, did we run off and make a bunch of automated mobile tests? Um, no. It didn’t take us much playing with the app to find a couple of crashes and a few oddities.
Here’s Mark with our first crash:
Really GTAC app?
Steps to reproduce:
1. open the app
2. tilt the phone sideways.
Here I am with our 2nd crash:
Just don't install it on a tablet.
Steps to reproduce:
1. install the app on an android tablet
2. try to open it.
After Mark and I finished playing with the app together, my phone started tossing up errors from, guess what…the gtac app!
Aside from crashes, we found some other issues. While I wouldn’t consider these as serious or impactful as a crash, I’d probably raise issues for these. (Just don’t ask if they’d be raised in JIRA or Bugzilla.)
1. We couldn’t figure out where to add notes initially. When click on notes, it opens a page where there’s no way to add a note.
2. Notes don’t link back to sessions.
3. Notes are saved in email as an xml file. What am I going to do with notes in xml format? I don’t know about you, but I’m not in the habit of reading through my notes as an xml file.
4. Why have notes as separate choice if they are attached to sessions?
5. Opening tweets and hitting back doesn’t take the user back to the gtac app. It’s like the app is expecting you to press the one button at the bottom of the interface (o wait, that’s the iphone).
6. There is a “sandbox” tab in the “starred items” window. Why?
7. None of the sessions, including keynotes, list the speaker
After we found the first crash, I rushed up to James Whittaker with Mark and said, “Hey you! We broke your fancy gtac app!! Can we get a pin!” James, who was on the way to the podium looked at me and said, “This is the last time I ask for bugs at a testing conference…you should tweet your find.” So I did. A few minutes later, a googler I had been sitting with at lunch came over and gave me a cloud pin.
Cloud...we haz
This leaves me with a dilemma. While the pin was given specifically to me, Mark and I worked on these bugs together so it’s only fair to work something out especially since a cloud pin means you get a prize at the end of the conference. If you’re a Googler at GTAC reading this post and you still have a cloud pin, please consider giving it to Mark (or if you can’t find him, I’m happy to pass it along.)
Update: Supposedly bugs in the app have been fixed. Hmm…
