I have an application form on a website to apply for something. It's been tested thoroughly and passes. However my client found that if you entered an emoji in one the fields that does an address search, the form breaks.

And my answer is "well, yeah." It's an unreasonable action. No user would actually do this, and I think it's silly the client is coming to me about this. I mean, what do they expect if they do unrealistic things to the form that an ordinary user would not?

How do I handle/deal with this? Do I tell the client that they're being ridiculous, or do I humor them and fix it?

This isn't the first time they've done this. They'll find all sorts of ways to break the website, such as enter this value, then delete and enter this invalid character, then enter a number, then delete and repeat, separate the red sea and move my house 6 inches to the left and you get an error. And I just feel like puling my hair out. What do they expect?

Who's the unreasonable one here?

  • 2
    Testers from your client are also users, so "No user would actually do this." is and invalid response when they find a problem with the site. When entering an emoji in an address search (or other invalid data), I would expect either a response along the lines of "invalid entry" or a search result of 0 hits, but not a broken form. Commented May 18, 2018 at 11:18
  • The bug might not just be about the emoji, but any codepoint outside the Basic Multilingual Plane. There are several common systems (such as MySQL) that fail to handle Astral Plane characters, which includes regular symbols used by users of other languages, such as Chinese and Japanese. Not such an unrealistic situation... Commented May 24, 2018 at 21:56

4 Answers 4


From a secuirty point of view, input should never be trusted. What's to say that next time it's not an emojji but some kind of textual exploit such as billion laughs attack?

At the end the day, if it is a public facing site you're going to have script kiddies pointing their tools at it that will send all kinds of data at it. If the page breaks it is your BUG, it should be fixed, and could imply that there is inherent risk (will it accept and execute XSS such as alert('hello') )?

The input should be validated on the client AND the server. Only process data you're expecting.

Checkout Troy Hunt's very useful Owasp Top 10 guide which you can download for free Owasp Top 10 developer Guide


It can be a real challenge to differentiate between what is a bug and what is a new requirement.

One way to make this more explicit is to produce a test report that includes both the testing performed and the scope of the testing. If the client accepts the scope then any future out-of-scope work will be chargeable.

For example, the test report could say something like this:

The address field has been tested for field length. No other text validation is performed.

If this is approved by the client and they then report a problem with emoji's breaking the field it would be considered a change request.


You didn't mention that this was part of some client-beta testing process, so I will assume it's not.

Instead, I assume that this issue came up when an actual client was actually using the application, and it displayed behaviour that the client did not expect.

In my eyes, that is a bug. However!

Do I tell the client that they're being ridiculous, or do I humor them and fix it?

You are displaying remarkably polarized thinking, there. Never tell a client they are ridiculous! Even if you want to fire a client, you'd be better served by doing so in a way that won't give them cause to harbor significant ill will to your company, potentially causing them to then go out of their way to cause you harm (such as publicly posting your ill treatment of them).

And even if it is a bug, there's nothing saying you need to drop everything and fix it now. Have you considered responding with the following?

"Thank you for your feedback! We have received your bug report, and have entered it into our system. Once it's been prioritized, we will begin processing it."

And then give the bug an appropriate (read: low) priority, and get around to fixing it when you eventually have time (possibly never, but going through low-risk, low-reward bug reports seems to me like a valid use of slack time. Your mileage may vary).

Make sure you thank them, because they are doing you a favour. I would love to have clients as dedicated and helpful as this one. S/he is doing in-depth, quality-assurance testing for free. Likely simply because s/he likes your product and wants it to be the best it can be (or possibly just because s/he enjoys finding other people's problems, but either way, the result is the same).


Your Question, Clarified

The core of your issue seems to boil down to this:

It's been tested thoroughly and passes. However my client found that if you entered an emoji in one the fields that does an address search, the form breaks.

Analysis and Recommendations

From a project management standpoint, one can extract the following take-aways just from the two sentences quoted above:

  1. The project's Definition of Done has not been formally defined.

    If you and the client have different definitions of "thoroughly tested" that weren't agreed upon up-front, then you have a problem. It may be a communications problem, a planning problem, or a contractual problem, but in all cases it's a problem at the project level and needs to be dealt with constructively.

  2. You say the form "breaks," but don't define the level of impact.

    Your client is performing extensive QA testing (as someone should on the project), and finding issues. However, "the form breaks" is pretty non-specific. It it puts unsanitized data into a database, causes the application to terminate, or otherwise does something besides raising a recoverable error, then it is a bug. If your application can break when someone's cat walks across the keyboard, it is unlikely to be fit for purpose.

    However, again, the issue is about defining a level of quality. You have defined it as "the form works when users follow the happy path." The client has likely defined it as "the system is robust in the face of unsanitized input." However, the project has not adopted an agreed-upon level of quality that both the developers and the client agree on. Fix that!

  3. The project is not integrating QA or acceptance testing into the development cycle.

    Part of your frustration is that you are getting post facto feedback about the work increment. However, if QA and UAT were truly integrated with the development cycle, there would be no surprises for anyone. Both the developers and the testers would know ahead of time what tests had to pass, and whether or not each increment of work met those goals.

    Moving to a test-first mindset is hard, but doing anything else is setting your project up for failure. This is where project management experience, including process management and communications-oriented leadership, can really help.

  4. You and the customer are not collaborating with one another.

    One of the four core values of the Agile Manifesto is customer collaboration over contract negotiation. Even if you aren't following an agile methodology (which would certainly explain some of your pain), the point is that working side-by-side with your customer rather than relying on hand-offs and round-trip feedback is generally more effective and avoids exactly the type of communications and expectational challenges you're experiencing.

    Work on creating collaboration through a well-defined Definition of Done, implementation of test-driven development, and inclusion of client testers and UAT specialists within each development cycle. Collaboration will almost always be more effective in resolving the challenges you're experience, especially when compared to contract disputes or lawyering up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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