Tales and Advice from a QAE

Quality Assurance is an invisible and often underrepresented part of software development. It's also an excellent place to start with software engineering! Support Me on Ko-fi

[beben-eleben]

For future reference.

[mollimassacre-deactivated201408]

Thank you.

[fuckyeahifightlikeagirl]

For those who would ever need it. -C

[qa-engineer]

Process is progress!

When you’re the only person on a QA team, life can be hell. 

Setting up tools, getting your environment set up, understanding the current team process can seem impossible. And, on top of that, instead of a steady release process developers are throwing everything against the wall. But, if your team isn’t willing to put up with a change in process, get help from leadership or find a new team! Something needs to change with your change management system. Here’s how you figure it out. 

Step 0: What problems are you trying to solve? It may seem unlikely, but all stakeholders are trying to change and achieve something with every release. Design wants to see their designs come to life. PMs want to release features and fixes in a timely manner. Developers want to ensure that their releases are as solid and unbreakable as possible. QA wants the time and tools to test. 

Gather any other specific concerns. Make sure that you’re talking with all employee stakeholders. 

Step 1: What are some possible solutions? Your way may not be the only way. Discuss with your manager the current process, your findings, and what changes you can make to address these. Is your work load unpredictable? Schedule release dates so that you know when work is coming! Everything delayed? Help PMs (and your career) by becoming SCRUM master. 

Present your solutions with your manager and mentors, and ask for their support. And document the process! 

Step 2: Figure out your audience Who do you want onboard with your idea? Who do you want feedback from? Do you want to start this process with a small team, or does this need to be company wide? Should this process be driven by individuals, or managers? 

Step 3: Present! Present your ideas in whichever forum is best. Congratulations! You’ve done the hardest parts!

Step 4: Review Take any feedback you’ve been given, and restart the process. :) 

[qa-engineer]

Managing backlogs

BACKLOGS! 

Where all good bugs go to die. How do you manage a backlog that’s existed since before you’ve been employed? Here’s a quick tutorial!

Step 0: Define your backlog What should your backlog be? Should there be more than one?  Make sure that every issue in your backlog is ticketed. Make sure they’re all in the same repository. Make sure you’re only looking at items pertaining to your team. 

Step 1: What are the issues? Meet with the product manager(s) and developers to figure out how they feel about the backlog. Is it too large to surmount? Are the tickets not prioritized? Is the company only focusing on new features?

Step 2: Set some goals! Reduce the backlog by closing duplicate tickets. Create a new work flow so that everyone knows when tasks are complete. Close all tickets older than and without comments for 1 year. The possibilities are endless!

Step 3: Get help! You didn’t make this mess, and unless everyone is aware, it’s just going to get worst. Host a meeting and have the PMs, engineers, and other stakeholders help you to trim this backlog back! Don’t forget to quantify your backlog ahead of time!

Step 4: Review the results Did you quantify the backlog ahead of time? Good! This is easy, now. How many tickets did you start with? How many do you have now? How many items were prioritized at the beginning of the meeting, and how many now? Does this still need more work? 

Present your results to your team and your manager. You’ve just helped out the whole company. :D

[qa-engineer]

STARTING OUT: Defining priorities

I’m the first person on my team. What should I start with?  Depending on your skill level, what your company does, and how large your engineering team is, there are several things you may want to get done. Here are some ideas! Define Priorities Define the priority definitions for your company. These should apply to test cases, features and bugs. There are no standard definitions for these, but here are some guidelines.  P0/Critical- These are issues that are out to customers NOW, and cannot continue for another moment. Sound the alarm, everyone should drop what they’re doing and focus on fixing this as soon as possible. 

P1/High- This isn’t out to customers, yet, but this fix or feature MUST go out in the next scheduled build. You may drop less important tasks to make sure these are fixed/implemented. 

P2/Medium- this may or may not be out to customers, but this shouldn’t remain unfixed for very long. If this can’t get into the next scheduled release, try for the next one. 

P3/Low- this is isn’t great, but it isn’t very important. Not many people will encounter this, or it may not have much of an impact. Try to schedule this sometime soon. This is a good onboarding task for a new engineer. 

P4/Trivial- This is nice to have, but isn’t necessary. Do this as a passion project, or to onboard new engineers.  Look up some industry standard priorities for ideas, and always involve your team. Some examples to look for inspiration:  Facebook’s Unbreak Now! Google’s priority definitions

[qa-engineer]

How do I improve my relationship with engineers?

If you are having a tough time with your engineering team partners, there may be a couple of reasons why. Always ask your mentor or manager for hints on how to improve, but here are a few places to start. 

The engineering team feels you’re taking up too much of their time.

You have questions. And you should! But maybe the developers or other members of your team don’t have time to answer all of them as soon as you have them. Try to limit your questions to their “office hours” (time specifically set aside to help others), schedule an appointment with them, or ask asynchronously before in person, via email or company messenger.

The engineering team is not available to you. 

With a large enough team, you might not even SEE the developers. Try to reach out via email or company messenger, if appropriate. Or, ask if you can be present in kick off meetings, stand ups or planning to build a relationship with them.  You can also make sure that your emails, messages, test cases, plans, sign off docs, and bug reports are as detailed and understandable as possible.

If that’s not possible, reach out to someone in the engineering org to mentor you in a skill you know they have that you want to get better at. If all else fails, try again in 6 months or at a smaller company. 

The engineering team doesn’t like QA as a whole

YIKES! This can happen for a number of reasons. Work with your manager, your mentor, the engineering manager, or HR depending on the circumstances.  Your manager- Discuss with your manager what pressures the developers are perceiving coming from QA. If communication is broken, logging tickets, gathering metrics, and getting sign off may feel like blame. Come up with some strategies with your manager/lead first.  Your mentor- if your mentor is on the engineering team, they should be able to tell you why the engineering team is hostile to QA. Ask your mentor what you, personally, can do.  The engineering manager- If your manager hasn’t been able to help, or if you’re team’s efforts are not improving the situation as much as you’d like, it’s time to get the engineering manager involved. Either your manager or you should ask what the engineers dislike about QA, or if QA is even the issue (sometimes, it’s just tight timelines!). Whatever the stressor, the engineering manager should be able to pinpoint what’s causing the friction, and/or coach their org on how to be better coworkers.  HR- if your manager and the engineering manager are not concerned with the hostility or passive aggression between your teams, it’s time to talk to HR. Let your HR representative know who you’ve alerted, what actions your team and the engineers have taken, and what the consequences of those actions were. Let your rep know what your ideal fix and relationship is. 

The engineering team doesn’t like me

I’m sorry. If it’s not a discriminatory issue (if they aren’t being unkind or avoiding you because of your race, sex, religion, nationality, age, weight, etc), you may be able to work on your relationship with your team, yourself. Talk to your manager, engineering manager, and members of your team for feedback on how you can improve. If it is discriminatory, contact HR, and start brushing up your resume. You deserve better. 

[qa-engineer]

How does QA experience translate to other jobs?

Experience in quality assurance translates frequently to other software jobs, as well as jobs outside of the software world. Here’s how some of the skills you will learn and develop on the job can help you in other fields. 

Complex task management is great for project management (PM) or team product management (TPM).

If you are able to work your way to QA project lead (with or without the official title), you will be handling and tracking a series of complex and varied tasks. You will also likely be leading meetings, delegating tasks,  and will likely have gained rough knowledge about how long it takes for your team to complete each milestone of a task (or know who to ask to get those estimates). This job involves a lot of planning and collaboration. 

Writing sign off documentation is great for Release Management You’ve worked with your team or teams a long time. You know the people to contact to sign off on different parts of the release, you know who needs to be in the room for kick off meetings, and you know when to gently remind and when to actively pursue teammates about deadlines. This job is more people management and getting everyone to collaborate. 

Scripting and writing test cases is great for Software Development You’ve learned how and what to test with automation, but now you want to build your own applications and programs. It’s extremely likely that you’ll be able to work with your team to navigate over to software developer or software development engineer in test. You can transition by submitting code (which you may have already been doing) and doing code review. If there is no room for developers on your current team (unlikely) you can create personal projects and share them through your website, or contribute to open source on git. 

Mentorship is great to transition to manager.  All of that mentorship experience helps you prove that you can help your teammates overcome any problem. If you’re working on roadmaps and leading the team in planning for the future, you may be able to transition to Lead or Manager. 

[qa-engineer]

What types of testing are there?

There are several types of testing, and several ways that testing can be completed. Some are easier to understand than others, and some require much more technical knowledge. Here is a(n incomplete) list! A/B testing Do our users like change A or change B? Usually, this is done by percentage; there may be more than two variables. 

Accessibility testing This is a sub category of testing that includes both making sure that accessibilty tools work with your software, that the UI is readable by those with visual disabilities, and that disabled customers can opperate your software. 

Automated testing Any testing that is done programmatically

Battery testing Does this app drain the battery unduly? 

Compatibility testing Which devices can the app run on? Does it run reasonably well on all supported devices?

Connectivity testing How does the app work slow, limited, or no connectivity to the internet or cell network? 

Functional Testing Functional testing is any testing regarding the function of the application or program. UI testing, accessibility, unit testing, and many others are types of functional testing. 

Integration testing Does the app work well with other apps? Ex: can I easily connect to Facebook or twitter? Can I use the device camera? 

Internationalization testing Can the app's language be switched without affecting the design or usibility of the app? 

Localization testing Will a user in another country be able to understand the dates and prices? EX: YYYY/MM/DD vs DD/MM/YYYY vs MM/DD/YYYY OR 10,000 vs 10.000 vs 1,0000

Low Memory test How does the app work on a device with low RAM or disk space? 

Manual testing Any testing done by a human being through direct interaction with the software

Monkey testing randomly tapping and pressing buttons in the app

Performance testing How long does it take the app to load from closed? From in the background? How long does it take to load a new page or flow?

Privacy testing Can the app reveal a customer's information? 

Redlining Does the app conform exactly to the specifications the designer asked for?

Security Testing Can the app be hacked or reveal company information?

UI testing Would a customer be able to get to and operate all of the features through the visible interface?

Unit testing What is the smallest possible test for these feature or function? EX: If an app multiplies the number of circles (N) on the screen by two for every time the user taps, the following tests may be run (depending on the functions written): that N when number of tap events is 0 is one; that the number of circles visible is equal to N; that (on a tap event) N = N*2; and possibly more!

Usability testing The app works as intended, but would a person who didn't design it understand it?

[qa-engineer]

What experience is transferable?

Every job necessitates some level of skill. Here are some ways you can prove your skill for a job in quality assurance, as a tech, tester, or entry level engineer.  Organization and planning

Have you written lesson plans, detailed experiments, or otherwise written clear and specific instructions for others to work from? This can help prove that you are able to write test cases.  Have you followed written instructions to complete a task? Double points if those tasks were vague. This can prove that you are able to perform the steps needed to perform a test case.  Have you ever done simple scripting in a programming or scripting language? This can prove you’re capable (and willing) to pick up simple automation. 

If you have any programming coursework, this is a boon in any entry level QA job. 

Have a specific skill you want to demonstrate? Just ask!

[qa-engineer]

What do I need to be entry level in Quality assurance?

Like many jobs in tech (and any place where start ups hire half or more of the workers) there are a number of titles which describe the same job, and a number of jobs described by the same title. I’ll be using (fairly) standard language for Silicon Valley, but if you’re unsure, match the description of the job with the skills needed bellow. 

Quality Assurance Tech/Tester (QAT)

Testers and techs must be able to : 

understand and follow written directions exactly. 

recognize visual and logical bugs 

excellent written and verbal communication skills

Testers and techs can level up their careers by: 

writing clear test plans for small features or bug fixes

collecting quality metrics

identifying hard to reproduce bugs

learning to script in a programming language

Quality Assurance Engineer/Lead Tester (QAE)

Engineers/Testers must be able to: 

do all of the QAT tasks excellently

write clear test plans for features and releases

write clear test cases from mocks, technical specs, prototypes, and existing features

collect and define quality metrics

track hard to reproduce crashes and bugs in an analytics tool

know how to script in a programming language, and be willing to learn another

Engineers/Lead Testers can level up their careers by: 

Mentoring other team members

“owning” release testing for a platform

becoming an expert in one or more platforms

working well and closely with developers and PMs

identifying user experience issues (confusing flows) before implementation

Software Development Engineer in Test (SDET)

SDETs must be able to: 

Write tests in an existing automation framework

write functions in an existing automation framework

mentor software developers in how to write tests in an existing automation framework 

know one or more programming language, depending on the existing framework

SDETs can level up their careers by: 

creating their own automation framework

“Owning” the maintenance of an existing framework

“Owning” multiple automation frameworks

Setting up automated tests to run automatically

Mentoring QAEs, junior SDETs, and others in testing

You may have noticed that these don’t all feel the same level of difficulty or require a lot of prior knowledge. This is true, and common in software engineering (and it sucks). However, you can use existing experience to qualify for “entry level.”  I’ll talk about that in an upcoming post!