Confessions of a Software Tester: Rope of Sand
Explaining a life that is full of more than mindlessly clicking buttons
Assuming you didn’t accidentally land on this page, you are probably here for one of two reasons: either you are trying to understand more about Lightning Kite as a company, or I have directed you here instead of once again answering the question: “What exactly do you do as a software tester?”
Life as a university student is very social and for reasons unknown to me, asking for someone’s life story is an appropriate response to “I missed class yesterday, can I get the notes from you?” Maybe I’m exaggerating a bit, but I find myself answering a lot of questions about myself and one of the first is usually about work, which only leads to more and more questions. The conversation usually follows this general pattern:
Bob: Where do you work?
Me: At a software company called Lightning Kite, I do most of their software testing.
Bob: You must be a computer science major then.
Me: No, I’m actually a psychology major--
Bob: --so you must have switched majors then, or you grew up in a techy home.
Me: No, actually I was a farm kid… as I was saying, I’m actually a psychology major and this is in line with my career goals. (It’s at this point the cogs stop turning, steam starts coming out of Bob’s ears, and internal system failure is imminent… So I hastily add): there is a crossover between psychology and software called UX design, that is what I am looking into for a career.
Bob eventually comes to and replies with: Software testing—I had a friend that did that and she hated it, don’t you get sick of mindlessly clicking buttons to see what works?
Me: It’s not just that, in general I make sure everything is working the way it is supposed to, which involves a lot more than just mindlessly clicking buttons.
Bob still doesn’t have any idea of what I actually do, but I don’t always have the time to go into the details so hopefully the rest of this post gives you (and Bob) a better idea of what software testing entails.
I do have to admit, Bob was partially right about mindlessly clicking buttons to see what works. But that is only about 5% of testing any software; and if that’s all I did, I would hate my job. Also note, instead of writing this blog post, I would be filling out job applications. Aside from being a monkey with a hammer seeing how easily the rock breaks, I group everything else I do into 3 other categories:
Specification and Permission Tests
One of the first things I learned after I started working at Lightning Kite is that you can’t have too many people double checking the work as it is done. There are many, many reasons why a “completed” feature might not work the same for everyone or why it might need some additional work. This involves a lot more than just logging bugs; if possible there should be a reason given for why the feature needs changed, or the exact cause of a bug or crash. If an app is going to be used for travel, realistic data should be used when testing. Realistic distances should be used, allow enough space for long city names, and the map should be an appropriate size or it should scale to a variety of sizes. Filters should be useful and results should load in as little time as possible. I do spend a lot of my time tracking down bugs and crashes but there is a lot more to catch than just that.
Specification and Permission Tests
In a perfect world, software would be 100% planned out before development starts. Every workflow would be mapped, every design element would be sized and placed in the wireframes, and there would be a document stating exactly what each user should or shouldn’t be able to do. But then I realize today is not that day as I watch the fresh toothpaste fall into the drain before I can wet my toothbrush—just a sign that a large part of my day will be spent going over each of these things on every project.
Probably the most common mistakes I see with workflows is placing frequently used elements several pages deep and placing the stuff nobody cares about front and center on the homescreen. I discuss this more in the UX design section, but it is bad practice to force aspects of your app onto users. In the end they will use the app in the way that is most useful to them. Also, if there are actions or tasks they frequently need to complete, why not automate the process for them wherever possible?
Sizing buttons and images is probably the most difficult to plan for, especially on mobile. The size of phone screens varies greatly and making content display well for everyone is a bit of a process. Different operating systems and browsers can also affect how things look and work. Even a website that is beautiful and sleek on your desktop could be a total mess on mobile browsers. It is a bit tedious, but if you want users to be able to access your app on any platform, it needs to actually work on each of them.
Hopefully by the time I hear about a new project, there will at least be a comprehensive list of the different user types accessing the app. For example, let’s say the app is going to be used by every employee at an amusement park. Potentially, each type of employee would need their own set of permissions (or features that they can access). Maybe the guests would even be able to access certain information. You wouldn’t want guests to be able to change the open/close status of a food stand, and you wouldn’t want a food stand employee to see the messaging channel the security crew uses to communicate. With complicated software it is difficult to plan every instance ahead of time, which is why I am always watching for anything that doesn’t make sense.
The most basic principle of User Experience Design is that nobody but the actual users of the software know how the software will be used, or what designs are best. Hopefully the owners of the software aren’t completely disconnected from the users and have somewhat of an idea, but even then it is impossible for them to know everything. It’s even less likely that the developers know what the users need, so, research and talking to representative users are really the only good ways to get it right. Even then it may take several iterations to make the majority of the users happy. It is a continual process of thinking ahead to try and prevent design mistakes as well as using feedback to satisfy users.
What I just described is more of a high level process that brings to light the specifics for a single app or website. There are some basic principles that are usually good practice with any software. These basic principles involve removing frustrations and roadblocks, and adding elements that might help the user enjoy interfacing with the app.
I found a fun example the other day with a website I use for one of my classes: I created a new account and immediately had to sign in at a separate portal. 1st mistake, why wouldn’t the user just be logged in after creating their account? Then my username kept getting rejected and I noticed it was automatically capitalizing the first character of my username, 2nd mistake. But nobody in their right mind would make a username case sensitive right? Nope, I had to delete the first character and fumble with it until it didn’t capitalize it. 3rd mistake. All this frustration and I’m not even on the homescreen yet, and look at everything they put in my way of completing the task I needed to get done.
The last aspect of UX Design I will mention is based off of a psychological principle called the availability heuristic. Basically, this principle states that people will first use information that is easiest to access or immediately available to solve a problem or complete a task. Starting with the homepage, information should be provided and organized in a way that directs them where they need to be. Users should never have to “guess” what they need to do next. If you provide them with the right visual cues, they will intuitively know what they need to do, even if they are seeing the app for the first time.
Anyway, hopefully that gives you a better idea of what is involved with the software testing process. It’s not a perfect science and there is a lot that goes into “good” testing, but one thing is for sure - testing is absolutely vital to producing good software. Plus, it can save a lot of time and money in the end!