Making quality visible in Product Engineering
•Als PPTX, PDF herunterladen•
0 gefällt mir•784 views
SuperOffice has established a culture where QA is an important and integral part of the daily work in R&D. It's about highlighting the quality aspect of everything we do and what actions we need to execute in order to use the new level of visibility that is created. This presentation was held on the Software Product Engineering Conference in Colombo in June 2103 (www.spec.lk) and is about what SuperOffice has done to bring QA to this level
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (19)
Ähnlich wie Making quality visible in Product Engineering
Ähnlich wie Making quality visible in Product Engineering (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Making quality visible in Product Engineering
- 1. Making QA Visible by JAN PETTER HAGBERG COLOMBO FRI 14. JUNE 2013 in product engineering
- 2. A quality assurance company should champion processes that build quality into the code from the start rather than test quality in later Mary Poppendieck
- 3. my talk today how we have made QA an integral part of what we do, and why we do it
- 4. why do we need to focus on quality assurance
- 5. #1 Product Engineering is all about “not counting your chickens before they hatch”
- 6. #2 what’s on the outside (design), must match what’s on the inside (code)
- 8. how will focusing on QA improve your time to market
- 9. you don’t want to end up here
- 10. bad quality means administration overhead waste of valuable time
- 11. bad released quality means handling of defects in your released version which will interrupt the flow in your current project
- 12. doing things right the first time allows you to free up time for creativity and ingenuity
- 13. things we have donethat we find useful Making Quality visible
- 15. our vision is to deliver software solutions which positively influence the individual user, by making their daily tasks more efficient, easier and fun The SuperOffice vision statement - 1990
- 16. second build a culture we discussed… How we really wanted to develop our software How we wanted to be proud of not only the software we created, but also how we created it
- 17. In product development there is no such thing as it works on my machine it is just a 10 min job a favorite hero who solves your current problems with dazzling programming = problems!
- 18. our mindset is that we are all product developers
- 19. …and we all participate in the system tests
- 21. each phase produces deliverables that should be «tested» before handed over to the next phase in the development process
- 22. document inspection Formal quality verification of a finalized document. May be used on all documents. Document updated. 1/3 presentation A small informal presentation of a solution aimed to generate discussion and maybe alternative solutions backlog meetings Presentation of User Stories code review Quality Assurance of code or unit test code before feature complete or after implementation of bugfix pair testing Developer gets help with dev.test from a tester. Bugs found are fixed different types of reviews
- 23. project retrospective Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand Norman L. Kerth
- 24. why project retrospectives? the exercises build trust really visualizes the QA aspect you learn a lot in projects
- 25. Project Retrospectives – a handbook for team members by Norman L. Kerth
- 26. fourth process improvements should be an evolution not a revolution
- 27. -> 97 - Source Control system - Developers tested during weekends when product was considered finished 1997 - The developers tested at the end of the development cycle - BugTracker, our own implemented bug database - Improved our Release Test routines 1998 - We introduced a common coding StyleGuide - Specification and Technical design templates was introduced - Bought a professional bug tracking system - DevTrack 1999 - A dedicated test person was hired - Code Reviews introduced - Rational Rose and UML was introduced - Nightly builds - Milestones with testing of each Milestone - First Project Review 2000 - We enhanced the templates for Specification and Technical design 2002 - Test Procedures were introduced - Two persons on the Test team 2003 - StateZero DB created which is a DB you know the content of. 2004 - Developers Test (checklist) - Unit Tests on NetServer 2005 - Three persons on the Test team - 1/3 Reviews and Document Inspections 2006 - QA Plan template and QA Progress Plan template - Smoke test introduced - Hired Hans Schaefer to help us with analyzing our test work 2007 - Sri Lanka test resources was hired (3 people) - SCRUM introduced 2008 - Improved our Beta program - More Test people hired 2009 - SCRUM used in our largest project so far SuperOffice 7.0 win & web - Sri Lanka test resource now counts 3 more people = 6 people, 4 people in Norway - One tester on each team 2011 - Microsoft TFS tool introduced, supports working with the SCRUM as an Agile method
- 28. SCRUM process makes QA work visible sprint test functional test TDD testing is part of daily work backlog meeting sprint planning
- 29. visibility of status apply rules and more… one tool
- 31. problem? Product Developers have little or no contact with the users of the software they build
- 32. frequent releases will give you quick feedback from your users and increase the quality awareness among your product developers
- 33. beta program «testing carried out by real users in real environments» the beta program can be an opportunity to let your product developers get to know your users
- 34. in this talk Making QA visible in Product Engineering
- 35. have a vision culture - we are all product dev. bring everyone on-board find defects early with reviews feedback from customers
- 36. successful implementation of QA in every aspect of what you do will give you the ability to do more!
- 37. thank you!
- 38. about me I am experienced in most roles involved in software development after 20 years in the business. I have worked both in the ISV industry as well as a consultant. After many years as a programmer, I started to look closer to the processes and methods used in software development and how to improve these. With a special interest in delivering good quality software on time I have build up the QA team in SuperOffice and also embraced Agile methodologies as the development process to be used within the company. Today I am working with offshoring, distributed teams, processes in R&D and as SCRUM master. I am also the QA Manger in SuperOffice SuperOffice have 200 employees, 42 of us work in R&D
Hinweis der Redaktion
- QA are all the activities we do to ensure correct quality during development of new products
- What we in SuperOffice wanted to achieve was to find the defects early in the development cycle, preferably before they where implementedfinding defects should be the exception not the rule. if verification triggers test- and fix cycles, then the dev.process is defective.What you want Is a culture where you don't blame testers for escaped bugsIn the earlier days, Quality Aassurance was initially used, like in World War II when munitions were inspected and tested for defects AFTER they were made. Today's quality assurance systems emphasize catching defects BEFORE they get into the final product and by that eliminate waste
- I strongly believe in these three principles
- Software product development is about making a great product that your audience want to buy. You do this by building the product first and then people will evaluate it and buy it if they like it."Like it" does not only mean functionality, but also that ithas an easy to understand designactually works as intended, meaning that the user gets a good feeling of the product in his experience of using it
- Quality is important for good user experience. Not only in the design, but also in the materials usedYou wouldn't build a great design chair using rotten wood, would you? Steve Jobs was extreme in his thoughts about this when he built his Macintosh computers. You don't need to go that far, but it is important that:Good quality architecture and code that is maintainable AND extensible over time/versions
- You want to eliminate waste because you need that time to work with your next versionmore bugs means more time until you are able to releasefor every month you delay your release because of bad quality (it is not ready) you both loose sales and the opportunity to start on the next version of your product= bugs are waste
- This might look like a finished project ready to ship, but is not! I believe in what I see and not what project plans tells me. I need to see a working piece of software to know the statusThe picture above is from early 2000. The cards on the wall are not user stories, but functional areas (large piece of functionality)In this image there are a lot of hidden work – bugs, not completed features, works on my machine etc= You do not know the status of this project before you have tested it
- In theproject:Eachbugfound late in thedevelopmentcycleinvolvesseveralpeople and administrationofthebug; Tester (findsbug, logs it)Product Owner (reproduces thebug, evaluatesthebug)Developer (reproduces thebug, fixes it, developers test)Tester (verifiesfix)This sums up to manyhours used pr bug = waste
- After the Release:In Product Development you must always think of your next version and start developing it as soon you have released. You don't want to use your time fixing faults in a released product ==> It ruins your flowWhen you release you should know the defects that exist in your product. Your software will always have errors, but you should know about them so you are able to evaluate which ones to fix and which ones to ship with your softwareSpending less resources on older versions means you can focus on improving your product-line and delivering a better user experience.
- I believe that taking QA seriously, doing things right the first time will free up time for improving your product and make it more competitive
- Not time to tell abouteverythinghere, but I willgiveyou 5 thingsthatwe have done to ensurethat QA is visible in our R&D department and is a part oftheeverydaylifeofeach and oneofus, not onlythe testers.
- This vision actually sets the standardIf you are so lucky that your company have a vision, you can find a lot of useful information here. The SuperOffice vision guides us in where to put our efforts when we develop our software. We can spend some time on a user control if we think it will apply with our vision about being more efficient and easier to use.The same goes for bugs – our software should POSITIVELY influence our users, and you don’t do that with a piece of software with serious defects OR a lot of minor defects that the user runs into all the time => gives a negative user experience and not positive
- At one time in SuperOffice we started to talk about how we really wanted to develop software. This was important because it created a concensus for the basic To establish the culture we started with study groups. Once a week at almost at the end of the day, we gathered in a study group and discussed books like “Code Complete” and “Clean Code” (Steve McConnel), Design Patterns, The Deadline, Peopleware (Tom DeMarco) to mention a few.
- The code must work on the test servers – no discussion and it is your job to make sure that it worksThere is no such thing as a 10 min job: It is not just to "add" not planned functionality just because the developer sees an opportunity. It´s inevitable that it will involve other resources from Design, Testing, error handling and prioritization by Product Owner etc also = use a lot of time not scheduled forA hero in your team that always fixes your problems as a Project Manager, but very often with consequences revealed later.= this causes problems
- How to build the QA culture - At SuperOffice we all have the title "Product Developer", but we have different skills in designing, development and testing etc.
- Everybody participates – all meetings are rescheduled – it is Fun and we all learn new things about our product
- Reviews and retrospectivesareactivitiesthatreally supports theconceptofthat QA is everyonesresponsibility. Thesearetechniquesthatare used bothearly and late in thedevelopmentprocess and theyarethere to ensuregoodqualityearly or to improveyourprocess and learn from yourmistakes.
- Testing in thiscontext is Reviews, Presentations ofhowwethinkaboutthatthenewarchitectureshould be (Technical review) etc…
- Reviews are the maybe mot visible QA thing you do since it involves almost everyone. Shows that you have to deliver Quality before you send you work to the next person in the working chain.Sogeti claims that 40% of the bugs are introduced before the coding starts. This very much align with what Tom Gilb also saysStart early - look for bugs in your documentation. Use techniques like: Document review, backlog meetings, 1/3 presentation etc. This involves Product Owners, Designers, Testers and Developers and makes the Quality Assurance aspect very visible
- Even if you do SCRUM and sprint retrospectives, it is also a good idea to run a project retrospective and get an analyze of the whole project from start to end.The Project Retrospective technique does not focus on blame, but that we did what we did because of the situation at hand and the knowledge we had at that time
- Within Product Engineering it will be the same peoplethatwillworkonthenextversionofyourproduct. It will be veryuseful to analyzewhatworked and whatdidwe not yetknowhow to dealwith etc.Whathappened in theprojectWhydid it happenWhatcanwe do to make sure it does not happenagainThe workshop aims to build 5 posters:Whatworkedwellthatwewill not forgetWhat have welearnedWhatshallwe do differentlynext timeWhatweneed to discussfurther, still puzzles us.Whatwedon’tknowhow to solve at this moment
- You want to have everybody on boardPeople are only able to adjust to a few changes in each project, not all at once
- QA is very visible in the Agile and SCRUM process.Sprint TestPerformed by a QA person when a part of a functionality is finishedimplemented to ensurethat it works and that it workswithother parts ofthefunctionality and the rest oftheapplication.Functional TestPerformed by a QA team when a functionlity is finishedimplemented and all bugsfound by Sprint Tests arefixed. Last test offunctionalitybefore a System Test.
- Tools, like TFS - everything is in the same tool. Apply rulesUsing a tool that contains functionality or is integrated with all sub-systems so that everybody easily gets an overview of open User Stories and unresolved bugs at any time makes both the progress and quality more visible for every team memberAbilty to apply rules for submitting of code
- This is where you connect with your users
- We are often working “behind closed doors”, only our bosses gets to meet our customers and users now and then
- This is also an opportunity for you to let your Product Developers experience how the product they have created is received by your usersIt is easier to understand the problem of a user if you get to see what a fault in your program causes him in his daily work.Gamification – possible for users to “like” functionality so that your dev.teams get scores?In two projects we have used a pre-beta program with 20 users that have helped us testing. They where given a short test assignment that also teached them about the new functionality. We shared the result in a tool where everyone could watch the progress and the comments written by the testers. We answered the testers ASAP and logged bugs if they found anything interesting – the best part; the users thought it was fun Free testers
- …becauseyou do it right the first timeDon’tneed to use time on fighting bugs