Paper de Cem Kaner sobre los puntos claves en el Testing de Software

Les voy a dejar un paper de Cem Kaner (en inglés) que trata sobre 28 puntos claves en el testing de software.

El autor plantea una pregunta o un tema y luego lo analiza, es muy interesante el paper y se puede leer bastante fácil. Si tienen ganas de debatir algunos de los puntos podemos hacerlo en el foro de esta comunidad de Software Testing dentro de Run IT.

Les dejo los puntos que trata el paper:

The Role of Testers

• The primary reason to test is to find bugs.
• The primary reason to test is to prove the program works correctly.
• Testers are THE advocates of quality on a project.
• Test groups should evolve into quality assurance groups.
• The test group should have the power to block release if product quality is too low.
• Testers and programmers have conflicting interests.
• The test group should work independently of the programmers.
• Testers should push their project teams to follow «appropriately professional development models,» like the Waterfall, that require people to THINK before they act.
• Testers should base test cases on documented characteristics of the program. If the software documentation is inadequate for this, testers should assert a quality control function and demand better specification and requirements documentation.

Test Planning and Documentation

• Testers should specify the expected result of every test, in advance.
• Exploratory testing, if done at all, should be done only by experts.
• There should be at least one thoroughly documented test for every requirement item or specification item.
• Testers should design most or all tests early in development.
• Testers should design all tests for reuse as regression tests.
• Testers should document manual tests in great procedural detail so that they can be handed down to less experienced or less skilled testers.
• Testers should document each test case individually, ideally storing them in a test case management system that describes the preconditions, procedural details, postconditions,and basis (such as trace to requirements) of each individual test.

The Practice of Testing

• Testers should assume that the programmers did a light job of testing and so should extensively cover the basics (such as boundary cases for every field).
• Testers should develop automated tests at the user interface level.
• Testers should design tests without knowledge of the underlying code.
• Most testers don’t need to be programmers, because they only have to specify how the external program will behave in their tests. Testing tools will allow business experts to develop automated tests without having to program.
• Testers should design the build verification tests, even the ones to be run by programmers.
• The pool of tests should cover every line and branch in the program, or perhaps every basis path.
• All failures must be reported into a bug tracking system and carefully counted.
• We can measure the individual effectiveness of software testers by counting how many bugs they find, perhaps with an adjustment for bug severity.
• We can tell how close we are to release of the product by examining the bug curve that shows bug finds per week.

El link al paper: http://www.kaner.com/pdfs/TheOngoingRevolution.pdf

fuente: Run IT – Red Social de Profesionales IT