Posted on by & filed under process, qa, Safari Flow, testing.

Dear QA-self from the past,

This is your QA-self from the future writing to give you a quick pep-talk. Right now you do not have access to the Website’s Database so information that could take you a matter of moments to obtain end up taking way longer because you don’t have permissions to a run a simple query. You also have no control over your Test Environment or what gets deployed to Production. You’re frustrated because changes you aren’t aware of keep sneaking in. The good news is that things will be opening up in the coming years when you start working on Safari Flow. You’ll have access to your Website’s Database and can deploy builds yourself to the Test and Production Environments as needed.

PostgreSQL Database

Being able to obtain information via a PostgreSQL database will really help give you insight into how data is stored and allow for more efficient testing. You’ll be able to verify that scheduled tasks are running and that the website and other systems are creating/sending data to each other as expected. With your new-found powers, there are many ways you can utilize the database in your testing.

Let’s say a user visits your website, creates an account, then purchases a product (maybe a Safari Flow subscription!). As these actions occur, the website could be sending information to the database, a customer account system, and a billing system. In the old days you would have to log into 3 separate applications to (not-so) immediately determine if each was updated. Today you can run one query and know that each system is on speaking terms. By running one query you can see that the CustomerAccountID and BillingID were safely created in the User table of the database. And what about that email that was supposed to be automatically generated at noon, but wasn’t? You can quickly see that the batch job stalled and didn’t run when it was supposed to.

You can also help determine the impact a change might have on existing customers and find Test Conditions much easier. What if there was a requirement to inactivate all users who created an account on August 5th, used Promotional Code ‘123’, and have the First name of “Fred”? At the place you’re at now, some Product dude probably gave you a list of users that should be affected and the Developer used that list to make the change. As a curious QA you begin to ask questions. How do you know the list is good? How do you know the Developer didn’t inactivate people that shouldn’t have been? Plus, good luck manually searching for these users in the Admin UI that stores the data in multiple places. In the future you will be able to confirm changes like this much more efficiently. You’ll first run a query given the criteria above and ensure the list is accurate. From here you can easily verify that the ‘Active’ column is set to ‘False’ for the applicable user accounts. Next you can run some simple variations of this query to get a list of users that should still be set to ‘True’ just by flipping the ‘=’ to ‘<>’. Wait……..why were people named “Alfredo” and “Frederick” inactivated? Could be that the List should have included these people or that the Developers script was looking for ‘%fred%’ instead of ‘fred’. Either way you just found a possible bug with the list or the UPDATE script much quicker than manually scouring the website’s Admin system.

Here’s a couple chapters to read to get up to speed quicker:

Deploying Builds

Currently, you don’t get automatically notified when a deploy to the Test or Production Servers are kicked off or completed so many times you have no knowledge as to what changes were checked in, who checked them in, or when/if the deploy even finished. Sometimes you aren’t even aware that a deploy occurred.  Plus certain developers like to sneak “minor” tweaks in without telling you so several changes go untested without any visibility or worse something breaks that you already tested during the sprint.

 Fast-Forward to now, where YOU deploy builds using Jenkins to the Test and Production Servers. You receive automated messages letting you know when the build starts, completes, or fails. You also get notifications each time code is checked in that includes who did it in along with a link to GitHub so you can see what files were affected. You now work with responsible Developers who add notes about what was committed so you’re able to reconcile each change and begin to plan what you want to deploy to the Test and Production Servers. Since the QA team clicks the buttons, we’re empowered to deploy code when we’re ready with minimal surprises.

Notification when code is merged to the master branch:

Notification as deploy occurs:


Jenkins Build Summary:

In the future you’ll actually be deploying to your Test and Production Environments multiple times within a Sprint! Here’s a chapter on that subject:


Your Future QA-Self

P.S. Your beloved Giants will actually win a World Series….twice in fact!

Tags: empowerment, pushing the big red button, qa, testing,

Comments are closed.