Followers
Heya, I'm Hanna. The local transfem puppy girl software engineer, rights activist, and security researcher.
here's a great bio, i really like coding and stuff and socializing with people online and contributing to projects
- Look for failure, not success. If you test expecting things to work, you will see them work. Ask "how could this break?" on every screen. A session with zero bugs found usually means the testing was shallow. - Testing produces information. You aren't certifying the app as correct. You report what you saw so someone can make a decision. A clear note saying "I didn't test X" is useful output too. - Use oracles to decide what counts as wrong. You need a reason to call something a bug. Michael Bolton's HICCUPPS heuristic lists the usual ones: does the behaviour match: - the app's own history (what it did before) - Tangled's image - comparable products (GitHub, Forgejo) - what the team says it should do - the user's goal - the product itself (other screens behave this way) - standards (a11y, HTML) If it's inconsistent with any of these, write it down. - Be curious, not scripted. Exploratory testing means you design, run and evaluate tests at the same time while you learn the app (the ISTQB definition). When something looks odd, follow it, even if that takes you off your plan. - Act like different users. Try a brand-new user with no repos, a power user with 200 issues, someone on a slow phone, someone who double-clicks everything, and someone using only the keyboard.- Look for failure, not success. If you test expecting things to work, you will see them work. Ask "how could this break?" on every screen. A session with zero bugs found usually means the testing was shallow. - Testing produces information. You aren't certifying the app as correct. You report what you saw so someone can make a decision. A clear note saying "I didn't test X" is useful output too. - Use oracles to decide what counts as wrong. You need a reason to call something a bug. Michael Bolton's HICCUPPS heuristic lists the usual ones: does the behaviour match: - the app's own history (what it did before) - Tangled's image - comparable products (GitHub, Forgejo) - what the team says it should do - the user's goal - the product itself (other screens behave this way) - standards (a11y, HTML) If it's inconsistent with any of these, write it down. - Be curious, not scripted. Exploratory testing means you design, run and evaluate tests at the same time while you learn the app (the ISTQB definition). When something looks odd, follow it, even if that takes you off your plan. - Act like different users. Try a brand-new user with no repos, a power user with 200 issues, someone on a slow phone, someone who double-clicks everything, and someone using only the keyboard.
DevOps/Infrastructure consultant with an interest in Nix and automation.
