Should I Involve My QA Team in the Early Stages of a Software Project?

We, at SOLTECH, understand that the process of developing software has many challenges. Requirement gathering, meeting promised budget and time constraints, navigating unfamiliar business processes, building a team to produce a specific product, the list is extensive. One of those challenges is when do you start the testing process?

When faced with a project that can be expensive, time sensitive and demanding, the last thing you want is to stare down an extensive list of bugs come Quality Assurance (QA) time. Not only can this increase project time and costs, but it can also increase your anxiety level. However, your software project doesn’t have to get to that point.

Over the last twenty years, the team at SOLTECH has worked on hundreds of projects. Like life, not everything goes according to plan 100% of the time. However, that experience has allowed us to refine our process all with the goal of delivering amazing custom software. One of the things that we’ve seen work well in reducing that scary bug list is involving the QA team in the early stages of any project.

The typical software project or software company will bring in their QA team towards the end of a project. Mostly at the point when the software is built and ready to be tested. However, just because this is the norm, it doesn’t mean that there isn’t a better way.

This article is meant to help you understand the benefits of including the QA team as early as possible in the SDLC (Software Development Life Cycle) and understand how they can help in each phase of the SDLC so they are most effective.

The Problem – When do we start testing?

Many people have a very linear perspective when it comes to testing software. They think of the basic SDLC:

• Step one: get requirements.
• Step two: design the software.
• Step three: code the software.
• Step four: test the software.
• Step five: deliver the software.

This line of thought appears even when using sprints in an Agile methodology. The only difference is that each of these steps may happen within each sprint. It makes sense, right? How can you test something before it’s even been produced? This philosophy leads to the idea that the project doesn’t really even need Quality Assurance involved until the software is mostly developed or half way through the first sprint. On its face, that looks like a great way to save on labor cost for the project. However, what this philosophy actually can do is increase the risk, cost, and timeline of any project. An increase in any of these factors can be devastating to a project. The client will lose confidence in the team working on the project, and the ability to provide what has been promised.

It’s critical to minimize and avoid any of these outcomes. The best way to do that is to get QA involved during step one.

QA needs to be involved from the very beginning

I’m sure you’ve heard the stereotypical definition of what a software tester does: “They try to break it!” While this may be one of their most enjoyable parts of the job, it is also the most expensive because if they can break it, it will need to be fixed and that takes time and money.

When QA gets involved early in the process, there will be less bugs and less ways to break the software come testing time. The sooner a bug is identified the lower the impact on risk, cost, and timelines.

Let’s think about this for a minute. As an example, if there is a conflict in the requirements that is discovered during the design phase, the impact of correcting that defect is minimal. You simply get clarification on the requirements and correct the issue before you move to the next step in the process. However, if you take that same bug and it is not found until the software is delivered to the QA team, the impact can be enormous. You now have to get clarification on the requirements and you must also correct all of the work that has been done in development. Depending on the nature of the bug, it could result in rebuilding entire features.

Imagine building a car that requires a lot of different parts. You’ve completed the car and turn it over to the QA team. Immediately, they come back with an issue they detected with the integrity of the chassis. Apparently, the chassis cannot support the weight of the assembled vehicle. Because you did not involve the QA team from the beginning and allowed them to review the vehicle requirements you are now faced with a major issue of having to dismantle the vehicle in order to fix the problem.

Is it possible to find all bugs in the early phases? Of course not. However, having QA in all stages of software development will help reduce bugs and will give you a better product at the end. Let’s see how they can help along each phase of the project.

What Quality Assurance Does in the Requirements Phase

Gathering requirements is the first step in the SDLC process. There are many advantages of having QA involved in this phase:

• Product knowledge – Product knowledge is essential for QA to do their job to the best of their ability. They can spend their time going over the user stories, wireframes, and other documents to visualize workflows, understand stakeholder’s goals, and put together questions.
• Identify logical conflicts and discrepancies – As their understanding of the project grows with reviewing the project’s documentation, they may start to see logical conflicts and discrepancies early on in the process.
• Identify poorly defined or unaddressed elements – They may see “holes” in workflows, permissions, user roles, etc. They may also see a lack of definition to things like user validations, input validations, text field requirements, etc.
• Provide feedback on user stories – The bigger and more complicated the stories, the more difficult they are to understand. This makes coding and writing test cases more difficult. Based on their experience, QA can provide feedback and offer suggestions for user stories.
• Ask questions – As issues come up, they can start asking questions immediately or point out the issues that they see. As stated before, it’s much easier and much more cost effective to get these addressed before coding begins.

What Quality Assurance Does in the Design Phase

The Design Phase is where all of the requirements are pieced together to establish the specific workflows, user roles, permissions, etc. and to get a vision of what the final product should look like and how to get there. This process is much easier if QA was involved in the previous phase. Even if you manage to catch every possible issue in the Requirements Phase, which probably won’t happen, the role of QA in the Design Phase is still vital.

• They are a resource – Assuming they’ve been involved in the Requirements Phase, they can become a tremendous resource for the team members who are working out the design of the product. When they are unsure how different elements relate to each other, they know they can reach out to QA first before bothering the client or stakeholder.
• Writing the test plan in parallel to the Software Design – This is a great time to write the Test Plan. QA might’ve already identified many points of possible failure. As they see the actual design and the Development plan comes together, QA can design the Test Plan to follow the same flow, so they are always in the same place as the developers. This makes for a more streamlined project.
• Design review – Being able to review the design during this phase allows QA to validate it. QA can help identify any logical conflicts and discrepancies in the design before the developers begin their work.

What Quality Assurance Does in the Development Phase

During this phase, QA can begin testing. Even during the sprints of an Agile process, there are specific things QA can do to overcome issues and identify bugs before they become a major problem.

• Reviewing the User Stories in the current sprint – By reviewing the user stories, QA can confirm that the development is heading the right direction. They can also identify any divergence from the user path.
• Review and writing Test Cases for the current sprint – Reviewing and writing test cases is not only the best way to do the testing itself, it’s also a great way to dissect the requirements on a “microscopic” level.
• Being available and accessible to the Developers – The Developers are going to have questions once they dive into the code. QA can be available and offer assistance.
• Testing the software as soon as it is “Done” – When a developer finishes a feature, QA can test it immediately. However, time is of the essence since the developer might have already moved on to the next task.
• Communicating when QA considers the feature as “Done” – Letting the team know when they’ve determined that the feature is working as intended is really important. This lets the team fully focus on the next task on their list and lets the project leadership know the true progress of the project.

What Quality Assurance does in the Testing Phase

This is where everything comes together. Assuming QA has been able to test throughout the process thus far, this step should consist of working on things that may have been missed or not investigated due to time constraints in other phases.

• Edge Case Testing – All of those things that users will probably never do, now is the time to address them. QA can test inputs that will probably never be used, using the application for things it’s not intended to be used for, etc.
• Cross Browser/Cross Operating System Testing – Often, the software may have only been tested using the same browser and operating systems thus far. Additional browser and OS testing will be required during this stage.
• Bug Fixes/ Regression – If the developers haven’t had time to focus on bug fixes, they will now be in a position to do so. Much of QA’s time will be used to verify bug fixes and doing regression tests.

What Quality Assurance does in the Delivering Phase

Most of the testing during this phase is focused on User Acceptance Testing (UAT). This is when the client sees the finished product and gets to have a “hands on” experience with the product. The software development team is not only being judged by the quality and functionality of the product, they are also being judged based on the quality of the work they’ve done. A bad experience in this phase could result in the client or stakeholder being upset or worried about the overall project. What can QA do to help?

• Work with the team to address bugs found in UAT quickly – Most clients understand that it is impossible for a provider to produce bug-free software. That being said, what the client really looks at is how quickly the bugs are fixed. QA can stay engaged with the team and work with them to address the bugs that are found quickly.
• Are those actually bugs? – You’d be surprised how many of the UAT testers don’t have a good understanding of what the software that has been built is designed to do. Since QA has been involved every step of the way, they can serve as a subject matter expert in support of the client. When a bug is reported, they can validate it with the requirements before the rest of the team is alerted. The bug may just be a misunderstanding with the requirements or something that is out of the project’s scope.
• Exploratory Testing – While UAT is going on, QA can continue to do Exploratory Testing. This will assure that the overall project is successful.

When QA is involved early, you can rest assured that the project will progress smoothly. More bugs will be identified earlier in the project, requirements will be groomed more quickly, and money and time restraints can be met more easily. Most importantly, the client will be happy. SOLTECH takes this approach seriously and makes sure that our QA team is involved throughout the process. If you would like to learn more about our approach to custom software development and how we work in collaboration with our clients, please contact us to start the conversation.

Click here to fill out our contact form to start the conversation.

Ann Mooney

Ann Mooney is the Director of Business Development at SOLTECH, and has over 30 years in Sales and Account Management in the Technology, Telecommunications, and Medical Industries. Ann’s key specialties are building long-term business relationships, results-driven sales, and account management.

Ann joined SOLTECH in 2016, she works directly with SOLTECH’s clients to help find them the best technology solutions for their business. Ann utilizes her strategic leadership and proactive problem-solving skills to continually grow SOLTECH’s business and ensure excellent customer service.

With her years of experience in the technology industry, Ann likes to share her expertise to educate her audience on the enhancement of workplace productivity and growth through software solutions in her articles. Her insights offer advice on important considerations for creating custom software, including initial steps, development costs, and timelines, as well as the advantages of collaborating with a skilled software development team.