“Coding and Testing”
- The beginning of coding is a good time to start writing detailed tests.
- As testers think of new scenarios to validate with executable tests, they also think about potential scenarios for manual exploratory testing. Make a note of these for later pursuit.
- Some quick risk analysis can help you decide what testing to do first and where to focus your efforts.
The Power of Three Rule – When unexpected problems arise, you may need to pull in more people or even the entire team. Tester, Developer and Customer (or businesspeople) can together decide on correct behavior and solutions.
Explore It!
As soon as testable chunks of code are available, and the automated tests that guided their coding pass, take time to explore the functionality more deeply. Try different scenarios and learn more about the code’s behavior. You should have task cards for tests that critique the product both business and technology-facing. The story is not ‘done’ until all of these test types are done.
If your exploratory tests lead the team to realise that significant functionality was not covered by the stories, write new stories for future iterations. Keep a tight reign on “Scope Creep” or your team won’t have time to deliver the value you originally planned.
Technology-facing tests that critique the product are often done best during coding. This is the time to know if the design doesn’t scale or if there are security holes.
- MANAGING DEFECTS
- Leaving bugs festering n the code base has a negative effect on code quality, system intuitiveness, system flexibility, team morale and velocity.
- Strive for “zero tolerance” towards bug counts.
- Teams have solved the problem of how to handle defects in different ways.
- Some teams put all their bugs on task cards
- Some teams chose to write a cared, estimate it & schedule it as a story.
- Some teams suggest adding a test for every bug
- The more bugs you can fix immediately, the less technical debt your application generates and the less ‘defect’ inventory you have.
- Try making the estimate for each story to include (atleast) two hours or half a day for fixing associated bugs.
If a bug is really missed functionality, choose to write a card for the bug and schedule it as a story.
Code produced test-first is fairly free of bugs by the time it is checked-in.
- The Daily Stand-Up helps teams maintain the close communication they need.
- Use Big, visible charts such as story boards, Burndown charts and other visual cues to help keep focus and know your status.
- Having story boards gives your team focus suring the stand-ups or when you are talking to someone outside the team about your progress.
Communication
- Testers can help keep the iteration progressing smoothly by helping make sure everyone is communicating enough. They can help programmers and customers find a common language.
- Use retrospectives to evaluate whether collaboration & communication need improving and brainstorm ways to improve.
- Teams in different locations have to make a special effort to keep each other informed.
Build Process
- Teams take different approaches to make sure their build stays ‘green’.
- The build needs to provide immediate feedback, so Keep It Short.
- Tests that take too long, such as tests that update the database, functional tests above Unit level or GUI test scripts, should run in a separate build process.
- Having a separate, continual ‘Full’ build with all of the regression suites is worth the investment.
During the iteration, you are automating new tests. As soon as these pass, add them to the Regression Suite.
As you start the iteration, make sure that test environments, test data, and test tools are in place to accommodate testing.
You may have brought in outside resources for the iteration to help with performance, security, usability or other forms of testing. Include them in stand-ups and discussions. Pair with them to help them understand the team’s objectives. This is an opportunity to pick up new skills!!
- Consider what metrics you need during the iteration – Progress and Defect Metrics are 2 examples.
- Whatever metrics you choose to measure – Go for Simplicity!
testwithnishi 
I always found that one word in the sentence “If a bug is really missed functionality, choose to write a card for the bug and schedule it as a story.” is difficult to consistently apply – really. A lot of ground gets covered in the word “really.” Everyone needs to communicate!
LikeLike
[…] Chapter-18 Coding & Testing […]
LikeLike