I mentioned in our previous Dev@DME posts that I would be covering the quality assurance (QA) process in more detail. If you haven’t already, I’d recommend visiting those prior posts to get caught up!
In short, QA in a software company is responsible for, as much as possible, testing the application to identify issues or potential issues across the program. They try different workflows and paths and click on buttons in various orders – including those that a normal user likely never would – just in case it causes some other unexpected behavior. As we’ll discuss later, a QA team, no matter how large or experienced, will never catch everything before it is released, but many bugs and other issues are caught and corrected before ever seeing the light of day due to the efforts of QA teams.
While we are a software company, we don’t look at ourselves as a traditional software company; especially when it comes to the importance of QA. The gravity of a critical issue is magnified for critical forensic software products which, if left unidentified, could prevent a missing child from being found, or cause other evidence to be missed. As a user, you need to be able to rely on the tools you use every day to recover evidence, and we take that responsibility very seriously.
As a part of that commitment, we brought on Sarah and Denny as QA engineers in late 2019. Don’t worry – we were doing testing long before they came on board, but with their experience we have been able to improve and formalize our practices to make them even better. Also, as dedicated resources, they have more time to test various different conditions and permutations than we did when we used other shared in-house resources previously.
Our biggest challenge comes from the very diverse and ‘wild west’ nature of the surveillance DVRs that you encounter every day. There are tens of thousands of makes/models of DVRs and many of them function in different ways. Once you throw in the different permutations of hardware (DVR, hard drive, cameras) and software configurations (system settings, recording options, etc.), the testing landscape gets very challenging.
While we will never be able to test every possible permutation of scenario our users will find when using DVR Examiner, we are working to build as wide of a process as we feasibly can. Even outside of QA, in the development team, we always try to make sure you as the user are made aware of unexpected errors. That way you can reach out to us for assistance and determine what the best next steps are. Given the importance of the evidence you are examining, if you are going to encounter an issue, it is much better to bring that to the forefront so it can be investigated properly.
In the next post, we’ll cover the processes we use, as well as how they have evolved over the years. Until then, thanks as always for reading and stay safe! Also, make sure you subscribe to our blog and newsletter to stay up to date!