Simply put, feminism is a movement to end sexism, sexist exploitation, and oppression.
Simply put, feminism is a movement to end sexism, sexist exploitation, and oppression.
The road to redemption sometimes starts with a software mantra.
In test driven development, doing the simplest thing is a guide intended to keep you unblocked and moving:
However, doing the simplest thing can still be a challenge and might not even look like it is immediately moving you forward. Often, the simplest thing is a hack that looks like a badly drawn picture or a step in the opposite direction.
It takes practice to rewire a bold and busy, future-driven, human brain for this type of thinking. The trick is in repeating and following the mantra. The challenge is in continuing to follow the path. Your steps and tests won’t be perfect every time and your brain won’t like the fact that you are discarding so many fancy plans, but this is the practice. You are walking a path and each next step is the smallest, simplest one you can take.
This path will wind itself further into your thinking slowly and steadily over time. Your brain will relax into the small steps. The architecture of your code will change. Your focus will sharpen until you see only the step in front of you.
Although this may look and feel like tunnel vision, you will eventually find yourself reaching for the simplest thing when you are faced with larger challenges either in software or in real life. It is this focus on taking a single simple step that will start to open some doors and help you break through limitations in your code and also within your own mind.
Often, when viewed from the outside, the simplest thing equates to something far beyond easy. It could be making a change that breaks all of your tests or it could be admitting that you were wrong about something or, even harder, wrong about someone. It’s here that doing the simplest thing means tearing down a wall you’ve built inside yourself. That’s not easy.
Although the software lesson is in the accumulation of small, simple tests that become a safety net for experimentation, the larger lesson has more to do with how we approach our own inner limits, choices and patterns. As humans, we have a tendency to remain stuck in our own lives, unable to see what is blocking us as we debug, console.log, and pry ourselves until we can’t pry anymore.
When we are in a state of discomfort, the simplest thing can appear to be a tiny kite hovering far above and out of reach, amidst the thick dark storm clouds we hang over ourselves. It might look far away, but it’s not. This is when the simplest thing turns into whatever it is that takes you one step away from frustration. This might mean walking away or it might mean doing something you feel certain is wrong or something that is scary but that will keep you moving.
In the end, that is what doing the simplest thing is all about: keeping you moving with smaller steps. This focus in a moment when you are wracked with self-doubt and frustration is not going to give you a test suite, but it will give you something far deeper: a sense of relief. With practice, relief eventually turns to confidence and you will see the clouds in your own mind begin to disperse.
Some tweets are like a Rorshach test and it’s much easier for people to project onto them what they want to see. This tweet is such a case. The quote can be interpreted in a few ways, all of them insulting. It really hits the tester nerve, especially for testers who take pride in their testing skills and have worked to make them better. I can see how it especially hits the nerve of testers who have worked to set themselves and the activity of testing apart from development as its own industry and job role with its own set of skills.
It makes sense that the natural reaction to this is to reach for pride and say, “I’m a tester, FUCK YEAH!!!”
What’s been missed, though, is that this tweet was part of a mini-rant. I was actually going for something more complicated that speaks to where testing is going within the broader context of the software industry and my place in that paradigm shift.
Let’s take a moment to acknowledge the fun side of testing that we all know and love so well. We poke, we break, we question, we investigate, we discover. It’s fun!
Now, let’s examine the rest of what comes with a career in testing:
I’m sure there are people who would argue that the subset of baggage listed above doesn’t mean much in comparison to how much they loooooove testing and the pleasure they take in breaking things. If they want to stay in “testing” forever, that’s fine with me.
I disagree, however, that I should be content with less pay, a smaller set of career options and a position where I’m consistently marginalized on a team or even in tech.
It also occurs to me that the women’s restrooms at testing conferences are always crowded compared to the ghost town that is the women’s bathroom at any tech office or developer conference. There is no mystery here.
I started my rant because I had occasion to send someone I respect two of my favorite testing posts by Trish Khoo and Alan Page. When Trish and Alan suggest that testing teams are going away, that testing is an activity done by many on a software team and that testers should level up their coding skills, I see a role coming into focus where I am more empowered and more of an equal on a software team. I see a role where I’m even more in the thick of the software engineering process than I already am. I see a role that uses my testing skills and develops my problem solving skills as well. I see myself as a developer who is great at testing. One feeds the other and I am making great software as part of a team. All of this fits particularly well in the Agile XP process which includes TDD.
I’ve been working at building my web developer skills and I’ve found a team where this type of contribution will be welcome. It hasn’t been easy and this is all still a work in progress, but I can see the tipping point fast approaching.
No one can make you feel inferior without your consent.
By the way, the short-sighted person quoted in my original tweet wasn’t a developer. It was another tester. I am surrounded by developers who see what I’m doing and who couldn’t be more supportive.
Now that you have the full story, let’s look at my tweet again.
I just want to add…watch me.
Here I am at my desk, doing some cross-browser testing. You’ll notice that I’m surrounded by screens.
I’ve been fortunate because I’ve insisted at my testing jobs that I have two or even three monitors and I have never been turned down.
Having more monitors leads to better testing because:
More supported browsers are open and easy to compare
More sessions are open so it is easier to see cause and effect problems
I can have more than one or even two or three users signed in with different permission levels.
Even though there are still several browsers open, I can also have some terminals open for grepping through log files and taking notes or logging bugs.
In the world of web application testing, this is the difference between noticing something and having it obscured behind too many screens where you will never see it. In fact, if you have to switch to another tab or swipe to another space on your Mac YOU ARE TOO LATE. The bugs are gone and laughing at you beneath your fingertips.
We live in a time of “do more with less” and, let’s face it, testing is usually where the money dries up. It is easy to fall into the trap of thinking you will be seen as greedy if you ask for another monitor, but it makes the difference between being a good tester and being a great tester. If your team really wants you to find all the bugs, they should make it possible for you to SEE THEM. Believe me, they will crawl across your screens faster than you ever thought possible.
How do you ask for more monitors?
The three situations I’ve encountered from easiest to hardest (and naming no names):
If you see a monitor no one is using, just take it and hook it up. This is exactly the time to ask forgiveness instead of permission, and the truth is some places really don’t care. Hook it up, find some bugs and mention it to your boss. On the positive side, if no one is using the monitor, you’ll be putting a resource to use that would otherwise be wasted. At the worst, you might have to give it back and endure the “we have an allocation spreadsheet” talk from I.T., but if you can show someone the benefit before it’s taken away, you’ve got your case for more monitors started.
Ask in your job interview – when you are negotiating for salary is the time to ask for any special equipment you will require. Ask for a laptop and not one, but two additional external monitors so that you have a total of three. If the person on the other end balks, be sure you understand exactly why and be very clear that you will not find as many bugs if they don’t honor your request.
Here is a vga to usb adaptor I’ve had success with in the past. The company seems to update their drivers for Macs more quickly than others vendors.
If you work at a place where developers (even developer interns) automatically get two monitors, argue that everyone doing cross-browser testing should get an extra too. I’ve actually done this before and credit the group I was working with and the boss I was under for taking the argument to his superiors. In this type of workplace, however, where management isn’t too dear with what they give to developers to get their job done, it only stands to reason that they would want those doing testing to have what they need too. If you need to make a case, you might want to get some developer collusion going and have one of them test with you for an hour or so. That’s usually all it takes for people to judge the effectiveness of more browsers.
If you work at a place where no one has an additional monitor, it is possible the assumption will be made that you are setting a dangerous precedent which means everyone will want more monitors. Go ahead and laugh but there are places where you will hear this. If you happen upon this situation, strap on the guns and BE THE WICKED TESTER.
If better testing is dangerous, then I wanna go down in flames.
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!!
In the past month, I’ve had a few different people who are not testers ask me about filing bugs. It always makes me happy when people ask me this question, because knowing how to write up a good bug is the first step towards getting it fixed. The more effectively you write bugs, the closer you will be to getting your problem taken seriously and addressed. Since computing is now so ubiquitous this goes for everyone from developers interacting to sales and marketing people or even end users interacting with support.
Write an effective title
In this day of scanning, bug titles turn into what everyone will look at the most in a bug. In Tracker, they turn into story titles which is the most visible element of a story. It’s worth taking extra time to make sure the title is as succinct yet as informationally dense as possible.
Take pains to write clear steps to reproduce the problem
While some bugs are worth capturing even if you cannot reproduce them, it always helps the person on the other end to understand your bug if you include clear steps to reproduce. I make them painfully obvious, for example:
1. Open the Firefox browser
2. Open this URL: <URL would go here>
3. Click on the big red button
If you can identify elements by their CSS class or ID, that is a great way to make things clearer, if not, do your best to describe what you see.
Include environment information
Which Browser, which Browser version and which Os?
If you are on a device, the name of the device (Asus Transformer) and operating system version will clarify what hardware you are using when you see the bug.
Expected Behavior vs. Actual Behavior
Explain what you thought you would see vs. what actually happened. Often a feature works as the developer or product manager expected or you have uncovered an area of behavior that was not thought about when the feature was designed and coded. For this reason, it is important to separate what you expect from what actually happens.
It is good to include screenshots if something is noticeably wrong. Personally, I prefer a carefully written description as it gives me insight into what the author of the bug was thinking.
Manage your tone of voice – don’t write mean bugs
It can be easy to sound irate or self-righteous in a bug. Testers know this. After you’ve completed writing it up, read for and remove any overly emotional language. This goes for obvious phrases such as, “THIS MAKES ME WANT TO SLIT MY WRISTS,” “WTF” or “Really????????” and also more subtle language. Such language will not get your bug fixed any sooner and will only alienate you from those who can fix the problem. (I have learned this lesson from experience and have written a few mean bugs in my time.)
Don’t assign priority if you can help it
There is a difference between the severity with which a bug impacts your usage of a system versus the priority with which a developer will be able to fix the bug. While it’s well withing range for you to right about how a bug has impacted the application you are using, you are not the one in charge of the development schedule.
Anyone who works on finding and writing better bugs deserves a pat on the back so, here, let me give you a virtual one: <Marlena pats you on the back/>
As a tester of web applications, I’ve become familiar with how web pages are constructed and rendered through the browser. Firefox Add-ons provide a great set of tools for doing this and have been a mainstay of my testers toolbox for quite a while. One of my jobs as a Mozilla employee was to show others how to use some of these addons.
Below is a chat I had a while back with a contributor (name anonymized for privacy) about Firebug and Firepath, 2 addons that I use all the time for getting information about the elements, called locators, on a webpage. We use these all the time in Selenium testing and it is a taste of what I’ll be talking about in a free webinar I’ll be giving for the Software Association of Oregon on Tuesday, May 15 from 12:00pm to 1:00pm. Registration is free :o)
In addition to Firebug and Firepath, I’ll be talking about an add-on developed at Mozilla, Mem Chaser and some browser functionality that started as an add-on but has made its way into the Firefox browser, Tilt.
marlenac Have you used Firebug before?
olivier No i have heard of it
olivier Its a firefox extension
marlenac You’ll want to install 2 addons: Firebug and Firepath into firefox
marlenac I use both of these all the time to help with the locators. I’m also looking up a good link on CSS for you.
marlenac This blog post explains some of it and has a bunch of other links for working with Selenium and CSS: http://blog.reallysimplethoughts.com/2010/10/12/a-quick-introduction-to-css-locators-in-selenium/
olivier How does firebug help with locators?
olivier Does it generate the expression?
marlenac It allows you to inspect web pages so you can see what the locators are.
marlenac If you’ve got it installed, choose an element on a web-page, right click and choose “inspect element”
marlenac As an example, I’m on the homepage for addons: https://addons-dev.allizom.org/en-US/firefox/
marlenac If I hover the mouse over the big “ADD-ONS”, right click, and choose inspect element
marlenac It will split the window of the browser and show me the html of the page at the bottom.
marlenac the line starting with “<a title=”Return to the Firefox…” is highlighted.
marlenac Just above that is a css class “site-title”
marlenac If I want to select the link at “ADD-ONS”, the selector will be “.site-title > a”
marlenac We can check that this is correct with Firepath.
marlenac In the Firebug pane, there are several tabs at the top. “HTML”, “CSS” and further over is “Firepath”
marlenac If you paste in “.site-title > a” without the quotes, it will highlight the element for you.
marlenac It’s pretty great!
olivier Thx so much u just made my life easier
marlenac I know!!!!!! We’d all be suffering without Firebug and Firepath!!
marlenac A couple of tips.
marlenac Use .blah to specify a class name
marlenac Use #blah to specify an id.
marlenac Use the “>” to get to a child element.
olivier What if there are many child element?
marlenac You can keep going with it.
marlenac or if there is a list, you can use “nth” to specify the 1st, 2nd, 3rd.
marlenac This post has a great explanation of that: http://saucelabs.com/blog/index.php/2010/01/selenium-totw-css-selectors-in-selenium-demystified/
marlenac I’m just finding an example in our code as well.
olivier I think i get it
olivier I will ask i get stuck
olivier Thx again
marlenac You’re welcome :)
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.)
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.
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…
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”
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:
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.
If you’ve ever wanted to see what it looks like to switch tests from the Selenium-RC api to the Selenium-Webdriver api, this github pull request will give you a very good idea of the changes that have to be made.
There are a few reasons why these tests are a particularly good example of what happens.
A few highlights and bogans:
There’s much more to this change, but I’m dog tired and it’s Friday. Knock yourselves out with that pull request!
Special thanks to the team that wrote all of that code, Teodosia Pop, Florin Strugariu, Zac Campbell with special guest-star appearances made by Dave Hunt.