Improve and split QA tasks

[pablomendezroyo]

In dappnode the QA has been always a pending task, and one of our weakest points where we must improve. Testing in dappnode is a hard task to accomplish, there are many different components and different from each other. For this reason, makes sense to find the most important functionalities in dappnode and assign them to a dappnode team member to be the main responsible of:

• Find the best way to test such functionality.
• Define the test process for other team members.
• Find ways to improve and automate the testing of the functionality assigned.

Core functionalities in dappnode to be assigned for improving QA (open to discussion):

• Accessibility and HTTPS: everything related to the different ways to connect to a dappnode (wifi, local, VPN) and the HTTPS portal.
• Repository:
  • IPFS: IPFS repository remote and local options
  • Ethereum: Ethereum repository full node and remote options
• ISO Installer and scripts: anything related to the way of installing dappnode (ISO and scripts). The installer repository is crucial in dappnode, someone needs to own it and give it some maintenance.
• Dappmanager CORE:
  • DNS
  • Auto-updates
  • package install flow
  • ...
• Stakers: stakers are right now the most important user profile in dappnode. We must polish and improve anything related to it. This testing process should be done from a user perspective.
  • Staker pkgs copies: execution and consensus clients, signer, and mev boost
  • Stakers UI
  • MEV-boost smoothing
• DAppNode packages

[CMTRACE]

Internal QA is awesome but I'd also invite the dev team to enable those of us with multiple machines to help testing.

Similar to enterprise rollouts, devs and those close to the project are not necessarily the best to provide feedback before a change goes live.

In my experience some of the best feedback comes from a group of end users given early access to new code.

If there is a way for end users to sign up for early release software on non-production machines with a private and direct line of communication to devs a lot of these QA issues will be discovered before a wider rollout happens.

This concept is very mature in windows enterprise end user environments and is known broadly as progressive deployments.

I'd propose a limited access discord channel and role assignment to capture a group of users and their feedback.

Having a detailed and structured test workflow as you have outlined here could be shared with the test group so they can check off elements as they work.

[dsimog01]

Hi @CMTRACE! Can you ping me on our discord server? We are glad our users are willing to give feedback on new features/packages. My alias is dsdiegosg there