I wanted to ask your opinion on whether we should start defining a list of email clients that should be supported (and tested on).
That’s a definite “yes”. We need to define this, just as we do for browsers and their versions.
This is needed for both testing but also for correctly giving visibility to a developer about the (minimal) support they need to ensure for a mail feature that they may be developing, otherwise the results would depend on the opinion or inspiration of the developer, I guess.
- Testing mail clients is very time consuming since it’s a manual process
- We need to be able to have something automated
I think these are related to the “implementation” of the way to get to an objective, but not to the objective itself. Ilie’s question was about whether we should define an objective and, I guess, about what this objective should be (although Ilie did not ask that explicitly). This is to say that:
- the amount of work needed will depend on the number (and diversity) of clients we decide to support. We cannot evaluate the amount of work unless we know what we want to support.
- we cannot evaluate a verification tool if we don’t have the objectives to validate against. Passing all tests of mailtrap (or other library) is not an objective itself
- the fact that we decide to support an email client or not (the objective) is also needed for knowing how to react in front of bugs that are being raised, not only for organising the validation. So we can declare objectives of support without talking about the testing tools or even without testing ( ) only to know what to do with the bugs raised by users.
While I understand that it’s important to always calibrate the objectives in relation with the processes / tools available to achieve those objectives, I think it’s really interesting, in this case, to see exactly where we all stand in terms of vision of this objective (what would we “want” to support).