E porque hoje é sexta-feira....

Software Lifecycle

Software Lifecycle

This is the real developement cycle of a piece of software

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.

O nosso BLOG - Malta vamos dinamizar isto !!!

Na sequência do pedido de artigos para a nossa newsletter, julgo ter importância um blog - para que partilhemos experiências, contruamos um arquivo das newsletters, e tentemos actualizar o máximo que pudermos para que nunca sejamos apanhados de surpresa por alguma inovação. Tiremos dúvidas uns com os outros... Bom, aquilo tudo que sabem...

Esperemos que este seja o kickoff, de muita discussão, partilha, esclarecimento, conhecimento - tudo no sentido construtivo, claro!!!



__________________________________________________

Testing is the art of thinking.
Testing is the fun process of finding bugs.

______________________________________

Here is the main Testing Laws:

Murphy's Laws
**********************

• Any non-trivial program contains at least one bug.
  
• There's always one more bug.
  
• Every program has at least one bug. Programmers also know that every program has at least one line of unnecessary source code. By combining these two rules and using logical induction, it's a simple matter to prove that any program could be reduced to a single line of code with a bug.
  
• Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
  
• In any program, any error which can creep in will eventually do so.
  
• Not until the program has been in production for at least six months will the most harmful error be discovered.
  

Murphy's law says:

• The information item that indicates the irrelevance of the contained information is visible only after you've retrieved the whole information.
• A variation: If you try to find bugs in an application using a testing tool, you'll find bugs in the testing tool that keep you from testing your application.
• And the hardcore version: If you have successfully gotten a new version of the testing tool with all bugs fixed, you discover your application is due for shipment, and you don't have any more time to test your application.
• Alternative hardcore version: If you have successfully gotten a new version of the testing tool with all bugs fixed, you discover your application is incompatible with the testing tool -- which you could not know in advance since the bugs in the testing tool kept you from using it.
  

• Pareto Principle 80% of the contribution comes from 20% of the contributors.

***

• But recent surveys show that 80% think that they are among these 20% of contributors.
  

Murphy's Laws of Computing

• When computing, whatever happens, behave as though you meant it to happen.
• When you get to the point where you really understand your computer, it's probably obsolete.
• The first place to look for information is in the section of the manual where you least expect to find it.
• When the going gets tough, upgrade.
• For every action, there is an equal and opposite malfunction. He who laughs last probably made a back-up.
• A complex system that does not work is invariably found to have evolved from a simpler system that worked just fine.
• The number one cause of computer problems is computer solutions.
• A computer program will always do what you tell it to do, but rarely what you want to do.

C. Northcote Parkinson's Laws

• Work expands so as to fill the time available for its completion. It is better to be a has-been than a never-was.

• Delay is the deadliest form of denial.
  

Weinberg's Laws
**********************

• If you can't think of three things that might go wrong with you plans, then there's something wrong with your thinking

More Software Testing Laws

• Not all test that passed for the first time will necessary passed for the second one.
• What will passed in the mind of developers can fail in the real world.
• A computer lets you make more mistakes faster than any other invention in human history.
• If you can't test the software that you build, you shouldn't build it.
• Testing never ends it just stops.
• There are always circumstances under which software will fail

Software Testing Principles

From:The Art of Software Testing Glenford J. Myers , 1979

• A necessary part of a test case is a definition of the expected output or result.
• A programmer should avoid attempting to test his or her own program.
• A programming organization should not test its own programs.
• Thoroughly inspect the results of each test.
• Test cases must be written for invalid and unexpected, as well as valid and expected, input conditions.
• Examining a program to see if it does not do what it is supposed to do is only half of the battle.
• The other half is seeing whether the program does what it is not supposed to do.
• Avoid throw-away test cases unless the program is truly a throw-a way program.
• Do not plan a testing effort under the tacit assumption that no errors will be found.
• The probability of the existence of more errors in a section of a program is proportional to the number of errors already found in that section.
• Testing is an extremely creative and intellectually challenging task.
• Testing is the process of executing a program with the intent of finding errors.
• A good test case is one that has a high probability of detecting an as-yet undiscovered error.
• A successful test case is one that detects an as-yet undiscovered error.

• Some Myths about Software Testing
  
• Testing is only reactive in nature.
• Testers have to have full domain expertise.
• Anybody can do testing.
• Automation should always be utilized.
• "Formal" methods are "too much" for our company.
• Testing always increases development costs.
• There is no need to bring testers in early.
• Exploratory testing is always ineffective.
• Adding more testers to a project will reduce testing time
• Testing can always find all bugs if enough time is given.
• Testing does not, by itself, improve software quality.
• Everybody can do a test automation
• Automation can eliminate or reduce manual testers.
• The same testing strategy can be applied for manual software testing and automated software testing.

The following 3 myths submitted by Thomas Drake:

• Testing is the process of demonstrating that defects are not present in the application that was developed.
  
• Testing is the activity or process which shows or demonstrates that a program or system performs all intended functions correctly.
  
• Testing is the activity of establishing the necessary 'confidence' that a program or system does what it is supposed to do, based on the set of requirements that the user has specified.