Blockchain Architecture for QA

Blockchain is a distributed, immutable ledger that records transactions across a network of nodes. For QA engineers, understanding the architecture is essential because blockchain bugs are permanent — once a transaction is confirmed, it cannot be reversed.

Core Components

  • Nodes: Computers maintaining copies of the blockchain and validating transactions
  • Consensus Mechanism: Algorithm for nodes to agree on ledger state (Proof of Work, Proof of Stake)
  • Smart Contracts: Self-executing programs deployed on-chain (Solidity for Ethereum, Rust for Solana)
  • Wallets: Software for managing cryptographic keys and signing transactions
  • dApps: Decentralized applications with blockchain backends and traditional frontends

Why Blockchain Testing Is Different

Traditional SoftwareBlockchain
Bugs can be hotfixedSmart contracts are immutable after deployment
Centralized dataDistributed across thousands of nodes
Free transactionsEvery operation costs gas fees
Rollback possibleTransactions are irreversible

Smart Contract Testing

Common Vulnerabilities

  • Reentrancy: External calls before state updates allow recursive fund draining
  • Integer overflow/underflow: Arithmetic errors in token calculations
  • Access control: Missing permission checks on sensitive functions
  • Front-running: Miners/validators reorder transactions for profit
  • Flash loan attacks: Borrowing massive amounts in a single transaction to manipulate markets

Testing Tools

  • Hardhat/Foundry: Development frameworks with built-in testing
  • Slither: Static analysis for Solidity contracts
  • Echidna: Fuzzing tool for smart contracts
  • Mythril: Symbolic execution for vulnerability detection

dApp Frontend Testing

dApp frontends interact with blockchain through wallets:

  • Wallet connection: Test MetaMask, WalletConnect, and other providers
  • Transaction signing: Verify details shown to user match actual transaction
  • Chain switching: Test behavior when user switches between networks
  • Error handling: Insufficient gas, rejected transactions, network congestion
  • Block confirmation: UI updates correctly as transactions move from pending to confirmed
graph LR A[User Action] --> B[dApp Frontend] B --> C[Wallet Signing] C --> D[Blockchain Network] D --> E[Smart Contract Execution] E --> F[State Change] F --> G[Event Emission] G --> B

Advanced Blockchain Testing

Testnet vs. Mainnet

  • Always test on testnets first (Sepolia, Mumbai)
  • Fork mainnet for realistic testing with real contract state
  • Test gas estimation accuracy — underestimation causes failed transactions

Security Audit Testing

  • Formal verification of critical contract logic
  • Invariant testing (properties that must always hold)
  • Economic attack simulation (flash loans, oracle manipulation)
  • Upgrade mechanism testing (proxy patterns, time locks)

Cross-Chain Testing

  • Bridge testing: asset transfers between blockchains
  • Cross-chain message verification and finality differences

Hands-On Exercise

Design a test plan for an ERC-20 token smart contract:

  1. Transfer: Test transfers between accounts, verify balances, zero and max amounts
  2. Approval: Test approve and transferFrom, verify allowance tracking
  3. Edge cases: Transfer to zero address, more than balance, overflow scenarios
  4. Access control: Verify only authorized addresses can mint/burn tokens
  5. Gas: Measure gas consumption for common operations
Solution Guide

Transfer tests:

  • Transfer 100 tokens A to B: A balance -100, B +100, total supply unchanged
  • Transfer 0: should succeed or revert consistently
  • Transfer > balance: must revert with clear error

Security tests:

  • Reentrancy: attempt callback during transfer — must not allow double spending
  • Overflow: amount that would overflow uint256 — must revert

Pro Tips

  1. Test on forked mainnet — testnets do not replicate real-world contract interactions
  2. Always audit before deployment — smart contract bugs are permanent and expensive
  3. Test gas costs under various conditions — congestion can make transactions prohibitively expensive
  4. Verify every transaction detail shown to users — wallet phishing exploits misleading displays
  5. Test with multiple wallet providers — each has different signing flows and error messages

Key Takeaways

  1. Smart contract immutability makes pre-deployment testing more critical than in any other domain
  2. Security testing (reentrancy, overflow, access control) is the top priority
  3. dApp testing must cover wallet integration, transaction lifecycle, and blockchain state changes
  4. Gas optimization testing prevents failed transactions and excessive costs for users