Lisa Crispin - Testing Extreme Programming
Here you can read online Lisa Crispin - Testing Extreme Programming full text of the book (entire story) in english for free. Download pdf and epub, get meaning, cover and reviews about this ebook. year: 2002, publisher: Addison-Wesley Professional, genre: Computer. Description of the work, (preface) as well as reviews are available. Best literature library LitArk.com created for fans of good reading and offers a wide selection of genres:
Romance novel
Science fiction
Adventure
Detective
Science
History
Home and family
Prose
Art
Politics
Computer
Non-fiction
Religion
Business
Children
Humor
Choose a favorite category and find really read worthwhile books. Enjoy immersion in the world of imagination, feel the emotions of the characters or learn something new for yourself, make an fascinating discovery.
- Book:Testing Extreme Programming
- Author:
- Publisher:Addison-Wesley Professional
- Genre:
- Year:2002
- Rating:5 / 5
- Favourites:Add to favourites
- Your mark:
Testing Extreme Programming: summary, description and annotation
We offer to read an annotation, description, summary or preface (depends on what the author of the book "Testing Extreme Programming" wrote himself). If you haven't found the necessary information about the book — write in the comments, we will try to find it.
Lisa Crispin: author's other books
Who wrote Testing Extreme Programming? Find out the surname, the name of the author of the book and a list of all author's works by series.
Testing Extreme Programming — read online for free the complete book (whole text) full work
Below is the text of the book, divided by pages. System saving the place of the last page read, allows you to conveniently read the book "Testing Extreme Programming" online for free, without having to search again every time where you left off. Put a bookmark, and you can go to the page where you finished reading at any time.
Font size:
Interval:
Bookmark:
Identify as many questionable or incorrect assumptions as you can in the following statement: Testers run tests, and running tests requires that the code be written, and no code is available until the end of the first iteration. Therefore, the earliest the tester is needed is the end of iteration 1. |
Testers run tests. In fact, testers perform many other activities, including identifying hidden assumptions (wow, this is recursive), helping the customer write acceptance tests, estimating time for acceptance test tasks, and helping the team accurately estimate each story. |
Running tests requires that the code be written. This may sound like a stretch, but other things besides code require testing. Identifying hidden assumptions in stories is one example of a test on something besides code. Usability testing a user interface is another. It's also a good idea to "test" user documentation. |
No code is available until the end of the first iteration. Programmers will produce working code the first day. It's possible to do testing that goes beyond unit testing even before all the code for a single story is completed. For example, a programmer may spike a design and want to have it load-tested to make sure it's scalable. |
The earliest a tester is needed is the end of iteration 1. See points 13. |
For the above XTrack story, assume we've defined the following high-level acceptance tests in release planning. We know this isn't complete; it's just enough to illustrate the ideas (see ). Table 16.4. Test data for Exercise 10
Also assume we've come up with the following additional information while planning and beginning the first iteration:
Write these as an executable test in the style illustrated in the two examples in this chapter. | |||||||||
| // got to be logged in login("bob","bobspassword")// Add a new task with valid values it succeedsassertTrue( addTask( "User Gui", // name "Create GUI", // description "Bob", // assignee "2", // estimate "3", // actual "Not Started" ) ); // stateassertTrue( addTask( "User Gui", // name "Create GUI", // description "Bob", // assignee "2", // estimate "3", // actual "Started" ) ); // stateassertTrue( addTask( "User Gui", // name "Create GUI", // description "Bob", // assignee "2", // estimate "3", // actual "Complete" ) ); // state// add task with invalid values it failsassertFalse( addTask( "", // name - missing "", // description - missing "Bob", // assignee "long time", // estimate not numeric "longer", // actual not numeric "Ohio" ) ); // state invalid addTask() adds a task using the specified values and returns true if the task was added and false if it failed. |
Write an executable test for this story, and include the class and method declarations as illustrated in this chapter. Include at least one test case in each method, but don't worry about completeness. The point is the organization, not the details. | ||||||||||||||||||||
The class name is IterationStoryTest , and it has two methods: testDisplay() and testUpdate() : public class IterationStoryTest { public void testDisplay() { login("bob","bobspassword") assertTrue( displayIteration( "1") ); assertFalse( displayIteration( "-1") ); } public void testUpdate() { login("bob","bobspassword"); assertTrue( UpdateIteration( "10", "20041201", "20041215") ); assertFalse( UpdateIteration( "non-numeric", "bad date", "bad date" ) ); }} | ||||||||||||||||||||
Pretend your customer can't stand the executable format. Create or mock up a spreadsheet for him that corresponds to the executable test in question 1. | ||||||||||||||||||||
The spreadsheet would be IterationTestStory.xls , and it would have two workbooks:
|
Identify the assumptions about the initial system state in the following tests for XTrack story 4: public class IterationStoryTest { public void testDisplay() { assertTrue( displayIteration("1") ); assertFalse( displayIteration("2") ); } public void testUpdate() { login("bob","bobspassword"); assertTrue( UpdateIteration( "1", "10", "20041201", "20041215") ); assertFalse( UpdateIteration( "2", "non-numeric", "bad date", "bad date" ) ); }} |
The display test assumes iteration 1 has been defined and iteration 2 has not. The update test also assumes iteration 1 has been defined. |
Are these tests rerunnable without resetting the system? |
Yes, because executing the tests has no effect on the truth of the assumptions. |
What about manual tests? |
No manual tests. |
How many acceptance tests should be manual? |
None. |
What about the tests you can't automate? |
Don't run them. |
Given the following two Xtrack stories, identify as many modules and their parameters as you can:
| ||
| createStory(number,name,author,description, estimate,iteration,state) Attempts to create a story with the specified fields. If they're valid and the story is successfully added, it returns true ; otherwise, false . displayStory(number)Returns a display of the specified story. updateStory(number,name,author,description, estimate,iteration,state)Attempts to update the story specified by number with the specified values. If they're valid and the specified story exists and is updated successfully, it returns true ; otherwise, false . prioritizeStory(number,priority)Attempts to update the story specified by number with the specified priority. If the story exists, the specified priority is valid, and the story is successfully updated, it returns true ; otherwise, false . assignIteration(storyNumber,iterationNumber)Attempts to update the story specified by storyNumber to the specified iteration. If the specified story exists, the specified iteration number is valid, and the story is successfully updated, it returns true ; otherwise, false . |
Font size:
Interval:
Bookmark:
Similar books «Testing Extreme Programming»
Look at similar books to Testing Extreme Programming. We have selected literature similar in name and meaning in the hope of providing readers with more options to find new, interesting, not yet read works.
Discussion, reviews of the book Testing Extreme Programming and just readers' own opinions. Leave your comments, write what you think about the work, its meaning or the main characters. Specify what exactly you liked and what you didn't like, and why you think so.