Describing our Quality Assurance Process

Our QA and UAT process involves tailoring standards to the project itself. At a basic level we have two methods by which we QA. The first is an in-house QA process whereby we use members of our company to do the testing. The second is a third party utilization whereby we utilize an external team to do only the QA. We work with the client to understand which they might be more partial to and any trade-offs that might exist. 

In-House QA & UAT: Utilizing internal team members separate from the project itself we assign a designer, developer and non-technical team member as part of a dedicated QA team for the site. We have them run through a process that they are familiar utilizing for other projects on how and where to test for frontend, backend and other usability issues. 

Third Party QA & UAT: Utilizing a third party partner we have that only does QA as part of websites, web apps and mobile apps. Teams of 5-10 individuals run through their standard best practice checklists and communicate directly to us through our set up channels of feedback. 

Quality Assurance Discussion

Tony: Please describe our quality assurance QA process and how we ensure that they are provided with accurate and a quality end deliverable.  

Austeja: So, just like design and development, quality assurance I feel like is something that has standards, but is something that needs to be tailored to the project.  So, depending on the complexity of the project, we have multiple options available. This is something we can do in house and at a basic level ensure that your product is going to function and be evergreen, and we can provide enough support and maintenance to it throughout its lifespan.  But on the other side, as well, it’s something we feel comfortable delegating to a third party vendor, because it is a valuable concept to have someone do that does it day in and day out and has an entire staff allocated around it. And the reason for that is because depending on the complexity of the project, it might need 20 people on hand at that immediate moment to make sure we meet your deadline, and if we have the flexibility to scale that up or down, it benefits you as a client.  So that way we can respond to situations that may be urgent, or whatever they may be.  

Tony: I think a huge part of the QA aspect is it’s always nice to think of while our teams can do it internally, you want somebody that’s very well vetted, that has an expertise in testing these same type of applications over and over again, that isn’t necessarily familiar with the project.  Now, you have to give them standards, guidelines, so they know what they’re looking at, they know what the business goals are, but that’s what we run into a lot of, and again, we’ll do both, but I think in a lot of larger scale projects that have a bigger impact, we do lean towards the, maybe not the right terminology here, but “outsourcing it” to another company that does QA, that they can hold us accountable.  They can look through things, they can look through code standards, of course the frontend, make sure everything looks like the design was intended, and then test as users, hey, was I able to check out, was I able to select my seat, was I able to, again, during a kind of fake, I guess, rush, where a bunch of people, the tickets just got released and 10 people need to have them in queue and there’s only 5 tickets available, so I think that’s a big determining factor of how we work with the client.  Are there any big misnomers or nuances you notice when QA is mentioned, any responsibilities you feel are things like the client needs to know and we need to know to work together efficiently through that? 

Austeja: I think it’s something that has to be defined.  So, often times the client has an assumption of what QA means.  So, to them it may mean regression testing, make sure the app works on all browsers and all devices, and so on.  But in other circumstances it could be just user acceptance testing, so we know that your app should have the following capabilities, and does it do all of those things, and who is supposed to do it.  So, the biggest concept I think there is to make sure that the client and the vendor or the agency are aligned, so that way you know that your definition and my definition are exactly the same and we’re going towards  the same goal.  

Tony: Yeah, because the reality is in a lot of cases we might QA as an agency and the client might not actually get to use the feature function, it could be something very miniscule, an ability to edit a page, or publish a post, or change an author, and there’s a longer tail.  It might take them six months to get to that, and at that point it’s us feeling confident that we’ve covered everything and nothing was missed, so that when you get there they go, ah, this isn’t the way I wanted it. So it’s about having that communication and forcing yourself to understand, us to understand what the client really wants and what capabilities or bandwidth they will have to actually QA with us, or like, you know, besides us or after we do it.  What are you actually reviewing, because if your team is busy and you’ve got 600 things that technically you should look at, well, that might not be realistic, you might not be doing that, and so whether that includes some kind of documentation or outlining of a plan so that we feel confident and comfortable working with them.  

Austeja: Right, and I think within the industry there is a misconception that the client should never QA their own sites or their own apps, or whatever it may be, and while it is true that there should be a balance, the agency should make sure the development committee should make sure that they provide a QA support in that sense, but there is value to the client making sure that they proof and read and review and check their own product, because at a gut level they’re going to be the ones that know it best.  

Tony: Yeah, definitely.  Thank you.