Return to Answer

Call it beta.

You've managed timely delivery, of everything except thorough testing. You can still release responsibly but only if you're honest about that.

If you can get it in front of customers and get feed back from them you're in a good position. Just make clear that this is an early release snapshot that is still in early testing.

Of course that only works when the software isn't being relied on for something critical. If legal compliance, money or lives are involved take a breath and focus on what makes it critical. You can still release it and call it beta but only if you can keep people from actually using it for these critical things.

In short, customers can make good testers. But only if you can keep their feet out of the line of fire. Remember, they aren't pros.

Does that mean you didn't need to write the "thorough local tests"? Well you never "need" to write tests. They simply give you added reassurance. But that reassurance can speed development. But you decided to skip it. I'm deeply suspicious of why. If you're doing "thorough local tests" correctly they should speed you up not slow you down. They shouldn't be subject to "complications". They shouldn't end up depending on much to create.

If by "thorough local tests" you mean what Fowler called solitary tests in the mockist style then you're better off without it. I deeply believe in unit testing. Real unit testing. Behavior based unit testing. The original unit testing. Not every Foo class gets a FooTest class testing.

If you gave up on unit testing just to avoid that nonsense I don't blame you. However, I do encourage you to figure out how to craft a functional core for your unit and wrap that in tests that never heard of your DB, file system, or network. It's different. It takes practice at home. Use it at work once it makes you faster.

The bad news is, if you didn't do this from the start you've likely written what we call legacy code. Once you've done that it isn't easy to switch. Michael Feathers gave us a book to help get such code under test.

I point to that only because all I know about you're integration and QA tests is they've left you feeling nervous.

I will say, there is absolutely such a thing as too many tests. Don't feel bad simply because there could have been more of them. Feel bad if they could have been better.

Call it beta.

You've managed timely delivery, of everything except thorough testing. You can still release responsibly but only if you're honest about that.

If you can get it in front of customers and get feed back from them you're in a good position. Just make clear that this is an early release snapshot that is still in early testing.

Of course that only works when the software isn't being relied on for something critical. If legal compliance, money or lives are involved take a breath and focus on what makes it critical. You can still release it and call it beta but only if you can keep people from actually using it for these critical things.

In short, customers can make good testers. But only if you can keep their feet out of the line of fire. Remember, they aren't pros.

Does that mean you didn't need to write the "thorough local tests"? Well you never "need" to write tests. They simply give you added reassurance. But that reassurance can speed development. But you decided to skip it. I'm deeply suspicious of why. If you're doing "thorough local tests" correctly they should speed you up not slow you down. They shouldn't be subject to "complications". They shouldn't end up depending on much to create.

If by "thorough local tests" you mean what Fowler called solitary tests in the mockist style then you're better off without it. I deeply believe in unit testing. Real unit testing. Behavior based unit testing. The original unit testing. Not every Foo class gets a FooTest class testing.

If you gave up on unit testing just to avoid that nonsense I don't blame you. However, I do encourage you to figure out how to craft a functional core for your unit and wrap that in tests that never heard of your DB, file system, or network. It's different. It takes practice at home. Use it at work once it makes you faster.

The bad news is, if you didn't do this from the start you've likely written what we call legacy code. Once you've done that it isn't easy to switch. Michael Feathers gave us a book to help get such code under test.

I point to that only because all I know about you're integration and QA tests is they've left you feeling nervous.

I will say, there is absolutely such a thing as too many tests. Don't feel bad simply because there could have been more of them. Feel bad if they could have been better.

Call it beta.

You've managed timely delivery, of everything except thorough testing. You can still release responsibly but only if you're honest about that.

If you can get it in front of customers and get feed back from them you're in a good position. Just make clear that this is an early release snapshot that is still in early testing.

Of course that only works when the software isn't being relied on for something critical. If legal compliance, money or lives are involved take a breath and focus on what makes it critical. You can still release it and call it beta but only if you can keep people from actually using it for these critical things.

In short, customers can make good testers. But only if you can keep their feet out of the line of fire. Remember, they aren't pros.

Does that mean you didn't need to write the "thorough local tests"? Well you never "need" to write tests. They simply give you added reassurance. But that reassurance can speed development. But you decided to skip it. I'm deeply suspicious of why. If you're doing "thorough local tests" correctly they should speed you up not slow you down. They shouldn't be subject to "complications". They shouldn't end up depending on much to create.

If by "thorough local tests" you mean what Fowler called solitary tests in the mockist style then you're better off without it. I deeply believe in unit testing. Real unit testing. Behavior based unit testing. The original unit testing. Not every Foo class gets a FooTest class testing.

If you gave up on unit testing just to avoid that nonsense I don't blame you. However, I do encourage you to figure out how to craft a functional core for your unit and wrap that in tests that never heard of your DB, file system, or network. It's different. It takes practice at home. Use it at work once it makes you faster.

The bad news is, if you didn't do this from the start you've likely written what we call legacy code. Once you've done that it isn't easy to switch. Michael Feathers gave us a book to help get such code under test.

I only point to that only because the only thing I know about you're integration and QA tests is they've left you feeling nervous.

I will say, there is absolutely such a thing as too many tests. Don't feel bad simply because there could have been more of them. Feel bad if they could have been better.

Call it beta.

You've managed timely delivery, of everything except thorough testing. You can still release responsibly but only if you're honest about that.

If you can get it in front of customers and get feed back from them you're in a good position. Just make clear that this is an early release snapshot that is still in early testing.

Of course that only works when the software isn't being relied on for something critical. If legal compliance, money or lives are involved take a breath and focus on what makes it critical. You can still release it and call it beta but only if you can keep people from actually using it for these critical things.

In short, customers can make good testers. But only if you can keep their feet out of the line of fire. Remember, they aren't pros.

Does that mean you didn't need to write the "thorough local tests"? Well you never "need" to write tests. They simply give you added reassurance. But that reassurance can speed development. But you decided to skip it. I'm deeply suspicious of why. If you're doing "thorough local tests" correctly they should speed you up not slow you down. They shouldn't be subject to "complications". They shouldn't end up depending on much to create.

If by "thorough local tests" you mean what Fowler called solitary tests in the mockist style then you're better off without it. I deeply believe in unit testing. Real unit testing. Behavior based unit testing. The original unit testing. Not every Foo class gets a FooTest class testing.

If you gave up on unit testing just to avoid that nonsense I don't blame you. However, I do encourage you to figure out how to craft a functional core for your unit and wrap that in tests that never heard of your DB, file system, or network. It's different. It takes practice at home. Use it at work once it makes you faster.

The bad news is, if you didn't do this from the start you've likely written what we call legacy code. Once you've done that it isn't easy to switch. Michael Feathers gave us a book to help get such code under test.

I point to that only because all I know about you're integration and QA tests is they've left you feeling nervous.

I will say, there is absolutely such a thing as too many tests. Don't feel bad simply because there could have been more of them. Feel bad if they could have been better.

Call it beta.

You've managed timely delivery, of everything except thorough testing. You can still release responsibly but only if you're honest about that.

If you can get it in front of customers and get feed back from them you're in a good position. Just make clear that this is an early release snapshot that is still in early testing.

Of course that only works when the software isn't being relied on for something critical. If legal compliance, money or lives are involved take a breath and focus on what makes it critical. You can still release it and call it beta but only if you can keep people from actually using it for these critical things.

In short, customers can make good testers. But only if you can keep their feet out of the line of fire. Remember, they aren't pros.

Does that mean you didn't need to write the "thorough local tests"? Well you never "need" to write tests. They simply give you added reassurance. But that reassurance can speed development. But you decided to skip it. I'm deeply suspicious of why. If you're doing "thorough local tests" correctly they should speed you up not slow you down. They shouldn't be subject to "complications". They shouldn't end up depending on much to create.

If by "thorough local tests" you mean what Fowler called solitary tests in the mockist style then you're better off without it. I deeply believe in unit testing. Real unit testing. Behavior based unit testing. The original unit testing. Not every Foo class gets a FooTest class testing.

If you gave up on unit testing just to avoid that nonsense I don't blame you. However, I do encourage you to figure out how to craft a functional core for your unit and wrap that in tests that never heard of your DB, file system, or network. It's different. It takes practice at home. Use it at work once it makes you faster.

Call it beta.

You've managed timely delivery, of everything except thorough testing. You can still release responsibly but only if you're honest about that.

If you can get it in front of customers and get feed back from them you're in a good position. Just make clear that this is an early release snapshot that is still in early testing.

Of course that only works when the software isn't being relied on for something critical. If legal compliance, money or lives are involved take a breath and focus on what makes it critical. You can still release it and call it beta but only if you can keep people from actually using it for these critical things.

In short, customers can make good testers. But only if you can keep their feet out of the line of fire. Remember, they aren't pros.

Does that mean you didn't need to write the "thorough local tests"? Well you never "need" to write tests. They simply give you added reassurance. But that reassurance can speed development. But you decided to skip it. I'm deeply suspicious of why. If you're doing "thorough local tests" correctly they should speed you up not slow you down. They shouldn't be subject to "complications". They shouldn't end up depending on much to create.

If by "thorough local tests" you mean what Fowler called solitary tests in the mockist style then you're better off without it. I deeply believe in unit testing. Real unit testing. Behavior based unit testing. The original unit testing. Not every Foo class gets a FooTest class testing.

If you gave up on unit testing just to avoid that nonsense I don't blame you. However, I do encourage you to figure out how to craft a functional core for your unit and wrap that in tests that never heard of your DB, file system, or network. It's different. It takes practice at home. Use it at work once it makes you faster.

The bad news is, if you didn't do this from the start you've likely written what we call legacy code. Once you've done that it isn't easy to switch. Michael Feathers gave us a book to help get such code under test.

I only point to that only because the only thing I know about you're integration and QA tests is they've left you feeling nervous.

I will say, there is absolutely such a thing as too many tests. Don't feel bad simply because there could have been more of them. Feel bad if they could have been better.