Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I'm a software developer, currently working on web development.

We are a small company a team with 2 persons, a developer and a designer and we have no-one to test our applications.

From the last week I was somehow rushed to finish a task within a project programmed by someone else and I released it with a bug which I did not see.

Today I got the last warning and if there is a release with a bug I will be fired.

So is this fair enough to get fired because releases with bugs without any testers around or should I really improve my skills on testing?

share|improve this question

closed as off topic by Bill the Lizard, gnat, thorsten müller, Jarrod Roberson, Thomas Owens May 14 '12 at 14:35

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

I would leave without giving any notice. This is outrageous. – CodeART May 14 '12 at 14:02
You can retort with a 'last warning' if you are ever rushed to finish a task again they can expect more bugs. – Steven Jeuris May 14 '12 at 14:02
@CodeWorks C'mon now... thats just unprofessional. The place may be tough as nails but that is no reason for you to act like a jerk too. – maple_shaft May 14 '12 at 14:06
@FrustratedWithFormsDesigner - I've checked with the mods there and they say it's not constructive there. Given the answers it's getting I'm tempted to close it here. – ChrisF May 14 '12 at 14:13
@FrustratedWithFormsDesigner There might be a workplace question somewhere but the current version certainly isn't it, IMO. "Should I quit"/is it fair are too localized and not constructive respectively. – Ben Brocka May 14 '12 at 14:19

4 Answers 4

up vote 16 down vote accepted

From your description, I would make the assumption that the company is not happy with your work regardless of the recent release. Also, I suspect that if they are coming down so hard on you it is not because of "a bug" but more probably a habit of having many bugs in your code and they have become frustrated because this one was probably quite visible and was an embarrassment to the company.

Do you have a test procedure document? Do you have automated unit tests? These are the minimum that should be able to pass prior to your releasing a product to the customer. Your unit tests should be run in full always prior to a release. The test procedure document can make use of your engineering judgement and only regression test related functional areas and a couple of make sure the core functionality still works tests, with the addition of tests for the changes you just made.

I know some people are going to claim sometimes you don't have time, but if you are a professional you won't release code that you aren't reasonably confident in. Period. Even if it means missing deadlines by the couple of hours it takes to develop some confidence that things still work.

share|improve this answer
+1 for the first sentence alone. It does sound a little heavy-handed. – Anonymous May 14 '12 at 14:10
+1 this is exactly what I'm seeing too. – Florian Margaine May 14 '12 at 14:10
+1 for reading between the lines of the question. There's more going on than you only get to release one bug. – JeffO May 16 '12 at 16:15

What's not fair, is you work for an idiot.

If they don't want to release with any bugs, don't release. Continue to do your own testing. This will probably take forever or until they come to their senses.

Start looking for another job.

share|improve this answer
This is not a constructive answer and makes it more likely that the question will be closed. – ChrisF May 14 '12 at 14:09
Your answer is worded maybe a little flippantly, but kind of illustrates an important point. Has there been any version of Microsoft Windows without any bugs? Not that I know of. And have the perpetrators of said bugs had their employment terminated by Microsoft? Not that I know of. – Anonymous May 14 '12 at 14:12
@Anonymous-: The difference being that Jeff O qualified by stating "If they don't want to release with any bugs..." - although I suspect that Microsoft doesn't want to either, they understand that they can't catch them all pre-release. MS also has a great deal of QA who are likely held responsible for the quality of a build output. – Steve Evers May 14 '12 at 14:32
@SnOrfus - Of course, I agree with you entirely. – Anonymous May 14 '12 at 15:31
LOL, "I hated your answer so much I'm going to close the question." That's awesome. +1 – Crazy Eddie May 14 '12 at 15:49

I think I know what kind of answers are going to pop up here.

Whilst you should always test everything you write, if time doesn't allow for testing and learning another person's code and you had to release on time, it sounds like you had no other choice than to do your best.

Second of all, any company that applies that kind of pressure without allocating sufficient time and resources to conduct proper testing probably isn't the best place to be working anyway.

Only you can decide if you'd like to continue working there or not. To address the last part of your question - continue to improve your skills in testing, this is an ever-learning profession and it will only ever help you in the long run.

share|improve this answer

There are bugs and bugs. There is the bug that messes up the encoding of some trivial text, and the bug that shows your client confidential data to the public.

If you know you have some critical function you need to check before releasing, then test them no matter what your boss says. If your hierarchy insist on releasing a completely untested product, make sure that they understand that your job is not finished, and that they take the responsibility for anything that could occur. Be sure to communicate this by mail. Always voice your doubts when you feel that you hadn't enough time to deliver a clean product.

If you know that the delivery is risky but you don't voice it clearly, then your are responsible for this problem.

If the bug has very little impact and is difficult to find, then it is stupid to hope to release something in a reasonnable time without this kind of things. Try to explain that you have processes to log and fix those small mistakes after in the next releases.

This a matter of communication.

share|improve this answer

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