11

No, it's not a bug by default. This depends on the requirements of the system, there is not global rule for situations like this. Some operating systems allow the same user with different casing. Even the user part of an email adress (username@hostname.tld) is not case sensitive in all cases. For more info see the question Are email addresses case sensitive?...


8

It depends. Assuming that you're working in a US environment (the zip code being in US format) and that your application specifications don't call out whether or not a zip 5+4 should be accepted: I'd report this as a bug if: Your specifications/user stories call for any or all valid US zip codes to be accepted (this is an implicit requirement to accept ...


4

Checking for case sensitivity itself isn't a bug in my opinion. I'd consider it a bug, if the user doesn't get informed about the username being case sensitive. Otherwise one may wonder, why he sometimes can log in fine (Username1) and sometimes gets an error message (username1). In other cases the case-sensitivity is used to add an extra (but very thin) ...


4

If you don't have specific requirements you should design test cases based on best practices, best user experience and security. 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 ...


3

I'd consider this as a matter of usability/UX. Most services I know use case-insensitive logins, and most people I know use to blame services with case-sensitive logins. So, I'd say you should check the requirements, and, depending on the result, consult with BA/PO/PM, or whoever you have on the project, and ask him a) if anyone ever thought about login ...


3

You cannot test frontend using JMeter mainly due to its main constraint, as per JMeter project main page: JMeter is not a browser, it works at protocol level. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In ...


2

Did you try: elem.sendKeys(Keys.CONTROL,"a"); Output And about your code: It is failing because you are passing WebElement password = driver.findElement(By.id("passwd-login")); highlight1(high,password); Instead of WebElement password = driver.findElement(By.id("passwd-login")); highlight1(driver,password); Highlighted output:


2

Use the below function public static void highlight(WebDriver driver,WebElement element) { JavascriptExecutor js = (JavascriptExecutor) driver; js.executeScript("arguments[0].setAttribute('style', 'background: yellow; border: 2px solid red;');", element); } Where driver is your WebDriver instance and element is the WebElement which is to be ...


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 ...


2

It is definitely a bug, unless your requirements mention that ZIP extension should be ignored. So talk to your customer how to handle it. One possibility is to silently strip the extension if you don't need it.


2

There is no standard rule. Every application decides how to handle user names and whether case sensitivity is needed/wanted. If your application is supposed to be case-sensitive and isn't, that's a bug. If it's not supposed to be case-sensitive and is, that's a bug.


1

I agree with @Niels. This cannot be considered as a bug, solely on the basis of being able to create accounts with different set of upper case letters. You should refer to the requirements, to see if it specifically distinguishes between upper case and lower case in case of account creation. There is no rule to check in this scenario. For Gmail allows you ...


1

In case of username it isn't case-sensitive so user2 = useR2 = USER2 but in password case those are 3 different passwords because password will be encrypted.


Only top voted, non community-wiki answers of a minimum length are eligible