Software Lifecycle Joke

Software doesn't just appear on the shelves by magic. That program shink-wrapped inside the box along with the indecipherable manual and 12-paragraph disclaimer notice actually came to you by way of an elaborate path, through the most rigid quality control on the planet. Here, shared for the first time with the general public, are the inside details of the program development cycle.

1. Programmer produces code he believes is bug-free.

2. Product is tested. 20 bugs are found.

3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren't really bugs.

4. Testing department finds that five of the fixes didn't work and discovers 15 new bugs.

5. See 3.

6. See 4.

7. See 5.

8. See 6.

9. See 7.

10. See 8.

11. Due to marketing pressure and an extremely pre-mature product announcement based on over-optimistic programming schedule, the product is released.

12. Users find 137 new bugs.

13. Original programmer, having cashed his royalty check, is nowhere to be found.

14. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.

15. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.

16. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.

17. New CEO is brought in by board of directors. He hires programmer to redo program from scratch.

18. Programmer produces code he believes is bug-free. ----

Taken from here

Comments

Anonymous said…
read more jokes on http://www.geocities.com/xtremetesting/
7:09 AM
Post a Comment

Popular posts from this blog

Retrofitting testing - what is it?

It is nice to meet new terms and keywords relating testing. This morning I got a question how I am planning to do 'regression as part of Code Retrofitting testing'.   Have never heard of retrofitting testing before, so did some googling. The best explanation I found was on blog  http://blog.intrepidtesting.com/retrofit-vs-retest-vs-regression-testing/    article " Retrofit vs Retest vs Regression Testing " : Retrofit testing  is carried to to test that a change in functionality is correctly implemented for existing entities. Retrofit testing is more commonly carried out when you have an incremental project, or change requests. If the time available to test is tight, retesting and retrofit testing usually takes a higher priority over regression testing Colleague's comment while trying to help me: " if I googled it correctly then they expect you to perform regression for legacy system where your changes were introduced. In this way I would ...
Read more

tester's day!

Happy testers day! Top 24 replies by programmers when their programs don't work: 24. "It works fine on MY computer" 23. "Who did you login as ?" 22. "It's a feature" 21. "It's WAD (Working As Designed)" 20. "That's weird..." 19. "It's never done that before." 18. "It worked yesterday." 17. "How is that possible?" 16. "It must be a hardware problem." 15. "What did you type in wrong to get it to crash?" 14. "There is something funky in your data." 13. "I haven't touched that module in weeks!" 12. "You must have the wrong version." 11. "It's just some unlucky coincidence." 10. "I can't test everything!" 9. "THIS can't be the source of THAT." 8. "It works, but it's not been tested." 7. "Somebody must have changed my code." 6. "Did you check for a virus on your system?...
Read more