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.