Top 10 Takeaways from the TISQA Conference: Agile Testing in the Carolinas

2) Accomplish big goals using small teams that concentrate on small stories

Reddy: Smaller teams foster faster feedback, better communication, and enable rapid response to change. Similarly, discrete, well-defined requirements (such as features and user stories) are much easier to estimate and build than larger requirements. They're easier to prioritize and, therefore, to manage.

Quentmeyer: User stories should be small enough to complete in one-half to 4 days. If a story takes longer than four days to complete, it should be divided into smaller stories.

3) Know your user and your user’s needs (then get user feedback to validate what you think you know)

Reddy: A user story is a short description of functionality told from a user’s perspective. It is a placeholder that is used later to flesh out details. User stories are the basis of all Agile requirements and involve three C’s: a card on the white board that describes the story, conversation with the stake holder and team members to ensure a solid understanding of the requirement, and confirmation of that understanding by the stakeholder before development begins.

Grange: User stories are the tool that focuses everyone’s attention on what the user needs and what has to be developed to meet those needs.

Quentmeyer: Each story applies to only one user, and those users may vary. For example, other parts of the system may be considered a user of a story. The primary goal of each story is a meaningful purpose. We should ask, "What is it about this function that gives value to the customer?" You must be able to define any story with the statement, "As a , I want to so that . "

Walker: One of the primary advantages of using Agile methodologies is that, at the end of every two-week sprint, we get to produce something that we can send to a user and verify "Is this what you wanted?" That is unlike other development methods in which you may find out at the end of the project that the description you thought you heard from the user is not actually what they wanted or needed.

4) Make "testing" part of software development, not a separate activity

Reddy: Agile development uses a team in which testers are "embedded" into development and actively participate in all aspects of the project, rather than testing only after the coding is complete.

Walker: Unit testing becomes a coding practice, not a testing practice.

Quentmeyer: The tester must be an active and contributive participant in the development process that brings a testing mindset to the team, not an individual on the team that tests the product. Testing is not proofreading. It is active involvement throughout the development process: defining acceptance tests, helping developers with unit tests, defining what the product is NOT supposed to do, and so forth.

Page 2 of 4

< Previous Page 1 2 3 4 Next >