At 57Blocks, we have extensive experience conducting functional testing to ensure that features work as intended in various environments. In this article, we’ll explain our functional testing guide, referencing one of our client projects, Tokenpad.
Testing Principles
We have three easy to follow principles when testing.
- Start testing early; QA should identify critical bugs during the feature validation period on Dev, so that engineers have enough time to get them fixed.
- Be efficient; we try to identify 80% of the bugs, often the most glaring ones, during the first 20% of testing.
- Keep a record; knowing which areas of your product need more attention when your bugs are recorded and prioritized. Teams can then appropriately allocate time for bugs to be fixed, validated, and deployed.
Testing Environments
On a typical project, there are multiple environments, each serving a different purpose. Tokenpad has four. For each environment, we have different test goals appropriate for that environment.
Test Process
Below we detail the steps of our testing process (Tokenpad specific steps are highlighted in bold italics)
- Requirement analysis
Once product spec is ready, QA team will go through the contents, get questions answered/clarified. At the same time, QA team checks for any gaps between product spec and UI design. - Draft test plan & review with team
Write test plan based on our initial understanding of the product spec. Product manager, developers, and QEs review test plan together. - Draft test cases & review
Write test cases, including detailed steps and expected result. Product manager, developers, QEs review test cases together. - Before code freeze, test feature functionality on Dev environment
Validate new features and bugs. - After code freeze, full regression test on QA environment
Full regression test for all features, including UI, API, and smart contracts. Acceptance testing by stakeholders. - Smoke test and pool compatibility test on Rinkeby environment
Check previous pools are compatible with new release. To extend the coverage, a good practice is to create test pools and share to a group named with each release version. - Bug tracking
Bugs or issues found during testing phase are linked to a main Jira ticket for better visibility. QEs do initial analysis and report to stakeholders, so that major/critical bugs can be planned for hotfix. Minor bugs are moved to backlog. Our team decides which of these bugs to fix during our sprint planning meetings. - Post-validation on prod env
After features are released to production, QE team conducts a sanity check only to make sure environment is available and that features work, as plenty of tests are done in the regression testing phase. For pool validation, QE create one pool only to make pool fulfilled and tokens are finally transferred to contribution wallet.
Usually, QA has 2 days for testing after the code freeze begins. In order to find as many bugs as possible, we conduct our most intensive testing the first evening after features are deployed to QA. During the testing phase, 2 engineers are reserved for supporting and answering any questions raised by QEs. As a result, most bugs reported by QE can be fixed by the development team on the second day.
Sizing your QA Team
Because Tokenpad was a very complex product, it required more testing than the average product. Each investment pool involved many status transitions and fees calculations. Therefore, up to 4 QEs worked on testing the 2 roles, 3 transaction methods, and 4 management fee types on multiple browsers and devices for Tokenpad.
Lynn Meng is a Quality Engineer at 57Blocks.
57Blocks is a product development lab helping companies turn ideas into reality. If your company wants feedback or help, give us a shout at hello@57blocks.io
