SlideServe
Menu
Préférences
© SlideServe · v2026

From Bugs to Quality Engineering: A Phased Approach to Prevention

saad avatar
28 diapositives · 421 Views · Jul 31, 2014

This presentation by Jacky Guo explores the transition from testing to quality engineering with a focus on a phased approach to prevent bugs in software development. Attendees will learn to identify actionable steps for tomorrow, how to clarify requirements, conduct code inspections, and implement test cases effectively. By understanding the difference between reactive testing and proactive quality engineering, participants will better manage defects and improve software quality. Expect to leave with concrete strategies that enhance both process and team morale, fostering a culture of quality.

From Bugs to Quality Engineering: A Phased Approach to Prevention - slide 1
01 / 28From Bugs to Quality Engineering: A Phased Approach to Prevention
1 / 17

Télécharger la présentation

From Bugs to Quality Engineering: A Phased Approach to Prevention
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  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