1 / 28

Bugs – From Finding to Preventing

Bugs – From Finding to Preventing. Jacky Guo. About this presentation. Overview Testing vs. Quality Engineering Start preventing bugs. Objectives. After this presentation, you'll be able to: Identify a phased approach for preventing bugs Identify two actions for tomorrow to prevent bugs.

saad
Download Presentation

Bugs – From Finding to Preventing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Bugs – From Finding to Preventing Jacky Guo

  2. About this presentation • Overview • Testing vs. Quality Engineering • Start preventing bugs

  3. Objectives • After this presentation, you'll be able to: • Identify a phased approach for preventing bugs • Identify two actions for tomorrow to prevent bugs

  4. Test vs. Quality Engineering (SQE) "Test: to try something out… in order to find out… how well it works…" "Engineering: the application of science in the design planning, construction and maintenance of… manufactured things"

  5. Test vs. Quality Engineering (SQE) (continued) Test • Late in the timeline • Reactive • Find defects • Singular in affect Quality Engineering • First in the timeline • Proactive and reactive • Understand defects • Multiplicative in affect

  6. Phased approach • 3 elements • Clearly written requirements/specs • "Look" at code • "Test" early

  7. Phase 1: how do I start? • Written requirements • Clarify user& user scenario • Have your design principle • Simple • One Step instead of two or three • Avoid repeated things • Batch command • Bug the documents • "Does everyone see the same picture?" • "Will" versus "might, should, desirable" • Testability/ Sustainability • SMART

  8. Phase 1: how do I start? (continued) "Look" at Dev Design • Understand dev design • Assumption • Dependency • Work flow • Data flow • Error/Exception handling/Log system • Cover different user scenario • Testability • Risk

  9. Phase 1: how do I start? (continued) "Look" at code • Code inspections or reviews • Reviews are light-weight • Target code subsets • Inspect only the most critical/difficult sections. • Static analysis • Built into VS2005 • Find Bugs • Compiler warnings • Debugging skill

  10. Phase 1: how do I start? (continued) Set the example • Test requirements • Test design • Archive/version control(Testlink) • Reviewed by program manager and developers • Test code • Small code reviews

  11. Phase 1: done Congratulations • You have just grabbed low-hanging fruit • You have prevented countless bugs • You have risen above at least 50% of the Industry Now what?

  12. Phase 2: change the process Learn about your bugs • Find the cause • Unexpected customer requirement? • Vague spec? • Rushed design? • Domain knowledge? • Code error? • Be gentle, accurate and honest • Make a change

  13. Phase 2: change the process (continued) Assess the value/impact of that change • Hard Metrics • Defects per 1K LOC • Test cycles to ship criteria • Soft Metrics • Less panic at the end • Fewer pizzas ordered • People are happier

  14. Call to action • Start small, get a win • What are people most upset about? • What is the low-hanging fruit? • What does the RCA data say? • Be prepared to set the example

  15. Call to action (continued) What can you do tomorrow (pick 1)? • Get a best practice on the schedule • Document one requirement or design • Get it reviewed • Code-review one critical section • RCA 10 bugs • Implement 10 unit tests

  16. Review process • Requirement spec review • Dev Design review • Test Plan review(involve Dev) • Code Review(including bug fix) • Release spec review summary

  17. Test case Management • TC from Bugs by customer/external users • TC from review dev design • TC from user scenario • TC from Bugs review in case of regression • Regression Test strategy("diff" VS "full") • BVT runs before Dev Check in summary

  18. Bug Management • Map to TC • Bug quality • Root cause(process may needs change) • Bug fix review to evaluate the risk • Control the bar to fix bug(potential risk) summary

More Related