The promise of NoCode is appealing in that it allows anyone to create web, mobile and native applications without having to learn a traditional programming language. Filling out a form and using your mouse to configure an application has an exponentially lower learning curve than learning how to write programs using code. However, it turns out that building applications has never just been about writing code and often coding is the smallest piece of what it takes to actually ship a successful application. One import component of software development (both for NoCode and traditional code) is Quality Assurance (QA) or testing. While some software development organizations employ dedicated QA people the job of QA often falls to the developer. Since NoCode projects tend to do be built by solopreneurs the job of testing more often than not falls on the developer. Unfortunately developers (both NoCode and traditional ones) tend to be bad at testing, especially their own work. The principles of testing are the same regardless of what type of application you are testing or whether it was built using code or NoCode.
The major reason why developers tend to be bad at testing is two-fold. The first reason is that they tend to prefer building over testing. Building produces things and has a tangible output. On the other hand, doing testing is often seen as less fun and not as interesting. The second reason is that developers tend to be invested in wanting their code to work and tend to subconsciously avoid trying to break things. They take the “happy path” when testing and they know what that path is because they built it.
The key to being good at QA as a developer is to set aside dedicated time for QA and to view it as a completely separate role. When you’re wearing the QA hat the goal should be to find as many bugs and issues as possible. Developers tend to want to fix bugs they know about but if you try to fix issues as the same time you are testing it muddies the waters. It’s best to simply keep track of the bugs you find and then after you find a bunch to take off the QA hat and put back on the developer hat.
As a general rule the following are good areas to focus on when testing.
- Boundary Testing: What’s the minimum and maximum values that you can enter for a field. This isn’t just entering -99999 into an input field but also testing what happens with the application when there are no records. Or what if there are 1,000 records?
- Cross Browser or Version Testing: If you’re building a web application then it’s a good idea to test with different browsers and different resolutions, including mobile and tablets. Tools like crossbrowsertesting.com let you try your application on many different browsers and platforms. If you’re testing native applications then trying older and newer versions of the application can be helpful.
- Specifications Testing: If you built your application according to a specification or according to a list of features then it’s often a good idea to go back through each entry and make sure the application behaves as described.
Using a tool like Trello to track bugs can be an easy way to separate out your developer role from your QA role. You can create a simple board that has columns for To Do, Doing and Done to track the issues you find during your testing. Categorizing issues as being improvements or bugs can be a good way to help triage issues and determine which items to prioritize.
Your mindset when doing QA can be an important factor in how many issues you find. If you go into QA with the goal of breaking as much stuff as possible and finding as many issues as possible that’s likely going to help you find more issues than if you go into it hoping that everything works as intended. Every application has bugs and either you’re going to find them or your users will. It’s often better for you to find them before your customers do.
NoCode Guides is a marketplace for finding NoCode developers and mentors. Get one-on-one mentoring on your NoCode application or post a project and receive proposals from our vetted mentors.