Software Testing – Marlena's Blog

A Tableflip Guide: Transitioning from Tester to Developer

Writing code is power.

As someone who has found success as a software tester, I’ve long counted myself as one of the many people who “fell into testing.” I told myself over and over that I was content to be a “technical tester” and restrict my coding habits to testing scripts, test automation frameworks and tools. Nevermind that I kept having to prove my technical knowledge over and over again, once as a tester and additionally, as a woman.

Today, I consider testing (along with support) as the space I’ve been allowed to occupy in the power structure of tech. If you go to a testing conference you’ll find people talking about how you can stay in testing forever and how it is a great career path. I’ve noticed that, often, the testers who shout the loudest about staying in testing forever have carved out their own place in the power structure of the software testing industry.

Something else you will notice at software testing conferences is the long lines for the women’s bathroom or that people in testing talk about how it’s actually one of the more diverse areas of tech. Why is that? Hmm…I wonder.

Here’s another perspective on this phenomenon of testing being more diverse: tech has pushed women of all races and people of color of all genders into non-developer roles telling us that it’s because of skills, smarts or that our brains work differently. We’re told that our work is just as valued and necessary even though the pay is much smaller and prove it again bias means we will have to prove that we have skills over and over. I’ve now decided that the software testing career path is not so much about falling as it is about being squeezed into a corner and kept there.

Transitioning out of this has been a difficult, rebellious, empowering act also known in this year of 2015 as a tableflip.

A friend of mine who recently made a similar switch had this observation about it:

I hope that every tester no matter how long they have been in testing or how old they are considers whether they want, at some point, to try being a developer. In saying that, I understand that I’ll get 5 people telling me how they never want to code and love testing so much. If you are one of those people, have fun with that. This post isn’t for you.

This post is for testers who see that their reach could extend beyond testing into more areas of tech. In particular this is for women and members of all marginalized groups in testing who have likely ended up in the field due, in some part, to cultural bias. If you find yourself writing little scripts to help you do your job, learning how to write automated tests, or learning so much about the application you test that you are constructing api calls and looking at application code, please give yourself the gift of questioning how you could go further with your technical skills and that you might want to switch to a developer career path.

Before I share what helped me, it’s worth recognizing some of my own privilege. I’m a cis, white woman. I don’t have kids and I’ve purposely sought out jobs that offer work/life balance. That means nights and weekends are mine. I make a good salary and live in the tech hub of San Francisco so I have a good amount of access and a great network of friends. I did not, however, have the time or money to attend a bootcamp so you won’t be reading about that experience here. That doesn’t mean I think they are bad. It means that they are not an opportunity for everyone, even with a scholarship. Thinking the only way into programming is through a CS degree or a bootcamp is its own bias. There are plenty of us WHO ALREADY WORK HERE. We deserve our own bridge into developer land. That bridge is something I have found to be all too rare in the tech world. I hope that changes.

Here is some of what worked for me.

Attend community workshops

Here in San Francisco, there is always a meetup. I’ve been to Railsbridge, Girl Develop It! and some Women Who Code meetups. I suggest these as a first step because they will get you oriented and help you feel supported. Also, each has their strong points so attending different types of these meetups will help you figure out which workshop will be most advantageous at each stage of your journey.

Pick a stack and stick with it

Because I enjoyed Girl Develop It! so much and because I was surrounded at work by developers working in javascript all day, I focused on learning web development through javascript and React.js. Having been to some javascript conferences, I generally find the javascript community around the Cascadia.js conference and the Javascript/Node groups in SF to be very supportive and encouraging. Eventually I branched out to learn rails, but it helped my confidence to have a solid foundation in javascript, node and React.js.

Pick an editor and learn all of the shortcuts you can

Any developer you seek help from will want to sell you on using their editor. Don’t let them do it. Pick one and make them help you with that one. If you have a mentor relationship with someone in particular, it can be worth learning their editor, but the truth is that you need to pick an editor that feels comfortable for you and learn its ins and outs. This will keep you coding.

Keep learning the shortcuts in that editor, because being able to quickly navigate your code without thinking about it is only going to help if you are building something. Also, if you are asking questions or showing someone your code, it looks better if you are using shortcuts vs. mousing around and clicking. Trust me, developers will give you more respect if you use shortcuts. My favorite editor is pretty much anything in the Jetbrains family, particularly rubymine and webstorm. Sublime is also beginner friendly and used by many of my friends who are developers.

Find a workplace that will support you

I went through multiple jobs in my quest to switch careers and found that support varied from place to place. One thing I did find helpful was to be open about what I was trying to do, once I knew what that was. It could be that you decide to do this while you are working at a job that won’t support you. That happened to me. The only solution was to find a job that would support me. Although it sounds drastic, I found that once I was in a more supportive workplace, everything was easier.

Talk to a Career Counselor

This option is pricey and, sadly, not available to everyone, but I found it to be worth every penny. Tech is so broad and there are so many different types of developer jobs. This also helped to settle the question of whether this is really what I want and not just something I’m chasing because the developer job title is power.

[Mini-rant: Personally, I’ve found that so many people tell me I would make a great product manager and maybe that’s true, but the job that I do every day needs to be in line with my heart’s desire and not other people’s perceptions of my talent. Having worked with some brilliant product managers, I’ve seen what that work involves and I know it’s not what I want. Also, I suspect that women are often steered towards the role of product manager for reasons rooted in cultural bias.]

Talking to a career counselor helped me prioritize what I was looking for in a job and a company. As an example, I found out that I care less about being emotionally invested in the problem I am solving. I care more about how I am building software. This helped me shift focus away from companies building products to consultancies focused on pairing and TDD.

Build something

Once you’ve done some workshops and are comfortable with your editor, it’s time to build something! The thing doesn’t have to be particularly original or even interesting. In fact, you might simply repeat building something you’ve built in a workshop but give it a name-change or tweak. Lately, I’ve built several versions of the same rails app, but with a different name every time. Every time I’ve rebuilt it, I’ve learned something new or deepened my understanding in some way. At some point you will start thinking about building a thing you can release. This will help you when you start interviewing because it gives you something to point at and say, I built that.

Let other things go

I’ve just had about 6 months of not doing a lot of things I wanted to do. Once you are in the serious prepping for interviews stage, it’s time to Stop Doing Other Things. This is a painful but necessary step. Women are already pressured at every turn to take on more activities than we really have time for and to always be helpful and willing to sacrifice our time for someone else or their cause.

I found getting ready for tech interviews the ultimate excuse for taking a look at my responsibilities and removing myself from a lot of it. There were a couple of weeks when all I did was send out emails and talk to people to remove myself from responsibilities. It wasn’t fun, but it created the space I needed to proceed with deep prep.

Mock Interviews and Interview practice

I had former co-workers and friends mock interview me several times. In between, I would work on the feedback I received after the mock interview. This helped me strengthen and tweak what I was doing. In fact, since I focused on pairing interviews, it made me a better pair. Also, be sure to ask about what you did right. It is such a confidence boost to know that you have some things covered and don’t need to worry about them in an interview situation.

Don’t find a mentor — ask questions!

There is a general refrain I have heard over and over at different tech events: “find a mentor!” I wish people would say, instead, “keep asking questions!!” The truth is that you will need many people, some of whom will be more involved than others. Rather than explicitly looking for and asking people to mentor you, focus on reaching out with questions. You will need to practice and you will need to reach out and ask questions even if you are tired, even if you are shy and even if you don’t want to. At the other end of that reaching out, you will find people who will only half answer your question or people who prefer answering with their own hubris rather than the information you need, but you might, if you’re lucky, find someone who not only answers your questions, but will tell you to ask a few more. That is a mentor.

A good mentor will answer your questions and guide you in the right direction. A great mentor will be there for you many times in ways you didn’t even know you would need them. They will give you confidence when you don’t have any left and they will help you shape your career path in a way that best suits you. This is not a relationship you’ll be able to trivially go out and find just anywhere, but if you end up with one of these, thank your lucky stars and your mentor for it is rare and a true gift.

Don’t give up

There were so many days when I looked at my broken code and thought, “why am I doing this?” Especially if you are not at the beginning of your tech career, you will have some days when you seriously question this strategy of switching to developer. Currently, in San Francisco, there is an on-going parade of people marching through coding bootcamps and straight into jobs. This is discouraging to watch if you are someone who can’t afford to leave your current job for 3–6 months. Also, if you are older, especially in the Bay Area, it’s easy to look around and draw the wrong conclusion that development is for the under-30 crowd. Development should be for people who find it interesting and who are curious.

Curiosity is one of the most valuable skills a tester can have. In fact, I’ve told people for a long time that curiosity is necessary for great testing. The thing about curiosity is that it doesn’t have edges. This is the root of being someone who is engaged and who cares about what they do at work. If you are a tester and you are curious about where else you might fit into tech or where else you might find a challenge, you should follow that instinct and tech (and also other software testers) should be supporting you.

Feminism in the testing bubble

I’ve described myself as a feminist for years and, for many of those years I didn’t take too much time to stop and think about what that meant to me. My definition was fairly straightforward and one that I’ve seen in many other places. Feminism meant equal rights for men and women. My definition didn’t go much further than that.

In my earlier days of blogging, I didn’t particularly want to write about feminism. To an extent that’s still true. There is a tax for people who are part of any marginalized group. The tax requires that you will spend your time and energy not on the actual topics you care about and want to write about such as software, but that you will spend time and energy defending your participation in the space and your right to be there. The tax is so far-reaching and insidious that you will end up paying before you even realize what’s happening.

Payment comes in many forms: your influence, showing actual emotions on twitter, a boss’s anger, exhaustion from explaining yourself (again) and then there are all of the requests people make of you to teach them because they don’t feel like finding answers for themselves. Eventually you become #thatwoman who has opinions on feminism. This turns you into a “go-to” whether you want to be or not.

There was a time when I was willingly paying all of these various forms of tax. I’ve done organizing, participated in “visibility” efforts and written about feminism. At the end of it, I found myself exhausted and needing to focus on my own career rather than continuing to feed the testing community with all of its various requests.

I largely disengaged from the testing community a few years ago because I’m pushing my own career in a different direction and it is taking all of the energy I have. In the meantime, I’ve paid attention to what has been happening in tech around gender and diversity outside of testing. For the most part, I focus on listening and signal boosting other people because, as a straight, white, cis woman who already has a tech job, I have my own share of privilege.

Through all of this listening and signal boosting, my feminism has grown and changed. It has outpaced my old definition and is now anchored in bell hooks

Simply put, feminism is a movement to end sexism, sexist exploitation, and oppression.

I’m done arguing, debating and/or discussing the meaning of quality, but I don’t think we talk enough about feminism, what it means to us, how it touches our lives and what it looks like in our communities.

The testing community, in particular, seems to operate under this two-headed shadow of a certain leader with mysoginist tendencies coupled with other leaders who don’t seem to have an awareness of what is happening in tech diversity outside the walls of testing. (Yes, that is a challenge. I don’t mind if people communicate with me to tell me how wrong I am about that, just don’t expect me to give you a cookie.)

One thing I’ve learned in this new world is that if I am part of a marginalized group, it is ok for me to push back on taking responsibility for fixing things. It is ok for me to voice a frustration or call someone out and leave it at that. I don’t have to write tons of articles for different testing publications explaining myself. I don’t have to be the one giving talks about this. In fact, by not doing these things, it leaves space for other voices. I’ve noticed that there are some great new voices in software testing who are paving the wave for even more change.

My hope is that people in software testing reach outside of the testing bubble for influence on multiculturalism and inclusion. Prove me wrong. Show me that you are learning and listening. I am not the person who will say to you that my opinion is the only one and you should blindly follow it. We’ve had enough of that in software testing.

Resources:

The Ada Initiative

Quiet Ladies, Wadhwa is Speaking Now

Feminism is for Everybody

AlterConf

Model View Culture

Do the simplest thing first

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:

When you are writing a new test…do the simplest thing first.
If you have something complicated to implement…do the simplest thing first.
If tests are broken…do the simplest thing first.

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.

My role in the new world of testing

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.

The Fun
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!

The Baggage

Now, let’s examine the rest of what comes with a career in testing:

You will be seen as an also ran.
Developers (or management that doesn’t work with you day to day) will see you as not that smart or technical unless you get a chance to prove them wrong.
There is significantly less opportunity for promotion, especially as “testing departments” get smaller or go away completely.
Even if you learn how to write code, it’s assumed you will only ever work on test code and that your code will be shittier.
You will have far less decision power.
You will be paid less.

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.

—Eleanore Roosevelt

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.

If you do testing, you need more monitors.

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.

Flaming Skull (Photo credit: Tortured Mind Photography)

How’s it going with Tracker?

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!!

Writing bugs if you are not a tester (or if you are a tester and would like to review)

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.

Screenshots

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/>

Webinar with me: Using Firefox Add-ons for testing

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”
olivier Kk
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.
olivier Kk
marlenac the line starting with “<a title=”Return to the Firefox…” is highlighted.
marlenac Just above that is a css class “site-title”
olivier Right
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”
olivier Kk
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
marlenac Cool!
olivier I will ask i get stuck
olivier Thx again
marlenac You’re welcome :)

CSS & Web Performance – Awakening the speed demon

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.

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…

Isolating a performance bug

Image via Wikipedia

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:

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.