-1

A simple scenario from today: A developer gets a user story to display nice, layout constant, user-friendly error pages in case of an exception.

Developers want to have detailed pages on dev (local machines) environment and same behavior on staging (to trace bugs). While test case needs to validate the new look of error page :) There's no other good place to test that than on staging :) Looks like a paradox to me :) What do we do with that?

Edit: I've been asked to elaborate. Developers prefer detailed error pages with stack trace. Product owner wants to have nice error page without exception details. It is best for product owner not to even mention the word "error" on that page. They want custom error pages. Plus yes, we don't have separate QA environment and staging. It is because we have to ask IT Web team to create all of them, and DBA (not very friendly guys ;) ) to create databases and we have multiple small micro services.

5
  • I don't understand your example, sorry. "Developers want to have detailed pages" - do your refer to the "error pages" you mentioned beforehand? Can you please elaborate (or show a picture) where the exact problem is?
    – Doc Brown
    Commented Jun 28, 2017 at 6:54
  • 5
    Why can't developers look at log files to get that detailed information? Commented Jun 28, 2017 at 7:05
  • @BernhardHiller To complete your comment : there is a log console on browser for web application too.
    – Walfrat
    Commented Jun 28, 2017 at 12:09
  • @BernhardHiller I can see that you think that web development is about javascript.
    – doker
    Commented Jun 28, 2017 at 12:17
  • And where is the environment dependent feature? With a trivial "debug" switch, you can turn on and off stack traces in any environment. Just don't activate it in production. Where is the problem?
    – Doc Brown
    Commented Jun 28, 2017 at 22:08

4 Answers 4

3

Use a debug flag. If the flag is ON, then show stack traces with the error messages. If it's OFF, show just the pretty error messages.

Pretty much every common web framework already works this way...

1
  • This and config settings. That's how it's done. This should be the answer. Commented Jun 28, 2017 at 20:57
2

This is not likely the answer you want to hear, but in order to guarantee that a product works in every environment, you must have every possible environment available for testing. Don't get caught attempting to make a product developed in one environment for a radically different environment.

Clearly you cannot hope to have the exact production environment, though everything else is a compromise and a calculated decision towards whether or not a given difference is going to potentially produce bugs if not properly tested. Need to change address for database from test environment to production environment? That's an acceptable change. Need to use test user in test environment? That's also an acceptable change. Testing a product built in a Linux environment only to deploy to a Windows environment with Cygwin installed.. NOT acceptable! You'd need to test your product both in Linux and on a Windows machine with Cygwin installed in order to ensure there will be no problems.

In your case, you should have two environments for both cases, and for all the features which they have in common, a third environment ideally so that you can test that changes in both work together. Although this may not be possible, but my advice to you is ask yourself if it is your neck on the line. If it is, don't take chances. Insist that each environment in which the client may use your product be present internally for testing.

2

Why is there no other good place to test than staging?

To me it sounds like backwards thinking; obviously things need to be tested in the development environment first and that's where the changes should originate from. Perhaps your issue really is that the development environment isn't up to par?

First and foremost don't push code out of your local environment for someone else to test until it's done, verify your solution until you're confident that you're delivering something bug free. I've too often seen changes just pushed randomly out into staging environments, and even more horribly files edited directly on servers, for testing purposes and breaking builds in general which is both foolish and aggravating for everyone involved.

If you're talking about QA testing, what's preventing the from using a local environment? Can the QA persons spin up a Vagrant box to run the environment? Else, do you have any automated provisioning solution to spin up a separate throwaway environment?

It really isn't a catch-22 moment but you might not have a technical solution in place to allow for it to be tested easily right now. I do promise you that it's possible to solve the issue. Giving more or better advice is however incredibly hard without a better understanding of what the problem actually is.

UPDATE: Can't you just add or use an already existing debug flag in the application? That's, to say the least, a very common solution to the problem.

1

Some teams own a separate QA environment. Thus, QA engineers are able to test your product from the customer's perspective. And staging is used for development purposes by software engineers.

This solution costs more in terms of hosting/infrastructure but it saves a lot of time for both developers and QA team.

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.