QA Meetups

I attended a quarterly QA Meetup in my area this week. Meetups are a great way to network and get some new ideas from specialists. I try to attend every one that I can, because I like the atmosphere of a life event. There is an energy that exists only when you are physically present with other people who share your interests. And I am talking about an event, not a class. In my opinion the only energy in most classrooms is one of stagnation. A life event, however, like a conference or a meetup is a different story. People all have something in common and want to be there. The presenters, for the most part, have more masterfully crafted their presentations, because they usually give that same presentation at multiple events. They speak about their subject because they are experts in their field so they are also pretty passionate about the subject. They also get to define their own criteria for their presentations so they are only saying things they believe.

A DevOps duo presented at this meetup about the benefits of working with DevOps as a software quality engineer. They were very excited about this subject. I could tell that these guys enjoyed using their skills to help out QA. It made me wonder if most DevOps specialists would enjoy this or if it was just these guys. Anyway, I’m going to discuss some things that I took away from their presentation.

Automation engineers or even developers should build utilities for manual testers to do their jobs easier and quicker. Some examples they demonstrated were a set of utilities to populate databases with lots of data. The one that I remember the most filled their database with information on moons from Star Wars. Which was pretty cool. I would have filled mine with questions from trivial pursuit.

These types of tools are particularly useful because it is high value vs cost to implement. Utilities like these are usually fairly easy to create and do not require the maintenance, configuration, and planning of automated tests because a manual tester is operating them as a tool for their own testing. And I am all for empowering manual testers because they are much more agile and intelligent than 1’s and 0’s. Humans are slower, however, which is another reason why building utilities like this are an awesome idea. Plus whoever makes tools like this will become a celebrated hero for anyone doing manual testing.

That being said, there are a lot of discussions going on around the internet about this subject. DevOps is not being leveraged enough by QA. There is so much potential there. Basically, try to use DevOps more often. Especially for things that they can do better than you. Like perhaps setting up your Selenium Grid if you aren’t using something like sauce labs.

I’ve learned that DevOps can do certain things 100 times faster than me because they spend their whole careers working on those areas of the industry that I never set foot in. It’s not worth the time that you’d spend trying to figure it out yourself. Swallow your pride or build up the courage or whatever you need to do to be able to reach out to the people in your organization that know the things you don’t. Double down on what you’re good at. And, hey, I’m not saying don’t learn new things I’m just saying weigh the costs of value vs time and resources and how much you actually want to learn a new skill. If you really do want to learn some DevOps, IT, development type skills, reach out to someone in those areas who likes helping out and ask for their guidance. I highly encourage you not to run around in the weeds of Google search when there are experts in your organization who can show you what to do or at least tell you what to Google. You will find that they will be more than happy to help as long as you are kind and don’t take advantage of their niceness. By the way, buying the IT guys a pack of Mountain Dew goes a long way.

 Anyway, back to more thoughts that were inspired by this meetup.

If you aren’t already, consider using your own database for storing data to compare against. If for example you need to have a set of control data that you are comparing against data produced by your tests. In summation, store info in databases if you can because a database is easy to manage and back up. Try and see if configurations for the product your are testing can also be stored like this. This way if the devs decide it’s a good idea to clear the test server you don’t have to reconfigure your test environments. Repeating steps for no reason is a waste of time.

That being said, get help from developers and DevOps to find ways to skip unnecessary steps in UI tests. If, for example, you have tests that use many of the same steps to set up a test case, but it doesn’t matter how they are created, substitute the UI part of those tests with straight up database injection or API calls for the data you need in the UI scenario you are testing. If you are testing, for example, that you can use a functionality that requires a new user or a new record and you already have a test that validates the UI process for creating a new record. Use database injection to create the record for you in the other tests so that you don’t have to waste time going through the UI steps of the functionality you’ve already tested. After all, you want to test that you can do something with that new record, not that you can create the new record in the UI. You already have UI tests that test that part.

Try to setup a way to be able to create environments, data, and scenarios quickly. They gave examples of using Docker. Which stores snapshots of environments in what is called a Docker container. They demonstrated setting triggers in GitLab that would create a Docker container and attach it to every transaction with the repository made by the development teams. This allows QA to be able to pull down a container and perform full test suites on a consistent environment that wasn’t constantly having new code merged in as they were testing. If something broke, QA could tie the breakage to a specific transaction on the repository. The DevOps duo also demonstrated the superb security of the current version of Docker, for all you haters out there.

     I had a lot of fun at this meetup. I encourage anyone reading this to find meetups in your area for subjects you are interested in. You’ll learn more about your field and will start building up a social element to it that will take your career to another level. If there is nothing currently in your area, I encourage you to get a group of your co workers who are interested and start your own meetups. Just remember not to set yourself up as the person who always has to bring the pizza.

What motivated me to start this blog

I have often had big ambitions that I never acted upon because I couldn’t get started. I would either start them and then start something else when the first task got too challenging or I would never start in the first place because I had no idea what to do first.

I have wanted to start a blog for awhile, because I love exchanging information with other people that improves my knowledge on a subject and hopefully adds to the knowledge of others involved. It’s also nice to express my opinion once and a while. When I’m talking with people face to face I like to listen more than expressing my own points of view.

No one wants to talk to the guy who wont shut up.

I feel like when I talk to some people I could replace myself with a manikin with a picture of my face on it and they would never notice the difference. I defiantly don’t want to be that guy.

There is a lot of music in me, though. I have a lot to say and a blog gives me the outlet to talk as much as I want about things that are of value and interesting to me and only people who also want to talk about it a lot will listen. So it never has to be this “Let’s watch how much we talk about software so we don’t bore the non-techies” kind of thing.

I also love Gary Vaynerchuck and his authenticity. He expresses the greatness of blogs constantly.

It has been a year or more that I’ve wanted to start a blog, but I couldn’t decide on a subject, or I “Didn’t have time”, or I didn’t know where to start, or whatever. I’d also been watching John Sonmez’s Simple Programmer channel on YouTube. I don’t know why I never went to his blog until recently.

I noticed there was a free email course “How to create a blog that boosts your career” I received 5 or 6 emails after this that got me from no blog to blog with several posts on in like 3 weeks.

It did not matter that I was busy. I workout everyday, have a full-time job and several other obligations every single day. The e-mails are spread out over 3 weeks. This course is intended to take you slow, make sure you do it right, and not overwhelm you.

If you take this course you will be helped in choosing a theme for your blog. Which will include a lot of reasons why you should just pick something. Perfectionism is a plague.

You will learn how to create the actual blog in 5 minutes. It really does take five minutes

You will flood your backlog/notebook full of ideas for future blogs. This is easier than it sounds when he talks you through it in the emails. He also helps you set a mechanism to ensure that you’ll never run out of ideas.

You will write a post! I especially like that he has you set a mechanism to make sure you keep writing more posts.

You’ll learn how to generate traffic to you blog. Because what is the point of making a blog if you don’t want people to visit it?

I highly recommend you do this if you want to start a blog. It doesn’t even have to be a software blog. This will work for any type of blog. If you lack motivation or don’t know what to do this is a great place to start. Best yet, it’s not gimmicky.

I will never put anything on my blog that is slimy or gimmicky. I am all about authenticity.

Quality Saviors not Quality Enforcers

Right off the bat people in your organization need to know you are there to make their lives easier. Too much of the time QA is used as an expletive or as a phrase people use in hushed tones because they don’t want to be annoyed or get in trouble.

Quality Storm Troopers

Years ago I worked for an organization in the medical industry. Quality assurance was to be avoided, because if they came calling your name you were in trouble. It didn’t help that they dressed up nicely while we were clad in dirty scrubs, or that they all seemed to wear loud high-heels on the hard, easy to clean floors. You could hear them coming miles away and it either sent you into a scared panic or annoyed-dread.

I’m telling you this because, very rarely did one of these folks get it. Finding mistakes and yelling at people was not in their job description. The job of QA and SQA is to validate the value of a product. In order to do that you must establish a relationship with people so they are comfortable with you. An open and honest relationship breaks down walls and gets people on your side. I remember we had temptations everyday to hide information about areas where quality was lacking because we didn’t want to be hunted down and interrogated by the Quality Police.

Establish yourself as an advocate who can save devs from being embarrassed by releasing buggy code and they will love you. Too often there is an us-and-them sort of thing going on between developers and SQA.

End this!

Start by becoming good friends with the developers. Talk with them. Eat lunch and discuss code changes and upcoming releases. Try to figure out what they are worried about without letting your worries creep into the conversation.

You can worry when no one’s looking. Don’t gripe! It’s the complaining and nagging that annoys people and gives QA a bad rap.

Good practice

At another place I worked, SQA was made up of mostly laid back people who did whatever they could to make the devs’ lives easier. This worked out great. They worked alongside the devs to solve problems. There was no us-and-them. The difference was attitude. The SQA team didn’t run around acting like their little world of quality was the most important thing on the planet. Instead, they had a culture of listening and acting on what they learned.

Remember, there are plenty of people running around and putting out fires. SQA isn’t responsible for fixing things, so don’t act like you are. Be the calming presence in the room. Your job is to warn others about big problems on the horizon that will embarrass them if they don’t take care of it. It’s their choice to respond. But trust me, after you’ve established yourself as an advocate and find bug after embarrassing bug in pre-production, they will start listening and you won’t be known as the Quality Police.