Agile qa build quality in
•Download as PPTX, PDF•
4 likes•826 views
Software quality is often considered as something that can be sacrificed if necessary. Even worse many business leaders misunderstand the role of QA as the gatekeeper of software quality. It causes an organization to build low-quality software and spending time and money for fixing defects. By contrast, successful software development means that an organizational commitment to quality speeds software development, ease to add new features, and reduce maintain cost. This presentation provides practical practices for practitioners, and professionals to build quality in from the beginning based on real-world cases.
Recommended
More Related Content
Similar to Agile qa build quality in
Similar to Agile qa build quality in (20)
Recently uploaded
Recently uploaded (20)
Agile qa build quality in
- 1. Riot Games Sam Ryoo Agile QA Build Quality In
- 2. QA???
- 3. Cleaning up the mess?? http://www.betternetworker.com/articles/view/marketing/social-content/best-way-clean-after-party-2
- 5. Contents Move Forward Break the wall A long time ago Summary
- 6. A Long Time Ago
- 13. Break the Wall
- 17. QA ≈ SW Engineer Same skill set but different perspectives http://www.museomagazine.com/OLAF-BREUNING
- 20. Move Forward
- 21. The Problems of Specification http://www.flickr.com/photos/mataniere/3107073262 BA DEVQA
- 22. The Problems of Specification http://greenlynn.blogspot.kr/2010_12_01_archive.html JUST DO IT NOT WHY
- 23. Acceptance Test Acceptance Criteria + Examples (data + scenarios) Acceptance Tests
- 24. ATDD/BDD • Real-world examples • Select a set of these examples to be a specification • Automated specification • Develop software to pass the acceptance tests • Use the set of acceptance tests to facilitate discussion about future change request http://news.nster.com/1530-baby- instructions-101-the-do-s-dont-s
- 25. Executable Specification As formality increases, tests and requirements become indistinguishable. Robert C. Martin and Grigori Melnik Tests and Requirements, Requirements and Tests: a Mobius Strip IEEE Software January/February Issue 2008
- 28. Summary
- 30. Take Back Dev Skills http://news.kievukraine.info/2008/11/kie vs-scammers-target-easy-prey.html
- 31. Q&A
Editor's Notes
- Hi everyone. I’m Sam, Director of technology iat Riot Games Korea. I have been focusing on “how to build good software” I would like to share my knowledge and experience. Let’s start to define “what is good software.” What does good software mean to you? I think good software must meet customers requirements. It’s quite simple but hard to achieve and also many things to focus on. Especially I want to focus on “the quality of software”. Quality is the only one thing we can actually control and the basics to build good software. QA is for guarantying good quality software. Let’s look at today’s reality.
- Dilbert is a very famous cartoon for software engineering. In this cartoon Dilbert explains the purpose of QA to his colleague. According to Dilbert, QA is for detecting defects of product.
- Let’s think about cleaning up the mess. When QA happens at the end of development process, problems arise, such as not enough time to understand product, or fixing defects, That’s why “Known bugs” exist.
- See. It’s too late. How much will the repair cost now? If we had found these problems at the beginning, it would have saved us time and money.
- We can break down this problem in 4 categories.
- Let’s start with the origin of sw development.
- This picture is Eniac which was the first computer in the world. As you can see, there’re no qa and ba job in this picture. There were all engineers. They built and maintained all by themselves.
- This the first example of debugging. The first computer used vacuum tubes which attracted actual insects. This picture shows the dead bug which was removed from the computer. From this time, some engineers realized that QA and BA were necessary and needed to be created.
- Some industry pioneers introduced the importance of QA an BA. This is where the role of SW engineers spilt into QA, BA and sw engineers.
- Some engineers went to QA role. With this they built their own skill sets such as “Test scenario”, “Testing”, “Planning”, and etc. These skills are highly necessary for detecting bugs. However they lost some important engineering skills at the same time.
- There were three famous kingdoms in Chinese history; all competing for supreme power. With this competition, they built walls between them, losing all collaboration. The BA writes the specifications for sw. DEV writes the code according to the specifications. Finally QA detects bugs to meet the requirements of the specifications. Unfortunately, The QA process comes at the end of sw development.
- Let’s talk about the problems of these walls. Walls basically prevent collaboration. For example, after BA finishes, they “throw” their results over the wall to DEV. After that, DEV finishes their code and then “throws” over the wall to QA. Can you imagine the problems this creates? A vicious cycle is created. If bugs occur, by the time QA receives the code, there isn’t enough time to repair. Moreover, if specifications don’t meet the customer’s satisfaction, it’s a huge tragedy.
- Let’s talk about the solution. First, we need full collaboration.
- Here is a breakdown of costs of debugging at each stage. If bugs are detected at the TDD stage, repairs are only $5. However, if we find bugs at Full Build stage, the cost Rises to 10 times that. Finally, if bugs are detected at the System Test stage, it will cost 1000 times more. As a result, detecting bugs in the beginning stages, we can easily fix and save on cost. QA role comes after the System Test stage. How much time and money will be spent fixing at that stage? We need to collaborate with sw developers from the beginning.
- I would like to explain the two types of sw development process. First there is the “waterfall” type and second is the “Agile” type. In the case of waterfall, each step has to be completed before we continue with the next step. Also, each of the 4 steps uses 25% of company’s resources. So, in the Traditional process, after analysis and design (50% of resources used) documentation can be produced. Moreover, after testing (all resources have been used) is When the customer can view the product and provide feedback. Do you see the problem with this process? We end up utilizing all resources before we can provide A product and receive feedback from the customer. At this point, if the customer needs any changes, then the company has already used all resources and changes are more Difficult to implement. In the case of “Agile”, we try to deliver features to the customer as soon as possible and based on the priorities of customers. We can focus on the customer’s priorities first and deliver the features in a short period of time. Because of this, customers can give feedback at every stage of the sw development process. The customer would be able to use the product at each stage in the Agile process, providing true value for the customer. However, in the waterfall, customers can only use product after the testing stage. In addition, in the Agile process, we can apply any changes made by customers at each stage. Therefore saving time and cost, and also increasing customer’s overall satisfaction. Can you see any other differences between “waterfall” and “agile” processes? Yes, the testing stage comes before the coding stage in the agile process. We first build an automated test to verify production code. Then we develop production code to pass that test.
- Let’s see what is required for Agile testing. There are 4 quadrants; Technology Facing, Business Facing, Supporting Team & Critique Product. In the first quadrant there are unit tests and component tests. Unit tests are for used to help sw developers to “build it right”. By this, I mean to provide quality code that Is free of defects and must be automated and run frequently as the code changes. Up until now, people believed that only developers wrote unit tests. But this must be changed. As you can see in these quadrants, QA has the perspective of the Critique Product. This Critique Code is needed in the Unit Tests. As you know, it is difficult to self-critique during Coding. So QA provides this Critique for Production Code. To do this, QA must know how to code. In the second quadrant it’s about Functional Tests. Acceptance Test Driven Development (ATDD) is required for this quadrant. It must be automated, however if there is a small aspect that is hard to automate, then only use manual tests for that situation. QA write tests for Critique purposes and developers write tests for building purposes. The first 2 quadrants should be emphasized and are fundamental for QA and developers. The last 2 quadrants are similar with other processes.
- QA and SW engineers have almost the same fundamental skill sets; they must know how to code and how to build sw. But the must have a different perspective. QA has the Critique Perspective for the product. This is the key difference between QA and developers. QA has the ability to prevent defects in the code, whereas developers have difficulty To self-critique.
- Developers and QA must collaborate in coding and testing. Working separately has not been effective, so let’s break down that wall and work together.
- Kent Beck introduced XP Practices, which has 3 layers. Let’s focus on the fundamental layer; it is the core. It consists of …….. Test-driven Development is where we write the test first then write the code that can only pass that test. Refactoring is A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior. To prevent the changing of the observable behavior, we need the unit test. If there is no unit test, it’s hard to detect if there was a change in observable behavior. We must always choose Simple Design because it is easiest to understand and maintain. Unit tests and Refactoring assist us to help make an better and Simple Design. Pair Programming means code review. This offers support to write better code, similar to editing. This should happen in Real Time, saving resources and avoiding defects. These core practices are not only necessary for developers, but as well as QA. They must participate with this practice.
- Until now, we have only discussed participation during the coding stage. But, if we can progress forward to analysis and design, we can create more value.
- Let’s think about the traditional sw development processes. BA does analysis independantly and then hands over to DEV. DEV writes code independantly and then hands over to QA. We can compare this to the “Telephone Game”, which as you know, causes many miscommunications. Have you ever experienced the problem of a customer telling you “This is not what I asked for” after QA finished? This happened because of this traditional process. Every role uses their own language to communicate, which raises problems in Overall communication.
- Moreover, in the specification, they only explain the final goal. However, they don’t explain why it is required. For example, an F-16 is a type of plane. The first requirement of an F-16 is To be built cheaply but with Mach 2.5 speed. But if we have to achieve Mach 2.5 speed, high spending is required. Also, there is no explanation for the requirement of this maximum speed in the specifications. So, the engineers of the F-16 asked the customers “why do you need Mach 2.5 speed?”. The customer replied “In order to escape dangerous situations faster.” Instead of increasing maximum speed, acceleration and maneuverability was the solution. With this example, you can see that specifications do not always meet with customer’s requirements. Specification must explain “why” then all participants can find a best solution by collaborating.
- Examples are given to create easier understanding for Acceptance Criteria. If we combine Acceptance Criteria and Examples it becomes Acceptance Test. Once we have the Acceptance Test we can use this as specifications. We can use real life examples rather than written specifications. This helps collaboration between clients and sw engineers, BA, etc.
- ATDD & BDD means to build Acceptance Test first, then create Production Code after. Here are some simple steps for ATDD & BDD BA, QA and sw engineers get together and create as many real world examples as possible. Examples of these are selected to be a specification. And then that specification needs to be automated. Then developers can focus on passing the Acceptance Test, which is more effective to prevent defects And “just in case” code. If any specifications need to be changed or fixed, this can be done via the Acceptance Test.
- Examples can become tests, and tests verify requirements and examples elaborate requirements. According to Robert Martin, requirements, tests become Indistinguishable. The tests become the requirements itself.
- With the Automated Test, the Acceptance Test becomes the Executable Specification. In comparison to written specification, where we need to manually Read and understand and verify. With Executable Specification we can get instant results.
- We need to hold a specification workshop. BA, QA and sw engineers all need to attend and create Acceptance Criteria in collaboration. At the beginning of the Iteration, they need to Automate Acceptance Test. Our final goal being code that passes a Automated Acceptance Test. If all Automated Acceptance Tests are successful it means we developed the Feature properly. From this ATDD cycle, we can build quality from the beginning of the process. This means changing the role of QA. In the waterfall process, QA means just detecting defects. In this process, QA builds executable specification and defect prevention.
- In summary, I want to emphasize that QA needs to change their role in order to build quality. I will explain 2 important activities.
- This first activity is to “move upstream”. Many companies still implement the waterfall process. In these situations, we can not simply apply agile process. So, QA needs to participate in early stages, compared to only the final stage. The more that QA is involved with other stages, for example, coding, the more value will be added. It is not necessary to completely change to Agile Process, so we shouldn’t just give up. We should keep pushing forward and start with smaller Changes.
- QA has lost their DEV skills over time. We need to get these skills back and continuously hone these skills. Only then can QA participate in the code stage and We can keep pushing forward.
- Change and improvement starts with ourselves. Once we get back our DEV skills (defect prevention, etc.) we then can apply to our own work. Once you have confidence, this can be spread to colleagues. This is how we evolve. Q: What kind of testing framework is used? A: In the case of Acceptance Tests,