Testing, often mistakenly referred to as ‘Quality Assurance’ or ‘QA,’ is only a small part of ensuring quality for any platform during the Software Development Life Cycle (or SDLC).
MediSked has many testers spread across MediSked’s four platforms and their supporting architecture – Connect, Coordinate, Connect Exchange, and Portal, all of which are entrusted with being the last line of defense before a potential bug makes it to you, our end user.
We Must Be Very Quiet – We Are Hunting Bugs!
Testers are involved from the very beginning of the planning and spec design process, as our end-to-end knowledge of our platforms gives us insight into where a change needs to be made, as well as give us a heads up on what we should plan to test, or what parts of the testing can be automated to save time.
While there is no one-size-fits-all approach to what needs to be tested, we consider:
- The requirements – Does the solution fulfill the requirements? Does the solution actually solve our customers’ problem or make their experience better?
- The scope of the change – Are we fixing a specific case or are we making a sweeping update to a process or workflow?
- The risks
- The users – Who uses this? How will this change affect users who don’t use it?
The Tester’s Toolbox
Once testing begins, we pull many tools from our collective toolbox, including:
- Manual Testing – This is probably what you think of most when you think about software testing: someone hunched over a laptop, basking in the glow of their screen into the wee hours of the night, meticulously testing the far reaches of the platform on the hunt for every bug. While this is sometimes pretty on the mark, it’s only part of the bigger picture. You can also think of it as us doing what you do every day to make sure that your workflows aren’t being negatively impacted and that our improvements are working as designed and any bugs are effectively squashed.
- Automated Testing – Testers partner with technology to test the mundane but necessary elements of software more efficiently – like clicking on buttons, loading pages, or even adding data to test with. These tests are important but time-consuming, and free up our tester brains for diving more deeply into the platform.
- Regression Testing – We perform a predictable set of tests with every release (or change to specific features) to ensure that existing workflows and site features are working well with the new code. This can be performed at any step in the testing lifecycle, but most importantly as a ticket’s last stop before going to production.
- Smoke Testing – While this is a type of testing, this occurs right after we’ve pushed our rigorously tested code into the world for our users to experience, and we partner with our colleagues in other areas of the company. If anything is found during these tests, we work quickly to fix it so our users experience little to no downtime.
- Security Testing – This happens at many phases in a ticket’s lifecycle but is also critically important to protect the information on our platform. Threats are appearing and evolving all the time and it’s important to be proactive in finding and fixing them before the bad guys get a chance to deploy them.
“Why Didn’t Someone Catch This?”
The release has gone out, you can finally log back in and you start your day and there it is – a bug you’ve never seen before. How did this get here? Why didn’t this get caught?
As a user and a former customer support agent, I’ve seen on both sides of this question. The answer isn’t a simple one.
- Missed Case – Maybe a scenario wasn’t known or the data we had to work with didn’t include something, so a specific case didn’t get tested. You can bet it will be once we fix it.
- It’s not a bug, it’s a feature – Testers and Users alike love this one (*eye roll*). On occasion, a client may give feedback on a design after it’s released to better accommodate them. It’s not broken, it’s just not the best it can be yet.
- We Know – Also affectionately referred to as ‘Known Issues’ – It was caught, reported and for a multitude of reasons needed to go out as-is for the customer’s benefit. Improvements in these situations are prioritized and released as soon as possible.
So, as you can see, regardless of if the release goes out perfectly or if there are a few hiccups on the way there, there are many moving pieces and people involved in the process.
