Writing Test Cases

De productpatterns_wiki
Saltar a: navegación, buscar

Spanish.jpg Español

Box-In.png
Entries

  • Story Task version X Developer Y

Box-Out.png
Exit

  • Test.xls

Star.png
Solution

process-descending-24px.png
Process

Writing Test Cases1.png

time-24px.png
Development time

    • To acquire the necessary knowledge to develop the software product:
    • To create the Product Pattern: 45 minutes.
    • To apply the Product Pattern: .



video-24px.png
Explanatory video

  • Not applicable

Search-32px.png
Quality Controllers

  • None

template.png
Templates

Pruebas.xls

stuff.png
Examples

papel.jpg
Test case


tool.png
Support Tools

start-flag.png
Initial Context

This product can be used in any projectin which you will have to identify test cases for a particular functionality before implementation. The software features that can not be proven by evidence simply does not exist. Testing provides the opportunity to know if implemented is what actually had in mind. The tests indicate that our work works, when we can not think of any evidence that could cause a failure in our system, then we will finish completely.

end-flag.png
Result Context

Developers get a set of test cases related with a functionality specifically to develop.

cloud.png
Problem

Developers should write tests that help to get a program that works and keeps working over time. Programmers write test method by method under the following circumstances:

  1. If the interface for a method is not clear, write a test before writing the method.
  2. If the interface is clear, but they imagine that implementation could be a little less complicated, write a test before writing the method.
  3. If they think on an unusual circumstance in which the code should work as written, write a test to communicate the circumstances.

forces.png
Restrictions (Forces)

  • Characteristics of organizations: This pattern can be used in existing projects in any company.
  • System Type to develop This product can be used in projects in which user requirements are changing.
  • Type of Customer: It must exist or be achieved, the target area development business being involved in achieving it.
  • Heuristics of use::If it need urgent application or dispose of some of their funcionalidades.

roles.png
Roles

  • Developers (2-12)

lightbulb.png
Lessons Learned

  • Do not be tempted to underestimate the evidence. Working in pairs of programmers can reduce the above possibility. Tests must be isolated and automated. The test results must be positive or negative without intermediate points. As it is impossible to test all, it be necessary must to write test cases than you think you can fail. Be especially careful with the evidence that work when we had not planned (we should review that test case). Therefore to write test cases we must reflect on the evidence worth doing and what not.
  • The output file Test.xls is a generic document for all test types with unit testing box checked, which covers all test cases for a task.
  • A developer chooses an assigned task and together with a partner analyze functionality.

award.png
Capability Level

  • Not applicable.

Options.png
Basic Knowledge and Skills

board-24px.png
Knowledge

  • Knowledge of coding standard that defines the shared code ownership and the rules for writing and documenting code and communication between different pieces of code developed by different teams. Programmers have to follow the so that the code in the system look like if it had been written by one person.
  • Knowledge of the common vision of how the program works in which the activities take place.


help-24px.png
Abilities

  • Ability to work in group. All on an XP computer contribute in any way they can.
  • Predicting what will be completed by the deadline, and determining what to do next.
  • Programming capability in pairs. Besides to generate better code and tests, used to communicate knowledge through teams.

Information-Sources.png
Information Resources