The following is a transcription of the TestFlix 2021 talk by Anna Ondrish on How to Start A QA Department. Anna is eager to help you define and promote a quality mindset throughout all aspects of Testing by working with cross-functional teams to ensure that products built are delivered with the highest quality possible, on time, and within budget.
Connect to Anna on LinkedIn, by clicking here.
Introduction
Twice in my career, I have had the opportunity to be the first quality assurance analyst that was hired for a company and my role in both of those companies was to expand the quality assurance department after I got it all under control.
So, today I’d like to share with you some of my experience on how to start a quality assurance department.
Agenda For The Blog:
- Implementing a Test Case Management Tool
- Hiring Contractors, Full Time Employees, or Both
- Equip The Team to Work Independently
- Best Practices
Implementing a Test Case Management Tool
So, do you need test case management? Is that tool a priority? There are a lot of test case management tools to pick from and it all depends on what type of work you’re doing. It is decided by how big your company is and how many people are in your QA department along with how you’re going to scale everything. There was a lot to look into when I worked at Autoscribe, which was the first company where I was the first QA analyst. There we did not have a test case management tool. We used spreadsheets and word documents and they served their purpose at the time and that was fine.
In 2019, when I worked for Orsis as their first quality assurance lead we implemented Practitest and it was a great tool that helped keep us organized. It had a great dashboard and was integrated with our defect-tracking tool. so, it made testing very easy.
You can still always use a spreadsheet if you can’t get a test case management tool. Some companies just are not at a point where they can get tools. The agile manifesto points out that individuals and interactions are over processes and tools. So, you need to assess how many tools you are going to implement and the value of each one of those tools because garbage in is garbaged out. So, using a spreadsheet to start with is a fine way to go.
Contractors, Full-Time Employees, or Both?
When I started at my first company where I was the first quality assurance analyst, we went straight for full-time employees. We hired manual testers, then we hired automation specialists. I worked with offshore teams and then contractors, and later on, they came on board.
When I worked at Orases in 2019, I was a full-time employee, and we only had contractors, but we built a team and moved forward from there.
Equipping Your Team to Work Independently
It’s very important to work with your team members individually. As a group, I suggest that you have team meetings and one-on-one meetings.
Alternating every other week, I think it’s very important that each week you have a touch point with every one of your employees, contractors, and the people that report to you because especially now in a virtual environment where you can’t see the people and even when you were in the office it is a good idea to have that one-on-one time.
So, in your team meetings, you’re going to want to ask questions and then you’re going to want to listen.
You’re not going to want to say anything, just listen to your team members talk amongst themselves to hear what they have to say. Then you want to ask them, “how can I help you – what is it that I can do for you?”. You want to add value and then in your one-on-one meetings, you’re going to want to discuss individual contributions.
Develop individual work you want them to be working towards developing their own goals. Talk about areas of improvement for them and for the team while discussing the goals and then setting realistic expectations for their one-on-one time and for their team time because you know everybody has things that are going on in their life. So, just try to be realistic with your expectations.
Best Practices
The next thing and final topic that I want to talk about is best practices. Do we need best practices?
I call them best practices, but they are the kind of guidelines that the agile manifesto says. Working software over comprehensive documentation – do you need to write down everything or do you need to write down anything? You know what is the right answer.
See that stack of papers, I can tell you that a very long time ago when I first started out working, we used to write that much documentation. Not only did we use to write that much documentation but we used to rent that much documentation out. I’m so very grateful that we are not anywhere near that right now.
I think that it is important to write down some things that are important, like the test plans. If you work on multiple projects like at Orsis where we do custom software, writing a test plan for each project is having a template of a test plan. Then writing out that test plan for each project will help keep your staff organized.
If you have a test case management tool or if you’re using a spreadsheet that documented a repeatable process then you don’t have to keep telling a new onboard everything you want to be able to hand them.
When I say best practices, I want to make sure you understand I don’t mean a written document, it can be a workflow document as well. It can be a brainstorming document, it can be different types of documentation, doesn’t have to be like a word document only.
How do you use your defect-tracking tool? I think it’s important to write that down and that should be a repeatable process between yourselves and your developers. It can be any repeatable process that will help mitigate confusion.
You don’t want your team to be confused if they’re working on different software applications or if they’re working on one application or many different parts to it, we want to mitigate that confusion.
So, those are the areas that I want to talk about. I feel very passionate about them and I feel that there’s a lot of value in starting off a quality assurance department.
