Experience of a Quality Assurance Intern at Gravity Forms
By Isabel Doran
Published January 3, 2023
We have already discussed what it takes to prepare for a software/technical internship in my first blog post. Once all my learning preparation was complete, I began the role as a Quality Assurance (QA) intern here at Gravity Forms. It is this experience that will be the topic of this article.
While each company has a different process for onboarding and designated job structures, we’ll take a peek at what my experience was like joining the GF Product team. Throughout this article, I will walk through my first few weeks at Rocketgenius and discuss some specific topics included in the onboarding.
From there, I will highlight my fundamental tasks, as well as a side project which focused on connecting APIs through a new add-on. Lastly, I will wrap up with a few key takeaways from my first few months as an intern working on Gravity Forms.
With this insight, I hope to break down walls and uncover some unknowns of what to expect throughout a tech internship. Let’s hop in!
Onboarding: A Glimpse of the First Couple Weeks
Product Development Onboarding
Joining the team, I was entering as a Junior Developer with plenty of room to grow. Although my position would focus on Quality Assurance activities, it was essential for me to complete the Onboarding for Developers program. As I consider myself an avid learner, I was excited to complete the 20 Modules included in this program. My first step was getting connected to all the communication and project tools that were used daily. Some of these included:
- Fellow: Used to help keep track of all and any meeting notes you or your team members may have. Also, integrates seamlessly with Google Calendar.
- GitHub: Used to connect current development work to team members and project planning integrations.
- Slack: Our tool for daily communication, which integrates well with a few of our project tools.
- Zenhub: Used to create and plan future projects and specific work.
Modules: A Peek Behind the Gravity Forms Curtain
Next, it was on to the modules. Each of the modules ranged in both length and topic. While some were related to the company goals and process/guidelines, other modules were tailored to specific development topics. As I completed each module, I would walk through an overview with each developer on the team. With this walkthrough, I was able to ask direct questions and meet my team through relaxed one-on-ones. To mention a few, modules included:
- How We Work: Our History, Mission, Values & Guidelines
- Full Product Immersion (crash course of all our products)
- Gravity Forms Architecture
- Processes/Set-up for Automated Testing
- Accessibility & Security
- Add-On Frameworks
- All APIs
- Certified Add-Ons
After completing the modules, I sincerely appreciated the ability to learn technical skills that would be used throughout my work and peel back the curtain on what Rocketgenius was like as a company. As I read through the History, Values, and Inside Jokes that supported GF, I also worked alongside each Product team member. With this, I was able to develop a feel for what the next few months would look like.
Quality Assurance Onboarding
Once I had completed the Onboarding for Developers, it was time to move into Quality Assurance (QA) onboarding. For this, I followed along with our lead QA Analyst, who walked me through a typical pull request that lives in Github. Generally, testing would begin in this sort of manner. Based on the given feature or add-on that we were testing, there were set qualities to keep in mind, although there was an overarching checklist that we would follow for most cases. Now that I had understood what I’d be testing, I needed to learn,
- How these requests came about
- How I’d test this on my computer
Incoming Issues
As mentioned above, our team uses Zenhub to organize and plan current and future work projects. This system made it easy to follow, as each task gets created as an Issue. Issues get created for each new feature (enhancements) or bug finding throughout already developed work. Task issues can range in size and are estimated based on potential work time.
For example, a brand new enhancement may have a 20 or 40 Estimate, showing it would take a good amount of work from numerous team members. Contrastly, a bug finding may estimate a 5 or 8, as there is typically less work and time spent on these issues. Once the task issues have been developed and worked upon, the QA team would receive a corresponding pull request, PR, for testing.
Testing Time
Once the QA team received a PR to test, we would begin to test locally. To do this, I used Local by Flywheel. While we would create some local sites that included all of our add-ons, I would also form new local sites for each PR to ensure the proper connections and branches attach in each test case. From here, we would follow along with the previously mentioned checklists and specific to-dos per each test case.
If there were any funky findings or buggy features, the QA team would alert the developers promptly by adding notes and comments directly to the corresponding PR. This process would continue until each PR could be thoroughly tested and return no errors or funky displays.
First Rounds of Weekly Meetings
One of the aspects that helps the Product team flourish is the way in which they work – in a sprint structure. When first joining the team, this was a new work style to learn, but I grew to love it! The sprint is set up across a two-week timeline, opening with a sprint planning meeting on the first Monday and a closing retro to walk through what tasks closed throughout the sprint by the second Friday.
Given the number of issues to be completed in a sprint and working as a remote team, maintaining the daily sprint check-in is essential to keeping the ball rolling. This daily check-in was one of my favorite things because not only did it give you the ability to check in with your remote team regularly, but it also allowed us to check in with our projects on a 24-hour basis, which helped reduce confusion time and alleviate blockers, as we’d say.
The Meat & Potatoes of the QA Internship
QA Experience: P.R.s, Smoke Tests, & Beyond
I joined the team at the beginning of June, and within three weeks, I was off to my own QA devices. While there was plenty of flexibility to learn and grow at my own pace, I appreciated my lead QA, as she never made me feel like my questions were too big or too small. This room for growth helped me to feel comfortable throughout my work, and I successfully reviewed and completed about 50 PRs by September.
In addition to PRs, we also worked through testing products by Smoke Testing. This process was a slightly different testing procedure from PR’s, as smoke testing would include a detailed overview of the new features + existing Gravity Forms features. Once smoke testing was approved and completed, the enhancement is ready to ship out. From here, the Operations and Marketing teams step in for the next steps on the given feature.
API Project
While on the Product team, one of the side tasks included 10% projects. These projects help to fine-tune development skills and push forward smaller projects within the company that may not fit directly within sprints. Given I was a fresh junior developer, one of my projects came from the developer’s onboarding modules regarding APIs. Outside of my testing time, I worked alongside one of the developers to create an API project. This project focused around creating an add-on with API capabilities. The capabilities included,
- Collecting form entries from one site and displaying them on another site
- Allowing the user to select which form entries get extracted from
By the time I ended my internship on the Product team, I was proud of the add-on I had created. When first introduced to this project, I was unsure how I would approach it. But with help from the Gravity Forms documentation and guidance from team members, I was able to work my way through.
Attending Customer Time
Lastly, in addition to 10% projects, another side task the Product team undertakes is Customer Time. During Customer Time, each member can interact with and help our customers directly. One session of Customer Time is about two hours long. Through using Help Scout and guidance from our support team, one can read through past customer interactions or begin working on live time requests.
Given I had not previously spent time interacting with customers, I found the time spent in Customer Time invaluable. Not only was I able to directly help or affect a customer, but I also gained a different perspective on using the Gravity Forms product. Some questions or concerns from the customer’s perspective may never have crossed a developer’s thought process. Through having this exposure, Customer Time helps to provide big picture understanding of Gravity Forms and its different use cases. Which, as a developer, can only help the future projects and features which will come down the line.
My Key Takeaways
How I Stayed Organized
Thankfully, my QA lead had set up wonderful documentation, including checklists and specific what-to-do cases for potential testing setups. I would also try staying organized by creating a personal PR/smoke testing spreadsheet. This included columns for:
- Dates PRs Began & Titles
- Checkpoints for sending in notes & comments
- Checkpoint for reassigning to next step
Once a given PR or smoke test had been approved and completed, each row would receive a simple strikethrough. As for staying on top of my daily check-ins, I created a daily check-in template in my notes app. I make sure to fill this out at the end of each shift. This template included the following line items:
- What have I completed since our last Standup?
- What will I be completing before the next Standup?
- Am I blocked by anything?
While it may seem tedious to note each task completed daily, I found it to be a nice brain dump so that once I shut my laptop for the day, I wouldn’t have to worry about forgetting small tasks from the previous day. Especially with QA testing, there will always be moving pieces, probably multiple at a time, so it’s worth jotting down each task at the moment.
Learning How to be Part of a *Virtual* Team
Being part of a virtual team can feel isolating at times. But that highlights the importance of communication! As previously noted, daily standups are a great opportunity for this regularly scheduled communication.
Additionally, when considering remote work, over-communication can be appreciated. Whether you’re checking in with your lead at the end of the day to go through completed tasks or attaching a note to a PR for a newfound bug: adding details and maybe even a photo or video for a detailed explanation helps to cut down misunderstood messages.
Lastly, as many of us have seen with texting, the tone you intend may not always be perceived on the other end of a device. So communicating with patience and understanding first goes a long way.
Again, Keep Learning!
To close out this second article, let’s connect back to the first blog post in the series. Again, the idea of learning is always at the forefront! Throughout my first few weeks on the Product team, I spent most of my time learning their processes and how their team functions. I continuously learned about the new features I would be testing and how to put together an API-based add-on. To help supplement this learning, I read through GF documentation, carefully tailored questions in Google, and reached out to those directly on my team. I hope this idea hits home that you will ABL (always be learning)!
Lastly, I had the opportunity to meet and chat with the Women in WP Podcasters. Here is a link, if you are interested in listening to our talk about WordPress and Transferable Skills.
Be sure to sign up for our newsletter, so you can be notified when future articles are available…
If you want to keep up-to-date with what’s happening on the blog sign up for the Gravity Forms newsletter!