1

I have no requirements for this field by default in my case.

1) If password field accept password like 8 empty spaces in a row, is it usually considered like a bug?

2) If no validating for field length(it accept password of any length) is considered like a bug?

If this two points is bugs, they can be counted as functional bug?

2

Since you don't have guidelines, you would have trouble justifying the behavior of the password field as a bug.

That said, I'd suggest you raise a bug and classify it as a security flaw. You can cite the OWASP security standards password section to justify your case, even if the application isn't a web app: any software that needs a password by definition holds some level of sensitive information.

  • Thanks for help, realy helpfull resource. Yes I agree standards of password security is optimal decision in this case. Many thanks! – zuk22 Oct 19 '17 at 12:21
4

If you don't have specific requirements you should design test cases based on best practices, best user experience and security.

  1. It's not a bug, because it does not behave differently from expectations (you don't have any) but allowing to create password that is weak may lead to account hijacking and information leakage which is an issue. You have to think of a password policy which might be worth to implement.

  2. It also is not a bug. It depends on how these passwords are stored in DB, which algorithms are used for hashing passwords and so on. Password length validation on front-end should only prevent from damaging the back-end(or triggering internal server error) by using too long string (in case when in DB it was set to e.g 64 chars) or any related cases. This should also be based on password policy.

I would say, based on description above, that these are non-functional issues, specifically security issues

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.