This document provides an overview of managing software debt in practice, with a focus on quality debt. It discusses the different types of software debt including technical, quality, configuration management, design, and platform experience. It emphasizes the importance of asserting quality through practices like having a clear definition of done and implementing test automation. The document outlines how one team significantly reduced their testing costs from $17,000 to $7,000 per iteration by introducing the Fit framework and automating their regression tests.
Building Mobile (app) Masterpiece with Distributed AgileWee Witthawaskul
The document discusses how the speaker built a distributed agile team to develop a successful mobile app for Morningstar for iPad. Key points include:
- The project started in 2011 and involved developing concurrently for iOS and a Java backend.
- The team implemented agile practices like continuous integration, automated testing, and tracking work in JIRA to facilitate distributed development.
- The app launched in 2013 and became a top 10 finance app, demonstrating the effectiveness of their distributed agile approach to mobile development.
The document provides information about manual testing processes and concepts. It discusses 1) why manual testing is chosen as a career, 2) the skills needed to get a manual testing job, 3) when testing occurs in the software development lifecycle, and 4) the different types and levels of testing. It also defines key terms like requirements documents, test cases, defects, environments, and software development process models.
The document discusses CAI's Vericenter, a center of excellence for software quality and testing. It provides full-service testing solutions to improve software quality through expertise in processes, tools, and project management. The goal is to optimize resources, reduce risks, and deliver results through comprehensive system, user, integration, and data testing. CAI's approach utilizes leading tools and techniques and leverages experienced staff to shorten the testing process, increase quality and performance, and decrease costs.
Agile Software Development in Practice - A Developer PerspectiveWee Witthawaskul
This document provides an overview of agile software development practices from a developer perspective. It recommends adopting agile practices to increase productivity and recommends Scrum and XP as agile frameworks. It describes common agile practices like user stories, daily standups, iteration planning, testing practices like TDD, mocks and continuous integration to automate testing.
This document discusses software quality, including defining quality, achieving it through processes and tools, and assuring it through testing and metrics. It outlines preventing and finding defects, and the relationship between people, processes, and tools. Quality is achieved through standards, methods, and preventing defects, while being assured through reviews, testing, and metrics programs. Defects are defined and categorized, and processes for finding, removing, and preventing them are described.
This document discusses Behavior Driven Development (BDD), which is an agile software development methodology that focuses on defining and testing business requirements through executable specifications and acceptance criteria. The document covers the key concepts of BDD, including outside-in development, pull-based planning, and defining behavior through user stories and scenarios. It also discusses how BDD compares to other techniques like test-driven development and finite state machines. The overall goal of BDD is to facilitate collaboration between developers and business stakeholders to build the right product through living documentation of desired behaviors.
Marrying Jenkins and Gerrit-Berlin Expert Days 2013Dharmesh Sheta
The document discusses marrying Gerrit and Jenkins to improve the code review process. Gerrit is a widely used Git server and code review tool. Jenkins is a popular open source continuous integration tool. By connecting Gerrit and Jenkins, developers can ensure code review requests meet quality standards before review by having Jenkins automatically build and test code changes and report the results in Gerrit. This allows code review to focus on design and avoids wasted time on requests that fail builds or tests. The document then demonstrates this workflow with Gerrit and Jenkins.
Building Mobile (app) Masterpiece with Distributed AgileWee Witthawaskul
The document discusses how the speaker built a distributed agile team to develop a successful mobile app for Morningstar for iPad. Key points include:
- The project started in 2011 and involved developing concurrently for iOS and a Java backend.
- The team implemented agile practices like continuous integration, automated testing, and tracking work in JIRA to facilitate distributed development.
- The app launched in 2013 and became a top 10 finance app, demonstrating the effectiveness of their distributed agile approach to mobile development.
The document provides information about manual testing processes and concepts. It discusses 1) why manual testing is chosen as a career, 2) the skills needed to get a manual testing job, 3) when testing occurs in the software development lifecycle, and 4) the different types and levels of testing. It also defines key terms like requirements documents, test cases, defects, environments, and software development process models.
The document discusses CAI's Vericenter, a center of excellence for software quality and testing. It provides full-service testing solutions to improve software quality through expertise in processes, tools, and project management. The goal is to optimize resources, reduce risks, and deliver results through comprehensive system, user, integration, and data testing. CAI's approach utilizes leading tools and techniques and leverages experienced staff to shorten the testing process, increase quality and performance, and decrease costs.
Agile Software Development in Practice - A Developer PerspectiveWee Witthawaskul
This document provides an overview of agile software development practices from a developer perspective. It recommends adopting agile practices to increase productivity and recommends Scrum and XP as agile frameworks. It describes common agile practices like user stories, daily standups, iteration planning, testing practices like TDD, mocks and continuous integration to automate testing.
This document discusses software quality, including defining quality, achieving it through processes and tools, and assuring it through testing and metrics. It outlines preventing and finding defects, and the relationship between people, processes, and tools. Quality is achieved through standards, methods, and preventing defects, while being assured through reviews, testing, and metrics programs. Defects are defined and categorized, and processes for finding, removing, and preventing them are described.
This document discusses Behavior Driven Development (BDD), which is an agile software development methodology that focuses on defining and testing business requirements through executable specifications and acceptance criteria. The document covers the key concepts of BDD, including outside-in development, pull-based planning, and defining behavior through user stories and scenarios. It also discusses how BDD compares to other techniques like test-driven development and finite state machines. The overall goal of BDD is to facilitate collaboration between developers and business stakeholders to build the right product through living documentation of desired behaviors.
Marrying Jenkins and Gerrit-Berlin Expert Days 2013Dharmesh Sheta
The document discusses marrying Gerrit and Jenkins to improve the code review process. Gerrit is a widely used Git server and code review tool. Jenkins is a popular open source continuous integration tool. By connecting Gerrit and Jenkins, developers can ensure code review requests meet quality standards before review by having Jenkins automatically build and test code changes and report the results in Gerrit. This allows code review to focus on design and avoids wasted time on requests that fail builds or tests. The document then demonstrates this workflow with Gerrit and Jenkins.
The document discusses real world test-driven development (TDD). It addresses several myths about TDD, such as that it only involves writing unit tests before code or is only for new code. The document advocates for writing tests at multiple levels, including unit, integration, and deployment tests. It also emphasizes that test code quality is important and recommends integrating developers and testers, building walking skeletons before features, and using continuous integration practices. The overall message is that there are different ways to approach TDD effectively in the real world.
Ravit Danino HP - Roles and Collaboration in AgileAgileSparks
Roles and collaboration have changed in Agile. Entire teams now work together throughout a sprint rather than having separate roles confined to specific phases. The whole team, including developers, business analysts, testers, and documentation specialists, collaborates continuously. They plan iterations together, provide feedback to each other, and ensure code meets quality standards through coffee and end-to-end testing. With Agile, customers also become key enablers by providing early feedback to help shape requirements and the product.
The document discusses Source2VALUE, a software solution called CARE that provides computer aided redocumentation and evaluation of source code. CARE analyzes source code to provide metrics, detect changes, clones, and violations of standards and guidelines. It generates documentation and reports to help reduce software maintenance costs, improve transparency, and support auditing. A demo of the CARE approach and Source2VALUE portal is then presented.
This document discusses how to integrate Scrum and Behavior Driven Development (BDD). It recommends starting with refining the product backlog by splitting user stories, defining acceptance criteria through examples, and collaborating with stakeholders. Examples show how to write specifications using the Given-When-Then format. The document emphasizes starting each sprint by writing automated tests based on the specifications before writing code. This ensures the team builds the right product by focusing on delivering value through small, testable increments.
This document provides an overview of agile software development methods. It defines agile as developing software incrementally in rapid cycles with close customer collaboration. The agile manifesto values individuals, working software, customer collaboration, and responding to change. Popular agile methods described include scrum, extreme programming (XP), test-driven development (TDD), and lean. Scrum uses short iterations called sprints, with roles like product owner and scrum master. XP advocates frequent releases and pair programming. TDD involves writing tests before code. Lean aims to maximize value while minimizing waste. Agile frameworks help teams deliver faster with less risk by focusing on customer value.
This document outlines a Lean Six Sigma project to improve quality in the machine shop and brazing area of a rollator manufacturing process. The project aims to reduce dimensional variation in rollator frames and crossbars to decrease defects like cross folding and three wheeling. Success would mean an 80% reduction in rework/scrap and meeting delivery, production, and WIP reduction targets. Baseline data on outputs like scrap rates is available but more data needs to be collected from the processes to understand the root causes of variation. Completing new process controls in 4-6 months seems feasible if required equipment investments are approved. Stakeholders include suppliers, various process areas, customers, and others.
The document discusses the SQALE method for evaluating source code quality. SQALE was developed by experts independent of any tool vendor to provide an objective, precise method that avoids issues like false positives. It promotes evaluating quality by measuring the remaining work needed to fix issues. SQALE provides a standardized model that can be tailored to different languages and criticality levels, and gives guidance on remediation priorities.
Evolving the Product Management Process to Match Company GrowthSVPMA
The document discusses evolving a product management process to match company growth. It proposes combining elements of waterfall and agile methodologies. The hybrid approach emphasizes predictability from waterfall with adaptability from agile. It incorporates frequent customer feedback and testing. Project teams work in time boxes to incrementally deliver prioritized features through defined phases like concept, definition, design, development, certification and launch.
RenditionDigital provides end-to-end software development solutions including business process analysis, architecture and design, coding, testing, integration, and project management. They have experience in business applications, embedded systems, product development and maintenance, web development, testing, and mobile app development for iOS and Android. RenditionDigital helps fill clients' resource gaps and supports the entire product lifecycle.
Building In Quality: The Beauty Of Behavior Driven Development (BDD)Synerzip
Behavior Driven Development (BDD) began as a means of helping developers practice Test Driven Development (TDD).
In this it was successful, but it quickly proved its value in many other ways. In this presentation, Larry Apke quotes heavily from the work of Uncle Bob Martin to make the case for TDD and then explains how developers can use BDD to take advantage of this excellent software development practice.
Larry also talks about his “Ten Reasons BDD Changes Everything” along with some easy ways to begin implementation of BDD in your software development organization immediately and what the corresponding future steps would be to take full advantage of this technique.
This document discusses how to bake quality into an agile scrum model. It covers quality driven by scrum practices like short iterations and frequent course corrections. It also discusses quality of requirements, architecture/design, code, verification/testing and maturing the definition of done. Automated testing, code reviews, continuous integration and refactoring are recommended to ensure code quality. Quality is baked in through quality user stories, engineering standards/best practices, exploratory testing and peer reviews.
The document discusses efficient verification methodology. It recommends defining a conceptual framework or methodology to standardize some aspects while allowing diversity. The methodology should define interfaces and transactions upfront using an interface definition language to generate verification components and reusable assertions. It also recommends modeling systems at the transaction level using executable specifications to frontload the verification schedule.
My talk at PMI Sweden Congress 2013 on Agile and Large Software ProductsSvante Lidman
This is my "Success Factors for Agile Development of Very Large Software Products" as it was presented at the PMI Sweden Congress on March 11 2013. The title of the presentation is in Swedish but the material is almost completely in English.
This document discusses software design using agile methods. It begins by discussing technical debt, where shipping incomplete code is like taking on debt that accrues interest over time. It then discusses how agile embraces changes and focuses on enabling software to be changed easily through practices like automated testing, decoupling code, and refactoring. Refactoring is described as restructuring code without changing its external behavior in order to improve design and remove bad smells. The conclusion emphasizes that agile practices help keep the cost of changes low throughout the project lifecycle.
This document outlines the software quality plan for an airline reservation system project. It discusses roles in quality assurance including developers writing unit tests, an on-site customer for acceptance testing, and QA ensuring quality and functionality. It also covers risk management, prioritizing use cases, infrastructure and component testing for the application server, database, OS, and hardware. User acceptance testing approaches are defined using test tools and test scenarios from user stories. Training and disaster recovery plans are also summarized.
Shirly Ronen - rapid release flow and agile testing-asAgileSparks
This document describes a rapid agile release flow with three types of releases:
1. CR or production change requests that upload user stories daily to production for testing without releasing to customers.
2. A business release that takes all CRs and makes them available internally but not yet to customers.
3. A station-customer release that releases a group of features to customers after preparations like documentation.
It discusses splitting production from customer releases, freezing user stories and code at different stages, and performing various tests during the process.
The document discusses software quality and quality models. It provides an overview of ISO 9126, a standard for evaluating software quality. ISO 9126 defines six main quality characteristics: functionality, reliability, usability, efficiency, maintainability, and portability. Each characteristic has sub-characteristics and attributes that further define aspects of software quality. The document also discusses other quality models like Boehm's model and McCall's model, as well as perspectives from users, developers, and managers.
Shirly Ronen - User story testing activitiesAgileSparks
The document discusses testing user stories throughout the development process from planning through deployment. It emphasizes testing early by writing automated unit tests during development. Testers work closely with developers to understand the approach and test in the development environment. This helps find defects early and prevent issues. The goal is to deliver working software through continuous testing, including acceptance criteria, exploratory testing, automation, and regression testing.
The document discusses the purpose and activities of Iteration 0 in an agile development process. It describes setting up key infrastructure items like version control, IDE configuration, build systems, continuous integration, and project management tools. It emphasizes automating as many tasks as possible. The goal of Iteration 0 is to establish the foundation for subsequent iterations by creating a stable development environment and processes.
IP Reuse Impact on Design Verification Management Across the EnterpriseDVClub
The document discusses challenges with IP reuse dependency management across hardware design projects. It notes that verification reuse is often neglected and that finding and fixing issues on complex projects can be difficult without proper dependency tracing of IP instances, designs, and versions. The presentation recommends establishing processes and checklists for IP verification and design history tracking to facilitate reuse. It also shares survey results about the organizational impacts of improved IP reuse dependency management, such as more efficient engineering resource usage and 30% faster time to market.
The document discusses managing software debt through continuous quality assurance practices. It covers different types of software debt like technical debt, quality debt, and design debt. It emphasizes establishing clear definitions of done for tasks and releases to assert quality. Automating tests through practices like test-driven development and continuous integration can significantly reduce costs by making testing more efficient. Focusing on quality practices upfront helps reduce technical barriers and costs of making changes over the long run.
Raghwinder Parshad is a software quality assurance professional with over 2.6 years of experience in manual testing, test planning, execution, and results analysis. He has expertise in testing web, desktop, and mobile applications on various platforms. Some of the projects he has worked on include Promo Manager for NBC Universal, Programming Deal Memo for GE NBCUniversal, and Non-Programming Tool. He is proficient with tools like HP ALM, JIRA, and Mantis. Raghwinder holds a Bachelor of Technology degree and is looking to build his career in a leading corporate environment.
The document discusses real world test-driven development (TDD). It addresses several myths about TDD, such as that it only involves writing unit tests before code or is only for new code. The document advocates for writing tests at multiple levels, including unit, integration, and deployment tests. It also emphasizes that test code quality is important and recommends integrating developers and testers, building walking skeletons before features, and using continuous integration practices. The overall message is that there are different ways to approach TDD effectively in the real world.
Ravit Danino HP - Roles and Collaboration in AgileAgileSparks
Roles and collaboration have changed in Agile. Entire teams now work together throughout a sprint rather than having separate roles confined to specific phases. The whole team, including developers, business analysts, testers, and documentation specialists, collaborates continuously. They plan iterations together, provide feedback to each other, and ensure code meets quality standards through coffee and end-to-end testing. With Agile, customers also become key enablers by providing early feedback to help shape requirements and the product.
The document discusses Source2VALUE, a software solution called CARE that provides computer aided redocumentation and evaluation of source code. CARE analyzes source code to provide metrics, detect changes, clones, and violations of standards and guidelines. It generates documentation and reports to help reduce software maintenance costs, improve transparency, and support auditing. A demo of the CARE approach and Source2VALUE portal is then presented.
This document discusses how to integrate Scrum and Behavior Driven Development (BDD). It recommends starting with refining the product backlog by splitting user stories, defining acceptance criteria through examples, and collaborating with stakeholders. Examples show how to write specifications using the Given-When-Then format. The document emphasizes starting each sprint by writing automated tests based on the specifications before writing code. This ensures the team builds the right product by focusing on delivering value through small, testable increments.
This document provides an overview of agile software development methods. It defines agile as developing software incrementally in rapid cycles with close customer collaboration. The agile manifesto values individuals, working software, customer collaboration, and responding to change. Popular agile methods described include scrum, extreme programming (XP), test-driven development (TDD), and lean. Scrum uses short iterations called sprints, with roles like product owner and scrum master. XP advocates frequent releases and pair programming. TDD involves writing tests before code. Lean aims to maximize value while minimizing waste. Agile frameworks help teams deliver faster with less risk by focusing on customer value.
This document outlines a Lean Six Sigma project to improve quality in the machine shop and brazing area of a rollator manufacturing process. The project aims to reduce dimensional variation in rollator frames and crossbars to decrease defects like cross folding and three wheeling. Success would mean an 80% reduction in rework/scrap and meeting delivery, production, and WIP reduction targets. Baseline data on outputs like scrap rates is available but more data needs to be collected from the processes to understand the root causes of variation. Completing new process controls in 4-6 months seems feasible if required equipment investments are approved. Stakeholders include suppliers, various process areas, customers, and others.
The document discusses the SQALE method for evaluating source code quality. SQALE was developed by experts independent of any tool vendor to provide an objective, precise method that avoids issues like false positives. It promotes evaluating quality by measuring the remaining work needed to fix issues. SQALE provides a standardized model that can be tailored to different languages and criticality levels, and gives guidance on remediation priorities.
Evolving the Product Management Process to Match Company GrowthSVPMA
The document discusses evolving a product management process to match company growth. It proposes combining elements of waterfall and agile methodologies. The hybrid approach emphasizes predictability from waterfall with adaptability from agile. It incorporates frequent customer feedback and testing. Project teams work in time boxes to incrementally deliver prioritized features through defined phases like concept, definition, design, development, certification and launch.
RenditionDigital provides end-to-end software development solutions including business process analysis, architecture and design, coding, testing, integration, and project management. They have experience in business applications, embedded systems, product development and maintenance, web development, testing, and mobile app development for iOS and Android. RenditionDigital helps fill clients' resource gaps and supports the entire product lifecycle.
Building In Quality: The Beauty Of Behavior Driven Development (BDD)Synerzip
Behavior Driven Development (BDD) began as a means of helping developers practice Test Driven Development (TDD).
In this it was successful, but it quickly proved its value in many other ways. In this presentation, Larry Apke quotes heavily from the work of Uncle Bob Martin to make the case for TDD and then explains how developers can use BDD to take advantage of this excellent software development practice.
Larry also talks about his “Ten Reasons BDD Changes Everything” along with some easy ways to begin implementation of BDD in your software development organization immediately and what the corresponding future steps would be to take full advantage of this technique.
This document discusses how to bake quality into an agile scrum model. It covers quality driven by scrum practices like short iterations and frequent course corrections. It also discusses quality of requirements, architecture/design, code, verification/testing and maturing the definition of done. Automated testing, code reviews, continuous integration and refactoring are recommended to ensure code quality. Quality is baked in through quality user stories, engineering standards/best practices, exploratory testing and peer reviews.
The document discusses efficient verification methodology. It recommends defining a conceptual framework or methodology to standardize some aspects while allowing diversity. The methodology should define interfaces and transactions upfront using an interface definition language to generate verification components and reusable assertions. It also recommends modeling systems at the transaction level using executable specifications to frontload the verification schedule.
My talk at PMI Sweden Congress 2013 on Agile and Large Software ProductsSvante Lidman
This is my "Success Factors for Agile Development of Very Large Software Products" as it was presented at the PMI Sweden Congress on March 11 2013. The title of the presentation is in Swedish but the material is almost completely in English.
This document discusses software design using agile methods. It begins by discussing technical debt, where shipping incomplete code is like taking on debt that accrues interest over time. It then discusses how agile embraces changes and focuses on enabling software to be changed easily through practices like automated testing, decoupling code, and refactoring. Refactoring is described as restructuring code without changing its external behavior in order to improve design and remove bad smells. The conclusion emphasizes that agile practices help keep the cost of changes low throughout the project lifecycle.
This document outlines the software quality plan for an airline reservation system project. It discusses roles in quality assurance including developers writing unit tests, an on-site customer for acceptance testing, and QA ensuring quality and functionality. It also covers risk management, prioritizing use cases, infrastructure and component testing for the application server, database, OS, and hardware. User acceptance testing approaches are defined using test tools and test scenarios from user stories. Training and disaster recovery plans are also summarized.
Shirly Ronen - rapid release flow and agile testing-asAgileSparks
This document describes a rapid agile release flow with three types of releases:
1. CR or production change requests that upload user stories daily to production for testing without releasing to customers.
2. A business release that takes all CRs and makes them available internally but not yet to customers.
3. A station-customer release that releases a group of features to customers after preparations like documentation.
It discusses splitting production from customer releases, freezing user stories and code at different stages, and performing various tests during the process.
The document discusses software quality and quality models. It provides an overview of ISO 9126, a standard for evaluating software quality. ISO 9126 defines six main quality characteristics: functionality, reliability, usability, efficiency, maintainability, and portability. Each characteristic has sub-characteristics and attributes that further define aspects of software quality. The document also discusses other quality models like Boehm's model and McCall's model, as well as perspectives from users, developers, and managers.
Shirly Ronen - User story testing activitiesAgileSparks
The document discusses testing user stories throughout the development process from planning through deployment. It emphasizes testing early by writing automated unit tests during development. Testers work closely with developers to understand the approach and test in the development environment. This helps find defects early and prevent issues. The goal is to deliver working software through continuous testing, including acceptance criteria, exploratory testing, automation, and regression testing.
The document discusses the purpose and activities of Iteration 0 in an agile development process. It describes setting up key infrastructure items like version control, IDE configuration, build systems, continuous integration, and project management tools. It emphasizes automating as many tasks as possible. The goal of Iteration 0 is to establish the foundation for subsequent iterations by creating a stable development environment and processes.
IP Reuse Impact on Design Verification Management Across the EnterpriseDVClub
The document discusses challenges with IP reuse dependency management across hardware design projects. It notes that verification reuse is often neglected and that finding and fixing issues on complex projects can be difficult without proper dependency tracing of IP instances, designs, and versions. The presentation recommends establishing processes and checklists for IP verification and design history tracking to facilitate reuse. It also shares survey results about the organizational impacts of improved IP reuse dependency management, such as more efficient engineering resource usage and 30% faster time to market.
The document discusses managing software debt through continuous quality assurance practices. It covers different types of software debt like technical debt, quality debt, and design debt. It emphasizes establishing clear definitions of done for tasks and releases to assert quality. Automating tests through practices like test-driven development and continuous integration can significantly reduce costs by making testing more efficient. Focusing on quality practices upfront helps reduce technical barriers and costs of making changes over the long run.
Raghwinder Parshad is a software quality assurance professional with over 2.6 years of experience in manual testing, test planning, execution, and results analysis. He has expertise in testing web, desktop, and mobile applications on various platforms. Some of the projects he has worked on include Promo Manager for NBC Universal, Programming Deal Memo for GE NBCUniversal, and Non-Programming Tool. He is proficient with tools like HP ALM, JIRA, and Mantis. Raghwinder holds a Bachelor of Technology degree and is looking to build his career in a leading corporate environment.
Agile Testing: The Role Of The Agile TesterDeclan Whelan
This presentation provides an overview of the role of testers on agile teams.
In essence, the differences between testers and developers should blur so that focus is the whole team completing stories and delivering value.
Testers can add more value on agile teams by contributing earlier and moving from defect detection to defect prevention.
The document discusses quality assurance and testing in software development. It recommends establishing a quality assurance framework that incorporates source code management, continuous integration, code reviews, and continuous inspection tools like SonarQube. This helps automate the development process, reduce technical debt, and prevent bugs by finding and fixing issues early. Tracking key metrics also allows measuring the costs of quality problems versus prevention activities.
The document discusses quality assurance and testing in software development. It emphasizes the importance of establishing a quality assurance process that incorporates code reviews, continuous integration, and tools like SonarQube to measure code quality and technical debt. Having this framework helps prevent bugs, catch issues early, and ensures code quality throughout the development lifecycle to reduce costs associated with fixing defects later.
This document discusses various metrics that can be used to measure agile processes. It begins by defining what a metric is and explaining common process improvement cycles. It then outlines different categories of metrics including business, process, code, design, testing, and automation metrics. Examples are provided for each category. The document notes that choosing the right metric is important and should encourage desired behavior, be easy to measure, and provide periodic feedback. It emphasizes that both leading and lagging metrics should be considered to measure productivity, predictability, quality, and value.
This presentation describes Agile development practices as well as the requirements for building secure applications. It examines ways that teams can incorporate security into Agile development projects to successfully meet the goals of both.
What CS Class Didn't Teach About TestingCamille Bell
Computer Science classes don't teach testing. Testing is as critical to software engineering as writing code. Here I show what CS programs should have taught, but didn't.
Adressing requirements with agile practicesfboisvert
This document discusses addressing non-functional requirements with agile practices. It defines non-functional requirements as specifying "how well" functional requirements must behave by imposing constraints. The document recommends breaking down non-functional requirements into internal "rules" that guide software construction and external "restrictions" that are tested. It provides examples of expressing functional requirements as user stories and scenarios for clarity. The document advocates using techniques like pair programming and peer review to confirm rules are followed, and testing to confirm restrictions are met. This ensures both internal and external quality expectations are satisfied.
This document discusses various iterative software development models, including the spiral model, win-win spiral model, and cleanroom methodology. The spiral model is risk-driven and involves iterating through phases of planning, risk assessment, engineering, and evaluation. The win-win spiral model seeks to reconcile stakeholder objectives through negotiation. Cleanroom methodology emphasizes technical reviews, incremental development, and testing to reduce defects. Alternative models like hacking are also discussed for low-risk or disposable projects. Overall, the iterative models attempt to address limitations of the traditional waterfall model by incorporating feedback loops, prototyping, and incremental delivery.
Scrum is a framework for managing product development that emphasizes iterative work cycles, frequent inspection points, and adaptation to change. It consists of sprints, daily stand-ups, sprint planning, reviews, and retrospectives. Benefits include increased responsibility, reduced risk, motivation, and continuous improvement. However, it can also be verbose with meetings and interrupt development flow if not implemented properly.
Agile testing principles and practices - Anil KaradeIndicThreads
Traditional test processes are not adaptive to extensive changes in software. Agile process emphasizes on ability to adapt to changing business needs, customer collaboration, integrated teams and frequent delivery of business values. Agile is an umbrella term that describes a variety of methods including XP and Scrum.
The talk will discuss pitfalls of the traditional testing process. Traditional testing process happens very late in the SDLC Where as Agile process focuses on test-first approach. The talk will explain benefits of going agile. Principles and practices of agile process will be discussed and agile methodologies Scrum and Extreme Programming will be discussed in detail. Purpose of Scrum, its effectiveness, timings and managing the scrum will be discussed. Some of the practices for XP like Pair Programming, Test Driven Development will be discussed. The Talk will also cover the QA role in agile world. The talk will cover the implementation issues while shifting from traditional to agile process. Talk will also include an interactive game for illustration of concepts.
Backward thinking design qa system for quality goalsgaoliang641
This document discusses strategies for designing a quality assurance system to meet quality goals. It outlines various types of testing, such as user testing, integration testing, and performance testing. It also poses many questions about testing organization, processes, tools, and metrics that need to be considered when setting up a QA system. The document emphasizes establishing repetitive regression testing to stabilize code branches before release and using automation to help reduce the workload of testing.
Ben Walters - Creating Customer Value With Agile Testing - EuroSTAR 2011TEST Huddle
EuroSTAR Software Testing Conference 2011 presentation on Creating Customer Value With Agile Testing by Ben Walters. See more at: http://conference.eurostarsoftwaretesting.com/past-presentations/
This document discusses creating a plan for ongoing internationalization and localization efforts. It recommends conducting an initial assessment of code and requirements to understand what is and isn't internationalized. It also suggests creating an actionable plan with tasks, schedule, staffing, and costs. For ongoing efforts, it advises measuring internationalization as part of regular development processes, leveraging tools to catch bugs early, and focusing on expertise through training and collaboration with specialists.
Dollars and dates are killing agile finaldrewz lin
This document discusses how dollars and dates can kill agility in software development. It proposes a three year agile business roadmap to address these issues. Year 1 focuses on reducing carryover by identifying issues sooner. Year 2 optimizes the project portfolio by increasing value to cost ratio and lowering compliance costs. Year 3 moves to incremental funding and uses experimentation, feedback, and portfolio optimization techniques like commit/transform/kill. The document emphasizes the importance of balancing constraints, value, quality and adapting planning as complexity requires.
Agile teams speak in points and iterations, but project and business managers think in terms of dollars and dates. This conceptual and language barrier makes strategic business planning, funding, and progress management a significant challenge for sustained large-scale Agile. This session will include multiple case studies from large-scale Agile adoptions that we were part of and have supported over the past 7 years and how Agile values/principles went beyond just the development organizational boundaries into strategic planning and management.
Project backup repository and avoiding requirements creepAswin Vijayakumar
Requirements Engineering to use a backup repository to develop a software project management methodology used within Agile. Fit Criterion, Refinery, Traceability and Deployment are key techniques
This document discusses quality assurance in an agile development environment. Some key points:
- In agile, quality is a team responsibility built into each sprint through practices like test-driven development and continuous integration. QA focuses on working software rather than documentation.
- Traditional QA tested after development, but agile QA works throughout development. Automated testing and continuous integration allow for faster feedback.
- The "definition of done" ensures quality standards are met before work is considered complete. This includes things like testing, documentation, and business verification of requirements.
- Metrics like burn-down charts are used to track progress and quality over iterations. Visualizing progress helps the team respond quickly to changes.
Let's review it: What designers can learn from (code) reviewIda Aalen
What if designers approached collaboration and critique more like developers? Could it make us better designers, and could it better collaboration between designers and developers? Presented at Yggdrasil 2018 in Sandefjord, Norway
Similar to Managing Software Debt - Quality Debt Focus - QASIG Kirkland (20)
Cloud Native Java with Spring Cloud ServicesChris Sterling
Developing cloud-native applications presents several challenges. How do microservices discover each other? How do you configure them? How can you make them resilient to failure? How can you monitor the health of each microservice?
Spring Cloud addresses all of these concerns. Even so, you still must explicitly develop your own service registry to enable discovery, configuration server, and circuit breaker dashboard for monitoring the circuit breakers in each microservice.
Spring Cloud Services for Pivotal Cloud Foundry picks up where Spring Cloud leaves off, offering an out-of-the-box experience with service registry, configuration server, and circuit breaker dashboard services that can be bound to applications deployed in Pivotal Cloud Foundry. Now developers can focus on developing applications rather than microservices infrastructure. In this talk, we will introduce the capabilities provided by Spring Cloud Services and demonstrate how it makes simple work of deploying cloud-native applications to Cloud Foundry.
Right on the heels of the Manifesto for Agile Software Development, a new movement with the moniker DevOps has further advanced software delivery. Although the Agile software development movement brought iterative and incremental concepts to our industry, in many organizations its reach was relegated to only the application development teams. In many cases, this moved the bottlenecks in organizations from application development to release management, IT operations and business program and portfolio management decision making. This local optimization leads to real world application of Agile software development being perceived as unsuccessful and increased probability of being thrown away for the comfort in the illusions of control of plan-driven approaches.
The promise of DevOps is to further improve our ability to make holistic optimizations from business to software delivery to operations and ultimately increase feedback into our business decision making processes. This promise involves the application of The Three Ways as described by Gene Kim: Flow, Feedback and Continuous Experimentation and Learning. Even for those that were able to take advantage of Agile software development we can not sit on our laurels. We must embrace continuous improvement in order to fend off the effects of “Software is Eating the World” as Marc Andreessen pronounced. DevOps provides a view on the culture, practices, tools and processes for how valuable software is delivered, operated and evolved to enable competitive advantage.
From Zero to Continuous Validated Learning: Lean Startup on PaaSChris Sterling
The document outlines an example of using Lean Startup techniques to validate assumptions and develop a minimum viable product for a hypothetical service called Team8s.io to coordinate feature teams. It discusses identifying assumptions, developing a landing page MVP to test one assumption with audience participation, measuring results to incorporate learnings, and iterating based on feedback in an agile manner. The goal is to continuously inspect and adapt using scientific methods to build the right product.
Microservices: Aren't Microservices Just SOA?Chris Sterling
The buzz around Microservices has blazed through the software development industry. Questions about whether its just SOA renamed and how micro is “micro” have blocked out the valuable principles of the Microservices architecture approach. This talk will focus on how Microservices architecture principles have extended beyond SOA and enable DevOps and Agile software development.
Reduce Time to Value: Focus First on Configuration Management DebtChris Sterling
The value of software is only potential value until it is in users’ hands. There can be many roadblocks to software getting into those hands. These roadblocks tend to revolve around elaborate deployment pipelines stemming from Configuration Management Debt:
* Over-burdened release engineering and operations teams
* High coupling with centrally managed architecture element/component
* Source control practices that impact delivery velocity
* Too many variations/versions of the software supported in production
* Poor integration processes across architecture components and scaled team delivery
* Too many hand-offs between teams in order to release software to users
* Code changes feel too risky and takes too long to validate before releasing into production
* Poor documentation practices
In organizations that have effective configuration management practices it is common to see deployment pipelines that have a smaller number of hand-offs between teams, architectures that tend to be more malleable, and efficient validation processes. By focusing on reducing Configuration Management Debt it is simpler to identify aspects of the integration and release management process that need to be tackled in order to get working software in the hands of users sooner while reducing the bottlenecks in the organizational processes and practices.
In this session we will discuss specific approaches and examples on how reducing Configuration Management Debt leads to reducing other forms of software debt including:
* Smaller number of hand-offs: Platform Experience Debt
* Malleable architectures: Design Debt
* Efficient validation processes: Quality Debt
* More testable software: Technical Debt
The document provides an overview of a workshop on managing software debt. It discusses various types of software debt including technical debt, quality debt, configuration management debt, design debt, and platform experience debt. It emphasizes the importance of focusing on quality and design through activities like refactoring, test automation, and defining a done approach to prevent further accumulation of software debt over time. The workshop agenda covers topics like continuous integration, quality dashboards, release management, and wrapping up with a discussion of software debt management strategies.
Software debt slowly creeps into software assets if left unnoticed and can slow down delivery in ways that seemed faster initially. Fortunately, modern tools, frameworks, and software development approaches help us manage software debt effectively at a reasonable cost to implement. This program will show ways to recognize software debt in five debt areas so that you can start to manage it.
The document discusses strategies for scaling agile practices in large organizations. It outlines a three year roadmap for organizations to gradually adopt agile, beginning with reducing work carried over between sprints in year one, optimizing project portfolios in year two, and moving to incremental funding in year three. The document also covers techniques for balancing strategic planning needs with adaptive planning, forming meta-scrums to coordinate multiple agile teams, and establishing definitions of done for both individual teams and product releases.
Integrating Quality into Project Portfolio ManagementChris Sterling
Traditionally, projects are managed based on cost, schedule, and scope. This continues to be insufficient and leads to poor outcomes, unsustainable development efforts, quality issues, and software that may meet requirements but not the expectations of users. This talk will go into how organizations can integrate quality and value considerations into their portfolio management strategies leading to less surprises and more valuable outcomes. The talk will go into detail about how Agile, Lean thinking, and Managing Software Debt can give a more holistic view of the project portfolio.
This is a 45 minute presentation I will be delivering at a company-wide meeting to discuss:
* How push-button release was used to help entire enterprise go from 6 month to 1 week release cycles
* How a "No Defect" team policy with ATDD drives greater productivity
The document discusses testing in an Agile context. It presents an agenda on finding issues earlier using Agile methods, the effects of quality debt, definitions of done, quality dashboards, and Agile test and integration strategies like acceptance test-driven development. It also covers managing configuration debt and questions.
This presentation is from Scrum Gathering 2011 in Seattle, WA, USA. Much of the presentation involved showing tools and techniques outside the slide deck along with exercises that the participants would perform for learning purposes.
Managing software debt is important as software ages. There are different types of software debt including technical debt, quality debt, configuration management debt, design debt, and platform experience debt. Managing software debt involves putting feedback mechanisms in place to identify debt and refactor code frequently. Automating tests, evolving tools and infrastructure, improving designs, sharing knowledge across teams, and focusing on quality can help reduce debt and enable continued delivery of high value features as systems age.
This document discusses various topics related to scaling agile practices in organizations. It covers self-organizing teams and how they function through autonomy, self-transcendence, and cross-fertilization. It also discusses patterns for scaling such as component teams, feature teams, virtual architects, integration teams, component shepherds, and team architects. Finally, it discusses multi-level planning from product vision and roadmaps down to sprint planning.
UW Agile CP202 Class 3 Managing Software DebtChris Sterling
The document discusses managing software debt as systems age. It covers different types of software debt including technical debt, quality debt, configuration management debt, design debt, and platform experience debt. The document provides examples of how software debt can creep into systems over time if not properly managed through frequent feedback mechanisms and refactoring code as needed.
The 1st class of Spring Quarter Agile CP202 slides including:
* User Stories
* Acceptance Criteria
* INVEST Model
* Splitting User Stories
* Abuse Stories
The document discusses managing software debt as systems age. It describes different types of software debt including technical debt, quality debt, configuration management debt, design debt, and platform experience debt. It explains how software debt accrues over time and provides examples of how feedback mechanisms can help manage debt in aging software.
The document introduces test-driven development (TDD) and its benefits. It discusses the basic TDD workflow of writing a failing test, implementing just enough code to pass the test, and refactoring code to an acceptable design. Integrating TDD with a team is also covered. While TDD can improve software quality, it requires discipline to implement effectively and faces challenges such as schedule pressure, lack of experience, and legacy code without tests.
3. Chris
Sterling
• Director
of
Engineering
at
Rally
So)ware
in
Kirkland,
WA
office
• Author
of
Book
Managing
So)ware
Debt:
Building
for
Inevitable
Change
• Consults
on
so)ware
technology,
Agile
technical
prac2ces,
Scrum,
and
effec2ve
management
techniques
• Innova2on
Games®
Trained
Facilitator
Email:
csterling@rallydev.com
Web:
hWp://www.rallydev.com
• Cer2fied
Scrum
Trainer
Follow
me
on
TwiWer:
@csterwa
Blog:
hWp://www.geYngagile.com
Hashtag
for
presenta2on:
#swdebt
• Open
Source
Developer
3
4. Agenda
• Managing
So)ware
Debt
• The
3
Amigos
PaWern
Overview
• Test-‐Driven
Design
• So)ware
Debt
Types
• Monitoring
Quality
• Technical
• The
Power
of
2
Scripts
• Quality
• Con2nuous
Integra2on
• Configura2on
Management
• Automated
Promo2on
• Design
• Advanced
Quality
Metrics
• Pla]orm
Experience
Trending
and
Analysis
• Asser2ng
Quality
• Wrap
Up
• Defini2on
of
Done
• So)ware
Debt
Management
Strategy
• Test
Automa2on
• The
No
Defect
Mindset
4
7. Lack
of
emphasis
on
so)ware
quality
aWributes
contributes
to
decay
8. Principle:
No
maWer
what,
the
cost
of
addressing
so)ware
debt
increases
with
2me.
9. Types
of
So)ware
Debt
Technical,
Quality,
Configura2on
Management,
Design,
and
Pla]orm
Experience
10. Why
not
just
call
it
all
Technical
Debt
• Technical
debt
tended
to
focus
more
on
programming
aspects
of
so)ware
delivery
and
le)
out
full
so)ware
development
life
cycle
• Each
type
of
so)ware
debt
can
be
managed
and
monitored
using
different
tools
and
approaches
• Focusing
on
managing
each
type
of
so)ware
debt
simplifies
crea2on
of
an
overall
strategy
that
promotes
holis2c
perspec2ve
10
11. Types
of
So)ware
Debt
• Technical
Debt:
These
are
the
ac2vi2es
that
a
team
or
team
members
take
shortcuts
on
now
that
will
impede
future
development
if
le)
as
is.
• Quality
Debt:
There
is
a
diminishing
ability
to
verify
the
func2onal
and
technical
quality
of
so)ware:
the
Break/Fix
mentality.
• Configura2on
Management
Debt:
Integra2on
and
release
management
become
more
risky,
complex,
and
error-‐prone.
• Design
Debt:
The
cost
of
adding
features
is
increasing
toward
the
point
where
it
is
more
than
the
cost
of
wri2ng
from
scratch.
• Pla]orm
Experience
Debt:
The
availability
and
alignment
of
people
to
business
objec2ves
that
involve
so)ware
changes
is
becoming
more
limited
or
cost-‐prohibi2ve.
8
12. Asser2ng
Quality
Teams
must
focus
on
asser2ng
sustainable
quality
to
support
future
customer
needs
in
a
2mely
manner
13. Defini2on
of
Done
So)ware
developments
assert
what
finished,
working
so)ware
entails
to
support
predictable
delivery
into
the
future
14. Defini2on
of
Done
-‐
Assert
Quality
" Acceptance defined criteria for each " Tested on FE
user story
" Integration test written & passes
" Unit tests written and passed
" Test code reviewed
" Code compiles with no errors and no
" Environment requirements documented
warnings
" New code doesn t break existing code
" Interface document updated/added and
checked in to SVN
" Test case review (Dev to review test
" Acceptance criteria verified complete
case written)
" Architectural impact assessed and
" All P1-P3 bugs for the story are closed
artifacts updated if necessary " Test approves user story
" Comments in code " Story demonstrated to product owner
and accepted on Target Platform
" Error codes added
" Code reviewed by peer
" Code checked in with reference to
US#/Task#
14
15. Release
Defini2on
of
Done
• Every
release
should
have
clear
quality
criteria
• With
a
Release
Defini2on
of
Done
you
can
understand
targets
beWer
• Measure
the
gap
between
the
teams
Defini2on
of
Done
and
a
Release
Defini2on
of
Done.
• This
gap
is
a
source
of
quality
issues
and
represents
significant
risk
to
schedule
16. Case
Study:
Test
Automa2on
Reduces
Cost
of
Change
17. Manual
Regression
Tes2ng
• Tes2ng
was
taking
75
person
hours
during
2
full
test
runs
consis2ng
of:
• Comprehensive
manual
regression
tes2ng
• Data
conversion
and
valida2on
• Cost
for
tes2ng
was
$17,000
each
itera2on
17
18. Introducing
Fit
into
Tes2ng
Process
• A)er
8
itera2ons
team
had
introduced
healthy
amount
of
Fit
fixtures
and
automated
tests
• Reduced
70+
hour
test
run2me
down
to
6
hours
which
now
included:
• Fit
automated
regression
tes2ng
• Data
conversion
and
valida2on
automated
with
Fit
fixtures
• Reduced
cost
of
tes2ng
each
itera2on
from
$17,000
to
$7,000
18
19. The
Agile
Regression
Tes2ng
Triangle*
Smoke++
Tests
Risk-‐based
UI
&
API
Automated
Integra2on
Tests
Tests
Automated
&
Exploratory
Automated
Unit
Tests
Make
up
largest
por2on
of
regression
tests
and
are
developed
by
programmers
*
The
Agile
Triangle
has
been
modified
from
Mike
Cohn’s
original
version
19
20. The
3
Amigos
PaWern*
Quickly
get
testers,
coders,
and
business
on
the
same
page
before
building
based
on
a
requirement
*
The
Three
Amigos
paWern
originally
coined
by
George
Dinwiddie
hWp://www.s2ckyminds.com/s.asp?F=S17232_COL_2
21. The
Three
Amigos
PaWern
As a Shopper I want to
receive updates on incredible
deals that are located near
my home so that I can save
money on my purchases
Acceptance Criteria:
• Save Shopper’s location
• Ask Shopper if they want to receive
localized deals daily
• Send notification of incredible deals to
Shoppers located within 10 miles each
morning
• Allow Shopper to stop receiving
localized deals
21
22. The
Three
Amigos
PaWern
As a Shopper I want to
receive updates on incredible
deals that are located near
my home so that I can save
money on my purchases
• What
areas
of
the
applica2on
will
this
affect?
• What
is
the
overall
design?
(UI,
API,
UX,
etc…)
• What
are
the
details
test
cases
for
this
user
story
and
it’s
acceptance
criteria?
• What
about
nega2ve
test
condi2ons?
• What
about
boundary
condi2ons?
• How
might
we
put
exis2ng
func2onality
at
risk?
22
23. The
Three
Amigos
PaWern
• At
minimum
include
tester,
coder
&
business
rep
in
discussion
• Should
only
take
30
minutes
to
1
hour
for
user
stories
• Focus
on
clarifica2on
and
design
through
testable
inputs/
outputs
23
25. Release
Management
If
releases
are
like
giving
birth,
then
you
must
be
doing
something
wrong.
-‐
Robert
Benefield
26. Case
Study:
Enterprise
Agile
Adop2on
• 180+
person
Web
2.0
product
organiza2on
• Waterfall
SDLC
that
development
uses
to
deliver
in
6
month
release
cycles
• Want
to
use
Agile
methods
to
be
more
responsive
to
users
and
keep
up
with
other
Web
2.0
companies
• Transi2oned
to
Agile
methods
on
15
teams
in
3
months
• Changed
release
management
strategy,
added
XP
technical
prac2ces,
and
implemented
Scrum
product
development
framework
for
scaled
coordina2on
• Able
to
release
every
week
to
users
within
4
months
• Used
streamlined
deployment
environment
process
to
validate
product
changes
daily
using
Con2nuous
Integra2on
and
automated
promo2ons
26
28. Tradi2onal
Source
Control
Management
Code
Complete
Version
1
Integrate
for
Branch
Version
2
Debt
Main
Branch
Death
March
{
Debt
accrues
quickly
within
stabiliza2on
periods
28
29. Flexible
Source
Control
Management
Version 1
Version 2
Main Branch
{
Not Easy! Must have proper infrastructure to do this.
29
38. Early
Warning
Signs
Early
Warnings:
• Broken
Builds
• Broken
Automated
Tests
• Broken
Custom
Thresholds
38
39. Early
Warning
on
Quality
Dashboard
Early
Warnings:
• Design
Debt
in
Duplica2on
(DRY)
• Technical
Debt
in
Code
Complexity
• Quality
Debt
in
Bug
DB
(Break/Fix)
• Other
Custom
Thresholds
39
40. The
No
Defect
Mindset
What
he
needs
is
some
way
to
pay
back.
Not
some
way
to
borrow
more.
-‐-‐
Will
Rogers
39
41. Ken
Schwaber
For
every
[dollar]
of
compe22ve
advantage
gained
by
cuYng
quality,
it
costs
$4
to
restore
it;
and
so)ware
is
an
organiza2onal
asset
and
decisions
to
cut
quality
must
be
made
by
execu2ve
management
and
reflected
in
the
financial
statements.
hWp://www.infoq.com/presenta2ons/agile-‐quality-‐canary-‐coalmine
42. Case
Study:
Field
Support
Applica2on
• 2000+
users
access
applica2on
each
day
• Applica2on
supports
mul2ple
perspec2ves
and
workflows
from
Field
Support
Opera2ons
to
Customer
Service
• Team
of
5
people
delivering
features
on
exis2ng
Cold
Fusion
pla]orm
implementa2on
• Migra2ng
Architecture
to
Spring/Hibernate
in
slices
while
s2ll
delivering
valuable
features
• 36
2-‐week
Sprints,
33
produc2on
releases,
and
only
1
defect
found
in
produc2on
• So,
what
was
the
defect
you
say?
Let
me
tell
you…
40
43. Can
We
Afford
a
No
Defect
Policy?
• This
team
worked
on
legacy
codebase
inherited
from
another
vendor
• Other
vendor
had
been
slowing
down
month
a)er
month
and
cost
of
development
was
increasing
• In
first
itera2on
this
team
was
able
to
deliver
more
than
other
vendor
was
able
to
in
previous
2
months
• A)er
24
itera2ons
this
team
was
10
2mes
faster
delivery
than1st
itera2on
• Acceptance
Test-‐Driven
Development
and
Con2nuous
Integra2on
were
greatest
technical
factors
to
support
team
in
these
results
• Can
you
afford
not
to
have
a
No
Defect
policy?
41
44. Thank
you!
Ques2ons
and
Answers
[Time
permiYng]
45. Chris
Sterling
Director
of
Engineering
at
Rally
So)ware
in
Kirkland,
WA
office
Author
of
Book
Managing
So)ware
Debt:
Building
for
Inevitable
Change
Consults
on
so)ware
technology,
Agile
technical
prac2ces,
Scrum,
and
effec2ve
management
techniques
Innova2on
Games®
Trained
Facilitator
Email:
csterling@rallydev.com
Web:
hWp://www.rallydev.com
Cer2fied
Scrum
Trainer
Follow
me
on
TwiWer:
@csterwa
Blog:
hWp://www.geYngagile.com
Hashtag
for
presenta2on:
#swdebt
Open
Source
Developer