And So It Begins

Well, I finally bought a URL to further identify my name. I have been debating purchasing because it meant a few things. First, it means that I am out an entire $48. Second, it means that I should probably post regularly so that the identification is worth it, and continue making the name known. Lastly, it could add some credibility or validity to what I’m saying, though I’m not sure it always should.

The Journey

sailboat-37725_640

If you’ve read my original post when I began to write, you might remember that I have wanted to write a blog for a few years. You may also remember where my QA Blog journey officially began earlier this year. It started as a goal for myself, as part of my career development. I wanted to be more engaged with the QA community, and I also want to be a teacher/mentor of the QA role, training people to be more analytical, to think outside the box, and to test like they’ve never tested before.

These desires led me to start writing a blog online. I had no expectations of followers, or active readers, or really anything like that, but to fulfill a career goal, I needed to be somewhat active with my writing. Once I got a decent amount of pieces written to make it worth mentioning my blog to people, I figured it was time to make it real by purchasing a URL.

The Choices

I came up with a few different ones and tossed them around in my head while also presenting them to some friends and co-workers. I wanted to be sure that whatever I bought, I would be happy with for an extended period of time, which right now is just year to year. A few of my ideas were:

  • qaingtheworld.com
  • testingtheworld.com
  • lifeofatester.com
  • qalife.com (although taken, there is no real site)
  • mckelveytesting.com

I heard back from some people, and it was pretty much an equal consensus, they all liked lifeofatester.com. This was originally my second favorite option right after qaingtheworld, but I assumed that URL was a lot harder to read and say to people, so it quickly became a secondary option.

The Questions

I have had a few people ask me some questions about what is next, what do I want this to look like over the next few months or years, and my answer right now is simply, I don’t know. I have dreams of certain things happening in my career, but right now I’m just going to continue expanding my knowledge of the QA life, try to become even more analytical, and take that where I can in my future.

Don’t Send the Test Emails in Prod

I was recently scanning through the Messages on my Qdoba app and saw one of the messages at bottom was a test email. It was titled test and the subject was test. This got me thinking about how we test and when it’s especially important to be careful.

Qdoba

It seems like an easy concept… don’t add test data to production that the customers might be able to see, but in practice, this may not always be the easiest thing to remember. There are a lot of testers and lots of testing, any one of them could add data to prod.

The first is functional testing. As a functional tester myself, when I’m in a testing environment I will add fake data all day. I’ll add some names, run some reports, and importantly, ensure all emails work correctly. Sometimes you may have to test sending an email to all of your clients at one time, but this test email should never be sent in prod, so be sure that your data is set up so that if it requires a test, you send with an actual email ready for your clients.

Secondly, there can be a lot of service testing or automation testing that could run and accidentally send that test email. In a lower environment, we’ll have tests running all the time to ensure things are working. However, it’s important that these tests either don’t run in production, or if they do, that again they use real data that is OK for the clients to see.

Whenever you test, be sure to future-proof everything so that your customers don’t randomly get a test email that you can’t undo. It looks bad, causes confusion, and may even turn into a day of customer support phone calls that no one wants to deal with.

It’s not a hard concept to test, but in practice we need to always remember the importance of production data.

Finding Bugs is the Cool Thing to Do

I was presenting in a meeting and a handful of times, I said something like “I was able to find this bug and it was really cool” or “it was cool when I found this”. In a laughing manner, someone attending the meeting asked one of my developers if it was cool to them that I found those bugs. Part of me felt bad while the other laughed along with the crowd.

Spider Squashing

If you’re like me, then you believe that spiders are literally hell on earth. There are few bugs (in southeastern Wisconsin) that compare to the spider, especially those big black ones with thick legs, strutting around your house waiting to attack you while you sleep. After screaming like a girl, there is nothing more satisfying than taking a giant boot and obliterating that spider and all its worth. It feels so good and reminds me of the man that I am, that I protected my family from the evil Dr. Spider.

bugs

Software Bug Squashing

Finding a bug may never be a cool thing to a developer. It may point out their failure, or an area that they didn’t think of. Some bugs are so obvious that they should have never gotten past the gatekeeper, and over to us in QA. But it happens. As a QA analyst, finding the bug is very cool. Not that we like pointing out failures in others or anything, but rather as a team, we are working together to make the best product available. Finding and fixing any bug is actually an accomplishment because it means our users will not find the bug, or be bothered by it’s existence. They will not see the bug crawling around in production and scream like a girl when they see it. How is this not a cool thing?

Additionally, I am merely giving my developers an opportunity to be the big dawg on campus by obliterating the bug and becoming my rescuer, although they don’t seem to agree how cool it is that I found the bug.

So maybe it’s not COOL, but it is beneficial, and for that, there is no sorrow in finding and reporting a bug.

When Testing Requires Throwing the Computer Out The Window

OK, so maybe not exactly throwing your computer out the window, but I recently saw a post on LinkedIn (here) that got me thinking about how I sometimes think and feel about testing software. The image is posted below, and we’ll do two things. First I’ll describe how I relate testing to this image. Secondly, I wanna hear you caption this photo in the comments.

3b9ea7c0-90d7-45ba-9257-3735d6c9eab2-original (1)

Throwing Your Computer Out the Window

There are a few times a week that I want to throw my computer out the window. This can be for a handful of reasons.

Literally

Sometimes it gets late in the day and a bug is still crawling around your fingertips that you just cannot catch. You know you saw it, you know that it’s a bug, and that by catching it, you might get some immediate or long term recognition for it, but you just can’t seem to reproduce it. Every time you try, there is nothing wrong, everything works, but you know what the reproducing steps are, it just won’t happen this time.

I get the same feeling anytime I have a bug that I am able repro time and again, and then I call the developer over to show them and I can’t do it. The ole “works on my machine” or “nothing ever goes wrong when you’re here, can you just stand here”. It drives me nuts when I cannot repro a bug in front of the developer.

Lastly, anytime I log in to test, and it’s just a bad day for bugs. It happens, there are days that are inevitably buggy, and I can’t get through the workflow without a bug blocking me. Then when fixed, it causes more and more bugs. This repeats itself all day until the end, when you realize how little you accomplished today, because every time you went in to test, there was a bug blocking you.

Metaphorically

So maybe throwing the computer out the window isn’t the greatest test step in my test plan, but I say it to describe an example of testing and then losing power, or connection to the internet, or your computer just decides to blue screen. These aren’t really scenarios we test, maybe ever, but it’s always something to keep in mind when testing. What if I’m right in the middle of something and the site crashes or an unexpected error occurs. Do I have to start all over from the beginning? Did the site save any of my progress? Maybe a good alternative is to break up the workflow into segments that save on each step. This might prevent a large amount of data to be lost.

This could happen more on mobile devices when transferring between networks as you walk in and out of buildings and connect to WiFi. I wrote about this testing scenario on Mobile Testing Limitations on a Desktop Computer.

Caption Time

If you don’t have a LinkedIn account, there would be no way for you see the comments on the photo. But some of the good ones were “Troubleshooting Windows” or “Windows just crashed again”, and even “Jim put his computer to sleep”. I want to hear if you have anything better? Comment below!

The License Plate Conundrum

The other day I was driving home from work, and at a stoplight, I noticed that the license plate in front of me looked a little different than I remembered others looking. I stared at it for a bit, analyzing it like I do all things around me, and realized that it was not in the normal format that I recalled others. Then I glanced at every other car around me and found that this car’s plate was in fact, different than all the other plates.

Before you continue, here’s a challenge:

WI recently released a new license plate format with their letters and numbers. Can you think of what it is? There are thousands of them already out there now, so you have definitely seen one.

Analyzing the World

All around us there are inconsistencies between similar objects and being in QA teaches us to find those differences. For some, this is a learned ability. It requires time and practice, and the desire to find the problems. For myself, this ability has always come naturally. I’ve always enjoyed the Spot the Difference books, or Hidden Objects in Highlights, or even What’s Wrong with this Image found in similar magazines.

The idea of consistency is actually a simple concept. Either the two pictures, sentences, or layouts are the same or they are not. It’s very black and white. But sometimes it takes an extra moment or a trained eye to find those things. The next time you are driving down the street or viewing the world, try to find an inconsistency between two objects that appear the same, but actually have a difference.

Game Time

I was recently working with some friends on building a fence for a community center, and their sign read like this:

Hours of Operation:
Mon – Fri: 8:00am – 5:00pm
Sat: 9:00am – 3:00 pm
Sun. 8:00am-3:00pm

How many differences or inconsistencies do you see in this sign? Believe it or not, there are three things that I would report as an inconsistency bug. If you found more than three, then either you’re wrong, or I will have to look harder!

For fun, let’s spot the difference. Find the single difference between these two photos.

SpotDifference1

Last one.

SpotDifference2

Would you believe me if I told you I found both of these in under 30 seconds? There is actually a secret to this, and has nothing to do with being in QA.

If you cross your eyes, so that each eye is looking at the opposite photo, the photos become blurry, but it’ll make one clear image in between them, that you can actually then look at and move around on. The difference will appear green and flashing.

Inconsistency Bugs

Sometimes these types of bugs seem trivial to log, or maybe even fix. So what if one page says “Log in” and the other page says “Login”? Or, should we care that the buttons are sentence cased in most of the site, but there is one page way over here that has a title cased button? What about when there is a pixel difference from the item next to it?

All these things can deter users from desiring to use your product. Think about the last time you were on a website, and noticed something slightly off. Perhaps you couldn’t quite place what it was, but it may have bothered you, or you spent time thinking of it, or if you’re like me, you went back to the previous pages to see if you are crazy, or to confirm that you saw the difference. Whatever it is, it wastes time for the user, and causes them to think twice about their workflow.

Even the tiniest of bugs can cause harm to the system. They might not be critical or severe bugs or cause data issues, but they could cause a hiccup in the user’s workflow, and therefore should at least be mentioned.

If you read my thoughts on Collaborative Testing, you’d find that a lot of these things can be caught during that process, and fixed very quickly, so that no bug even needs to be logged. This is the ideal scenario. However, if it’s missed then, but caught during testing, it is always something that should be reported and allowed a decision to be made, because you never know if your user will catch it, and what the result of that could be.

The License Plate

By now you’ve had plenty of time to think about what format the new WI license plates are in. But in case you can’t figure it out, here is one more clue:

AAA-123
AAA-1234
123-AAA
1234-AAA

Think about your license plate and if there are any plates from your past you can remember.

Just so you have the answer before you go, the new plates are in AAA-1234 format. This was because they hit the max on letters/numbers, and it was time to start over again.

What are your thoughts on those minor inconsistency bugs? Log them or don’t? Or, do you even see them most of the time?

Bonus points if you can identify the TV show that this post’s title is based around.

A First for Everything

The idea of writing as a QA analyst is actually a scary thing to me. Imagine your entire day spent analyzing someone else’s work, and then when you find a problem, you let them know about it and they fix it. Can you imagine the opportunities that will arise when someone notices an issue with my writing? Perhaps a page link won’t work, or my Contact form won’t send. Maybe I will spell something wrong!

The Goal

I’ve actually had a desire to write or blog for quite a while now. I’ve toyed with the idea in the past about a family blog with my wife, that each of us could attribute to, add pictures in, and post about things going on in our lives. This didn’t really take off as both of us were so active in Facebook, posting everything we wanted there. I had created two or three different blog sites for us to try out, and now they sit, stale and getting older each day.

Last year, the beginning of 2016, our CEO at Zywave, asked us to better ourselves, to spend time learning a new thing, figure out what can make us stronger, and find something to achieve that year. I picked up the guitar, learned a handful of chords, and did a lot of practicing live in front of high school students while we sang songs. Perhaps not the most ideal time to practice, but it has worked out alright so far, and now I am a year an a half into guitar, know a handful more chords, and am able to comfortably lead music and worship for the same group of students.

This year again, challenged with finding a goal that we can attain throughout the year. I desired writing as a goal, but didn’t feel I was ready quite yet in my career to impact anyone. So instead of this as a goal, I set out to re-familiarize myself with Service/Integration testing (it has been a couple years, so perhaps a post to come on that in the future). This was a bust, because in order to achieve a goal, there has to be a certain amount of desire, and unfortunately there was little to none. I installed Visual Studio and pulled down the solutions for testing, but upon opening them, realized I didn’t want to continue.

The writing thing kept coming back into my head, keeping me up at night or distracting me at the dinner table. What topics could I write about? What knowledge can I share with the QA community that they don’t already know? How can a three year QA professional better the practices already set out by years of experience? I had to change my mindset on the whole writing thing, and so got to a point where I am comfortable writing about my current knowledge and skill sets, with the understanding that there is still so much to learn. I am more excited about this than any goal I’ve had, because I have finally figured out what I want to write about and how to do it.

The Big Picture

I’ve been asked about long term career goals many times.

Where do you want to be in five years? How about ten years?

This thought hasn’t really scared me yet, because I am still working my way up the ladder. I know that I have a few years to go before I hit this “peak” in my career, where I must decide what step to take next. I’ve only recently begun thinking about what I’d love to do in my career long term, and since things can only be achieved if dreamed for, then I guess it’s time to start dreaming big.

I love to talk, there’s no doubt about that, and anyone who has known me for five minutes knows that I enjoy this. I also love writing, and feel that I can easily sit down for an hour or two and crank out a 15 page paper (experience from the school days). So what could I do to incorporate these two desires into one big, overarching career goal, with my QA abilities in the holster?

I’ve got it. I would love to teach what I know. I want to not only better myself and my knowledge of the human-computer interaction era, but I want to help others learn more about it as well. I want to write about my work, my talent, and my life, and how QA affects me, and I want to teach people how to be more analytical, how to use their logic in the face of technology.

I told a friend of mine at lunch the other day, the big dream. I would love it if I could continue to work at Zywave, and become a QA expert in the field, and then take my knowledge to other companies for speaking and training events. It would be my dream to be called or emailed one day, and asked to speak for a QA-con, or a local training seminar, or even a company who is just starting up their QA department, and needs an adviser to come in and help pave the way for their new analysts. I would work for Zywave, testing their software, but be a designated consultant for going out and bettering more people in their QA roles.

This of course, is a dream that may or may not even be possible, but is only achievable with hard work and dedication (and possibly a handful of other business support)!

The Final Thoughts

You ever watch Jerry Springer, and at the end of his show, he gives his final thoughts? What gives him enough industry knowledge in order to go on TV and share emotional, relationship, philosophical advice to the viewers at home? Is it experience alone, is it training, or is it just basic logic as it relates to human interaction?

I have a lot of great topics I want to write about, some of which I don’t have a lot of industry knowledge on yet, but I’m hoping that I can learn a lot through this writing process, and share some personal experiences that will help some QA professionals get better in their careers.