There’s a couple of variables there that I’d find out about first:
why am I testing it? Is it for: security, certification, UX review, content checks, error handling, performance, reliability, availability, fun?
who am I testing it for and what matters to them? stakeholders, clients, managers, some team…
where’s this Login form: environment, interfaces, product type/s
what business domain is it in and how does that make a difference?
what state is it in?: is it a mockup, an UX interactive set of screens, half made, fully made; a whiteboard, uml diagram, a set of requirements or specs, brainstorming for build
previous knowledge: have I or someone else tested it before?
product status: is the product in use, is it a new product, is it in maintenance, feature in use, or new feature?
what access do I have(testability): to data, tools, interfaces, configurations, servers, or environments?
how much time do I have to test it? and what other constraints(is my manager telling me what and how to test and what outcomes he expects?)
…to be continued
It is a great point about establishing constraints and goals first, but.
If we are considering absolutely everything with no time limits I’d open my trusty updated MoT Test Heuristics Cheat Sheet and work my way through.
Then I’d go through some simple accessibility tests every tester should know. Followed by lots more accessibility tests including using screen readers.
