Continuous integration, acceptance test driven development (ATDD), specification by example and continuous deployment: The list of have-to-know concepts is growing and you have this nagging feeling that you should really get started so you won’t miss out on the fun.
Learn what basic Agile technical concepts mean, understand how you can benefit from using them and get ideas for how you might get started. Also, you will be able to explain to your boss or project manager why Agile technical concepts are well worth the investment.
This session will keep things on a strictly conceptual level - so whether you’re a developer or an interested manager please come along.
Testing for Agility: Bringing Testing into EverythingCamille Bell
The document discusses testing in an agile environment. It covers:
- Bringing testing into all aspects of development, not just as a separate phase.
- The problems that can arise from using a "waterfall" testing approach of waiting until late in the process to test, rather than continuous testing.
- How agile practices like test-driven development, behavior-driven development, and continuous integration can help transform testing practices from waterfall to more iterative and collaborative approaches.
• What is Behavior Driven Development?
• What is its value?
• How does BDD differ from Test-Driven Development?
• What is the role of the customer/product owner in BDD?
• What about teams that have traditional manual testers?
• What about teams that have developers but not testers?
• What is a good BDD test?
• What should be tested manually?
Adapting Agility: Getting your Agile Transformation UnstuckCamille Bell
In this presentation, I explore many common Agile transformation issues and what you can do about them. I cover challenges with customers, technical process, organizational hurdles, prioritization, agile requirements, etc. Some of the topics include:
o No single Product Owner in Scrum.
o No on-site customer for Extreme Programming.
o The user stories are too big.
o The user stories are too vague.
o Bug count is going up or not going down.
o Customer/Stakeholders/PO never choose technical stories for next iteration/sprint.
o Customer/Stakeholders/PO won't take the time to prioritize their backlog.
o Even though story points match prior velocity, there seems to be too much work.
o Stand-up or Scrum meetings take forever.
o Stand-up or Scrum meetings are short, but no one talks about real problems.
o Management doesn't value removing impediments quickly.
o Velocity seems to be slowing down.
o So many hoops to jump through that it takes forever to get anything done.
Beyond TDD: Enabling Your Team to Continuously Deliver SoftwareChris Weldon
Many project teams have adopted unit testing as a necessary step in their development process. Many more use a test-first approach to keep their code lean. Yet, far too often these teams still suffer from many of the same impediments: recurrent integration failures with other enterprise projects, slow feedback with the customer, and sluggish release cycles. With a languishing feedback loop, the enterprise continues to put increasing pressure on development teams to deliver. How does an aspiring agile team improve to meet the demands of the enterprise?
Continuous integration is the next logical step for the team. In this talk, you’ll learn how continuous integration solves intra and inter-project integration issues without manual overhead, the value added by continuous integration, and how to leverage tools and processes to further improve the quality of your code. Finally, we discuss the gold standard of agile teams: continuous deployment. You’ll learn how continuous deployment helps close the feedback loop with your customers, increases visibility for your team, and standardizes the deployment process.
[QaOps] Continuouss Integration | Pipeline strategyRafael Lima
The document discusses strategies for testing software applications, including the test pyramid approach. It describes the ideal test pyramid structure with automated unit tests at the base and more integrated tests as the layers increase. However, it notes that the ideal shape is not always achievable and provides suggestions for alternative test structures and strategies when facing constraints like existing codebases or microservice architectures. The relevance of the test pyramid approach in modern development is also examined.
Growing Manual Testers into AutomatorsCamille Bell
Manual testing can't keep up with modern software development. Tests generated by Capture/Playback tools don't work either as these tests become brittle and break. Instead working with business and development testers need to create acceptance criteria that drives product development. To become automators testers need new tools. Testers need new ways of working. Testers need new skills. And the organization needs to support your testers growth. Here is how I and others have made it work.
The document summarizes a presentation on Agile Testing for a software development group. The presentation covered the textbook definition of Agile Testing, focusing on doing the simplest tests to verify functionality and quality standards. It also discussed the street version, emphasizing establishing a quality philosophy throughout the team. Finally, it discussed challenges such as finding the right testing resources and preventing work from being "thrown over the wall" to testing without proper communication between teams.
The document describes WiredReach's process for implementing continuous deployment. It discusses how they moved from bi-weekly release cycles with large releases to releasing multiple times per day with releases containing under 25 lines of code. This was done by setting up automated testing and deployment pipelines. It also touches on some of the challenges they faced in taking this approach and strategies for incrementally building systems to support continuous deployment like adding production monitoring and building a "cluster immune system".
Testing for Agility: Bringing Testing into EverythingCamille Bell
The document discusses testing in an agile environment. It covers:
- Bringing testing into all aspects of development, not just as a separate phase.
- The problems that can arise from using a "waterfall" testing approach of waiting until late in the process to test, rather than continuous testing.
- How agile practices like test-driven development, behavior-driven development, and continuous integration can help transform testing practices from waterfall to more iterative and collaborative approaches.
• What is Behavior Driven Development?
• What is its value?
• How does BDD differ from Test-Driven Development?
• What is the role of the customer/product owner in BDD?
• What about teams that have traditional manual testers?
• What about teams that have developers but not testers?
• What is a good BDD test?
• What should be tested manually?
Adapting Agility: Getting your Agile Transformation UnstuckCamille Bell
In this presentation, I explore many common Agile transformation issues and what you can do about them. I cover challenges with customers, technical process, organizational hurdles, prioritization, agile requirements, etc. Some of the topics include:
o No single Product Owner in Scrum.
o No on-site customer for Extreme Programming.
o The user stories are too big.
o The user stories are too vague.
o Bug count is going up or not going down.
o Customer/Stakeholders/PO never choose technical stories for next iteration/sprint.
o Customer/Stakeholders/PO won't take the time to prioritize their backlog.
o Even though story points match prior velocity, there seems to be too much work.
o Stand-up or Scrum meetings take forever.
o Stand-up or Scrum meetings are short, but no one talks about real problems.
o Management doesn't value removing impediments quickly.
o Velocity seems to be slowing down.
o So many hoops to jump through that it takes forever to get anything done.
Beyond TDD: Enabling Your Team to Continuously Deliver SoftwareChris Weldon
Many project teams have adopted unit testing as a necessary step in their development process. Many more use a test-first approach to keep their code lean. Yet, far too often these teams still suffer from many of the same impediments: recurrent integration failures with other enterprise projects, slow feedback with the customer, and sluggish release cycles. With a languishing feedback loop, the enterprise continues to put increasing pressure on development teams to deliver. How does an aspiring agile team improve to meet the demands of the enterprise?
Continuous integration is the next logical step for the team. In this talk, you’ll learn how continuous integration solves intra and inter-project integration issues without manual overhead, the value added by continuous integration, and how to leverage tools and processes to further improve the quality of your code. Finally, we discuss the gold standard of agile teams: continuous deployment. You’ll learn how continuous deployment helps close the feedback loop with your customers, increases visibility for your team, and standardizes the deployment process.
[QaOps] Continuouss Integration | Pipeline strategyRafael Lima
The document discusses strategies for testing software applications, including the test pyramid approach. It describes the ideal test pyramid structure with automated unit tests at the base and more integrated tests as the layers increase. However, it notes that the ideal shape is not always achievable and provides suggestions for alternative test structures and strategies when facing constraints like existing codebases or microservice architectures. The relevance of the test pyramid approach in modern development is also examined.
Growing Manual Testers into AutomatorsCamille Bell
Manual testing can't keep up with modern software development. Tests generated by Capture/Playback tools don't work either as these tests become brittle and break. Instead working with business and development testers need to create acceptance criteria that drives product development. To become automators testers need new tools. Testers need new ways of working. Testers need new skills. And the organization needs to support your testers growth. Here is how I and others have made it work.
The document summarizes a presentation on Agile Testing for a software development group. The presentation covered the textbook definition of Agile Testing, focusing on doing the simplest tests to verify functionality and quality standards. It also discussed the street version, emphasizing establishing a quality philosophy throughout the team. Finally, it discussed challenges such as finding the right testing resources and preventing work from being "thrown over the wall" to testing without proper communication between teams.
The document describes WiredReach's process for implementing continuous deployment. It discusses how they moved from bi-weekly release cycles with large releases to releasing multiple times per day with releases containing under 25 lines of code. This was done by setting up automated testing and deployment pipelines. It also touches on some of the challenges they faced in taking this approach and strategies for incrementally building systems to support continuous deployment like adding production monitoring and building a "cluster immune system".
The document discusses best practices for continuous integration, continuous delivery, and automation in software development. It recommends automating the entire development cycle from build to test to deployment. Changes should be deployed frequently, such as multiple times a day, to catch errors early. All code, configurations, and dependencies should be stored in version control. A deployment pipeline approach is advocated with separate stages for testing, verification, and release to different environments. Rollback and recovery should be planned and tested.
Dr. Ronen Bar-Nahor - Optimizing Agile Testing in Complex EnvironmentsAgileSparks
The document discusses challenges in testing complex systems with legacy code and minimal automation. It recommends optimizing testing in agile by:
1) Breaking stories into testable chunks that can flow quickly to testing within sprints.
2) Involving QA early in architecture design to ensure testability.
3) Taking an incremental approach to automating tests for new features while refactoring legacy code.
4) Integrating continuously using a staged approach with independent integration testing.
This document summarizes a presentation on best practices for using Selenium for test automation. The presentation covers 12 steps: 1) Admit you have a problem; 2) Take a deep breath; 3) Try looking at things differently; 4) Pump some tech iron; 5) Find your inner Napoleon and develop a strategy; 6) Break down the wall between QA and development; 7) Learn the terrain; 8) Test less but test well; 9) Keep it lean and optimize; 10) Pay it forward by sharing knowledge; 11) Resources for learning Selenium; 12) Recap of the 12 steps. The document provides additional details on each step and recommendations for learning more.
The document discusses common mistakes and pitfalls when doing test-driven development (TDD). It covers topics like test identification (unit, integration, acceptance tests), ensuring each test covers a single scenario, dealing with legacy code, managing dependencies, and lack of automation in testing. The presenter advocates starting tests by making them fail and then passing the test with just enough code, iterating quickly via the red-green-refactor process, and focusing tests on specifying behavior rather than implementation details.
The document discusses quality driven software development using test-driven development (TDD) and behavior-driven development (BDD). It promotes writing unit tests, integration tests, and acceptance tests. TDD involves writing a failing test first, then code to pass the test, and refactoring the code. BDD uses a language like Gherkin to write automated tests of features in plain language before coding them. The document advocates for a feature-first approach where features are tested throughout development.
Computer simulations of software teams process helps you gain insight into its inherent complexity and assists in making better decisions about process policies
The Test Automation Pyramid is a useful model to help us understand and discuss automated testing efforts. Generally speaking it is a good practice to have lots of unit tests, fewer component integration tests, fewer API tests, and even fewer UI tests.
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 describes the experience of inverting the test pyramid for an organization that provides revenue management systems to hotels. It discusses:
1) Moving from a primarily manual testing approach with many end-to-end UI tests to focusing more on unit and integration tests by designing for testability.
2) This transition helped reduce regression times from months to weeks by grouping tests more efficiently and avoiding duplicative tests.
3) Challenges included dealing with legacy code not designed for testing, mapping acceptance tests across different levels, and building team competencies - but benefits included automation as part of development and improved collaboration.
Scaling Kanban in the Enterprise with GreenHopperDavid Jellison
Presentation delivered @Atlassian Summit 2012. Balancing the coordination of many Agile product delivery teams on the same major release cycle -- and still allowing these teams to self-organise -- is a craft Agile Enterprises must master. JIRA, GreenHopper and Confluence provide a rich platform that accommodates cross team co-ordination and the flexibility required for teams to self-organise. In this talk, David will walk the audience through the process of breaking down a Kanban value chain into steps and transitions, mapping out compatible workflows, and building the combined board. David will also share details of how Constant Contact provides visibility into the progress of teams and the release cycle. Constant Contact was able to deliver 15% more often in 2011 than prior years by refining their Agile practices.
Even with the best agile development practices, bugs sometimes slip in. You don't want to manually wade through hundreds of commits and thousands or tens of thousands of lines of code to find your bug. See how find your bug fast using Git, the best (and free) version control software tool. If you are still using CVS, Subversion, or costly commercial version control, you are missing out.
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.
The document discusses Agile testing and key practices that testers enjoy about working in an Agile environment. It highlights benefits like automated testing, collaboration with developers, testing features before they are built, and focusing on quality over just documenting bugs. The presentation emphasizes principles of Agile testing like continuous feedback, simplicity, adaptation to change, and enjoyment.
Scaling Continuous Integration in the CloudAtlassian
This document discusses scaling continuous integration in the cloud. It covers topics like automated testing, continuous integration, and using map reduce testing to parallelize test execution across many compute nodes in the cloud. Continuous integration aims for visibility of test results, reliability of the build process, and low latency between check-ins and test feedback. The document proposes using Hadoop and map reduce to distribute test loads across thousands of nodes to further reduce latency and enable massive parallelization of tests.
Developing for Remote Bamboo Agents, AtlasCamp US 2012Atlassian
Brydie McCoy, Java Developer
As more and more peoples' building demands grow, they expand from building everything locally to a distributed building system or the elastic cloud. And for OnDemand the elastic cloud is the only option. Unfortunately developing plugins for remote/elastic agents has its own set of gotchas. Most plugins written for Bamboo do not work properly on remote agents. This talk will cover the core principles of developing for remote agents, what you can and can't do, as well as more advanced topics such as data transfer and communication between the agent and the server.
The document discusses the "test pyramid" concept for balancing test suites from unit to end-to-end tests. It provides examples of different types of tests including unit tests, integration tests, UI/end-to-end tests. It also discusses challenges with different types of tests and strategies for addressing those challenges including dependency injection, mocks, and tools like Cucumber, Robolectric, and Pacto. The document seeks feedback on testing approaches and provides additional resources on testing best practices.
Why your company loves to welcome change but sucks at accommodating itFarooq Ali
The need for sound engineering practices in Agile. A look at a very common Agile anti-pattern (Flaccid Scrum) found in large organizations, and how to fix it.
Agile Testing Framework - The Art of Automated TestingDimitri Ponomareff
Once your organization has successfully implemented Agile methodologies, there are two major areas that will require improvements: Continuous Integration and Automated Testing.
This presentation illustrates why it's important to invest in an Automated Testing Framework (ATF) to reduce technical debt, increase quality and accelerate time to market.
Learn more at www.agiletestingframework.com.
This document discusses test-driven development (TDD). It begins by noting that projects often fail by being late, delivering the wrong thing, or being unstable in production. It then discusses how requirements constantly change and there is never enough time or money. TDD is presented as a solution by helping to prove code works, avoid waste from debugging, and allow for confident refactoring. The document outlines how to implement TDD through iterations involving red-green-refactor cycles and quality as the driver. It also covers limits, benefits, challenges, and tips for adoption of TDD.
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.
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.
The document discusses best practices for continuous integration, continuous delivery, and automation in software development. It recommends automating the entire development cycle from build to test to deployment. Changes should be deployed frequently, such as multiple times a day, to catch errors early. All code, configurations, and dependencies should be stored in version control. A deployment pipeline approach is advocated with separate stages for testing, verification, and release to different environments. Rollback and recovery should be planned and tested.
Dr. Ronen Bar-Nahor - Optimizing Agile Testing in Complex EnvironmentsAgileSparks
The document discusses challenges in testing complex systems with legacy code and minimal automation. It recommends optimizing testing in agile by:
1) Breaking stories into testable chunks that can flow quickly to testing within sprints.
2) Involving QA early in architecture design to ensure testability.
3) Taking an incremental approach to automating tests for new features while refactoring legacy code.
4) Integrating continuously using a staged approach with independent integration testing.
This document summarizes a presentation on best practices for using Selenium for test automation. The presentation covers 12 steps: 1) Admit you have a problem; 2) Take a deep breath; 3) Try looking at things differently; 4) Pump some tech iron; 5) Find your inner Napoleon and develop a strategy; 6) Break down the wall between QA and development; 7) Learn the terrain; 8) Test less but test well; 9) Keep it lean and optimize; 10) Pay it forward by sharing knowledge; 11) Resources for learning Selenium; 12) Recap of the 12 steps. The document provides additional details on each step and recommendations for learning more.
The document discusses common mistakes and pitfalls when doing test-driven development (TDD). It covers topics like test identification (unit, integration, acceptance tests), ensuring each test covers a single scenario, dealing with legacy code, managing dependencies, and lack of automation in testing. The presenter advocates starting tests by making them fail and then passing the test with just enough code, iterating quickly via the red-green-refactor process, and focusing tests on specifying behavior rather than implementation details.
The document discusses quality driven software development using test-driven development (TDD) and behavior-driven development (BDD). It promotes writing unit tests, integration tests, and acceptance tests. TDD involves writing a failing test first, then code to pass the test, and refactoring the code. BDD uses a language like Gherkin to write automated tests of features in plain language before coding them. The document advocates for a feature-first approach where features are tested throughout development.
Computer simulations of software teams process helps you gain insight into its inherent complexity and assists in making better decisions about process policies
The Test Automation Pyramid is a useful model to help us understand and discuss automated testing efforts. Generally speaking it is a good practice to have lots of unit tests, fewer component integration tests, fewer API tests, and even fewer UI tests.
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 describes the experience of inverting the test pyramid for an organization that provides revenue management systems to hotels. It discusses:
1) Moving from a primarily manual testing approach with many end-to-end UI tests to focusing more on unit and integration tests by designing for testability.
2) This transition helped reduce regression times from months to weeks by grouping tests more efficiently and avoiding duplicative tests.
3) Challenges included dealing with legacy code not designed for testing, mapping acceptance tests across different levels, and building team competencies - but benefits included automation as part of development and improved collaboration.
Scaling Kanban in the Enterprise with GreenHopperDavid Jellison
Presentation delivered @Atlassian Summit 2012. Balancing the coordination of many Agile product delivery teams on the same major release cycle -- and still allowing these teams to self-organise -- is a craft Agile Enterprises must master. JIRA, GreenHopper and Confluence provide a rich platform that accommodates cross team co-ordination and the flexibility required for teams to self-organise. In this talk, David will walk the audience through the process of breaking down a Kanban value chain into steps and transitions, mapping out compatible workflows, and building the combined board. David will also share details of how Constant Contact provides visibility into the progress of teams and the release cycle. Constant Contact was able to deliver 15% more often in 2011 than prior years by refining their Agile practices.
Even with the best agile development practices, bugs sometimes slip in. You don't want to manually wade through hundreds of commits and thousands or tens of thousands of lines of code to find your bug. See how find your bug fast using Git, the best (and free) version control software tool. If you are still using CVS, Subversion, or costly commercial version control, you are missing out.
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.
The document discusses Agile testing and key practices that testers enjoy about working in an Agile environment. It highlights benefits like automated testing, collaboration with developers, testing features before they are built, and focusing on quality over just documenting bugs. The presentation emphasizes principles of Agile testing like continuous feedback, simplicity, adaptation to change, and enjoyment.
Scaling Continuous Integration in the CloudAtlassian
This document discusses scaling continuous integration in the cloud. It covers topics like automated testing, continuous integration, and using map reduce testing to parallelize test execution across many compute nodes in the cloud. Continuous integration aims for visibility of test results, reliability of the build process, and low latency between check-ins and test feedback. The document proposes using Hadoop and map reduce to distribute test loads across thousands of nodes to further reduce latency and enable massive parallelization of tests.
Developing for Remote Bamboo Agents, AtlasCamp US 2012Atlassian
Brydie McCoy, Java Developer
As more and more peoples' building demands grow, they expand from building everything locally to a distributed building system or the elastic cloud. And for OnDemand the elastic cloud is the only option. Unfortunately developing plugins for remote/elastic agents has its own set of gotchas. Most plugins written for Bamboo do not work properly on remote agents. This talk will cover the core principles of developing for remote agents, what you can and can't do, as well as more advanced topics such as data transfer and communication between the agent and the server.
The document discusses the "test pyramid" concept for balancing test suites from unit to end-to-end tests. It provides examples of different types of tests including unit tests, integration tests, UI/end-to-end tests. It also discusses challenges with different types of tests and strategies for addressing those challenges including dependency injection, mocks, and tools like Cucumber, Robolectric, and Pacto. The document seeks feedback on testing approaches and provides additional resources on testing best practices.
Why your company loves to welcome change but sucks at accommodating itFarooq Ali
The need for sound engineering practices in Agile. A look at a very common Agile anti-pattern (Flaccid Scrum) found in large organizations, and how to fix it.
Agile Testing Framework - The Art of Automated TestingDimitri Ponomareff
Once your organization has successfully implemented Agile methodologies, there are two major areas that will require improvements: Continuous Integration and Automated Testing.
This presentation illustrates why it's important to invest in an Automated Testing Framework (ATF) to reduce technical debt, increase quality and accelerate time to market.
Learn more at www.agiletestingframework.com.
This document discusses test-driven development (TDD). It begins by noting that projects often fail by being late, delivering the wrong thing, or being unstable in production. It then discusses how requirements constantly change and there is never enough time or money. TDD is presented as a solution by helping to prove code works, avoid waste from debugging, and allow for confident refactoring. The document outlines how to implement TDD through iterations involving red-green-refactor cycles and quality as the driver. It also covers limits, benefits, challenges, and tips for adoption of TDD.
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.
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.
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.
Continuous delivery requires more that DevOps. It also requires one to think differently about product design, development & testing, and the overall structure of the organization. This presentation will help you understand what it takes and why one would want to deliver value to your customers multiple times each day. #CIC
Jeff "Cheezy" Morgan Ardita Karaj
This document summarizes an agile testing presentation at eBay. It discusses how eBay uses agile testing practices like:
1. Designing automated tests with test aspects to provide clear test coverage and enable early testing.
2. Modeling the business domain layer to enable modular, reusable, and data-driven end-to-end tests.
3. Implementing tests using Selenium to test eBay's European websites, mobile apps, and desktop applications in parallel across multiple platforms and languages.
It also emphasizes the importance of both automated and exploratory manual testing, speaking the same language as developers, and applying agile principles like continuous feedback to customers.
Definition of Done and Product Backlog refinementChristian Vos
The document discusses product backlog refinement and the definition of done in agile software development. It emphasizes that product backlog refinement is an important meeting to clarify and estimate user stories and work items to have a ready backlog for iteration planning. It also stresses that having a clear definition of done helps improve team quality, transparency for stakeholders, better release planning, and minimizing risks. Regular product backlog refinement coupled with a well-defined definition of done are key practices for achieving agility.
This presentation is about unit tests, integration tests, REST tests, code coverage and analysis tools, code reviews and other tools that help achieve high-level results.
This presentation by Ilya Tsvetkov (Associate Manager, GlobalLogic) was delivered at GlobalLogic Java Conference in Krakow on December 12, 2015.
Engaging IV&V Testing Services for Agile ProjectsRavi Kumar
This document discusses agile testing and the role of testers in agile development. It covers topics like the value testers provide, Brian Marick's test categories, challenges with agile testing and strategies to address them, and the role of automation and continuous integration. Key points emphasized are that testers are not obsolete in agile and need to adapt to new ways of testing, defining acceptance criteria, collaborating with developers, automating tests, and providing frequent feedback to the team.
Despite the belief that a shared context and collaboration drives quality, too often, software testers and quality professionals struggle to find their place within today's integrated agile teams. This session is a practitioner’s view of testing and testing practices within an iterative/incremental development environment. We will begin with a discussion of some of the challenges of testing within an agile environment and delve into the guiding principles of Agile Testing and key enabling practices. Agile Testing necessitates a change in mindset, and it is as much, if not more, about behavior, as it is about skills and tooling, all of which will be explored.
Shift left, shift right the testing swing.
This deck shows the testing framework we use today in our agile & Devops team. We do Behavior Driven Development (Shift left) and test in production as well (shift right).
SOASTA Webinar: Process Compression For Mobile App Dev 120612SOASTA
The webinar discusses continuous integration and automation for mobile development and testing. It presents tools from Atlassian, Zephyr, and SOASTA that can help automate the mobile development and testing process. Continuous integration with Bamboo can help developers integrate code changes more frequently and fail builds faster to catch bugs earlier. Zephyr provides test management to centralize test assets and provide visibility. SOASTA offers tools for test automation, real user monitoring, and performance/load testing to help achieve test completion with quality. Together these tools can help speed up the mobile development process through continuous integration, test automation, and visibility into the testing process.
This document discusses Quality Driven Development (QDD), an approach where quality is a dynamic and conditional subset of attributes driven by business value. It emphasizes building the right product through general team responsibility for quality assurance reflected in daily development practices. Verification and automated testing are used to ensure work meets requirements, while exploration testing validates if the right software was built. Quality assurance practices are incorporated to increase confidence and reduce risks and testing needs.
How to go beyond traditional Scrum principles and scale to globally distributed teams with Continuous Delivery and Subversion. Presented by Andy Singleton of Assembla and Scott Rudenstein of WANdisco. Presented Nov. 15, 2012. 30 minutes.
The document discusses the role of quality assurance (QA) in agile teams. It compares the traditional and agile approaches to QA, outlining the agile QA responsibilities which include helping define user stories and acceptance criteria, estimating stories, ensuring testing is accounted for in planning, and more. Common mistakes like not involving QA throughout or having them run tests in subsequent sprints are also covered.
This document discusses automated testing and different levels of testing. It explains that automated tests should be written to achieve good design, clarify how a system works, understand the system, and minimize risks. While automated tests require time to write, maintain, and execute, these efforts can be minimized by making tests easy to run and maintain with minimal dependencies. The document also discusses different perspectives on testing, including what developers and customers want. Developers are concerned with complexity and risk, while customers care about functionality and user scenarios. It notes that while unit tests have limitations, acceptance tests are also limited as they are slow, fragile, and not isolated. The "lost layer" of the testing pyramid is also mentioned - the presentation, service, and persistence
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 document discusses challenges for testers in agile development environments. It outlines several strategies testers can use to address these challenges, including:
- Pairing testers with developers to facilitate exploratory and interaction testing. This helps testers understand the codebase and developers understand testing needs.
- Pairing testers with analysts to help define requirements by example, clarify expectations, and drive development of acceptance tests.
- Prioritizing testing to address important risks rather than trying to do complete testing. A good tester is never done but must justify testing in terms of risk.
- Tracking bugs when testing completed iterations, even if fixes are made quickly, so issues can be prioritized like stories.
This document discusses challenges for testers in agile development environments. It outlines several strategies testers can use to address these challenges, including:
- Pairing testers with developers to facilitate exploratory and interaction testing. This helps testers understand the codebase and developers understand testing needs.
- Pairing testers with analysts to help define requirements by example, clarify expectations, and drive development of acceptance tests.
- Prioritizing testing to address important risks rather than trying to do complete testing. A good tester is never done but must justify testing in terms of risk.
- Tracking bugs when testing completed iterations, even if fixes are made quickly, so issues can be prioritized like stories.
This document provides an agenda and overview for a webinar on quality coding features in Visual Studio 2012. The webinar will cover new tools for unit testing, code reviews, code analysis, and code clones. It will also review features for quality in requirements, development, and testing such as storyboarding, test environments, and exploratory testing. Attendees are encouraged to join the free webinar to learn about and see demonstrations of these Visual Studio 2012 features for improving code quality.
Release software is no less important than activities that precede it.
The Continuous Delivery is a set of practices and methodologies that build an ecosystem for the software development lifecycle.
We will see how to build this ecosystem around the applications developed, for which this release activities becomes a low-risk, inexpensive, fast and predictable.
Similar to Flexing your Agile Muscle - Agile Technical Concepts Explained (20)
The way we assess, evaluate and optimise individual performance is no longer relevant in the modern workplace. The performance of an individual is much less important than you think it is.
"Gold Medal Me" - Olympic Tips to Be the Best You Can BeSandy Mamoli
Increased complexity and rapid technological change require us to collaborate better. Collaboration is done in teams but team work is an individual skill.
Those skills are a must-have in our complex world where responsibility, resilience and rapid learning are everything. In this highly personal talk former Olympian Sandy Mamoli dives deeply into the Olympic mindset and contrasts the perspectives and attitudes of professional sports with modern work life. She demonstrates guidelines and tools from the sports arena that we all can immediately apply.
I share my insights that unlock the secrets behind becoming a future-fit employee and leader and describes skills that will make you a successful and appreciated member of any team and organisation. From critical feedback skills to learning from failure and high-performance teams, come along and learn practical ways for how to apply ideas from Olympic sports to your professional career!
How I Tried holacracy and Lived to Tell the TaleSandy Mamoli
This is the story of introducing holacracy at a New Zealand tech company, whose CTO gave Sandy a one-line instruction: “I’d like you to make it happen.”
Come along and learn from Sandy Mamoli’s successes and failures in her team’s quest to create a truly self-organising organisation. Learn what worked and what didn’t, and find out how the team resolved the question of whether they had joined a cult or actually improved their business.
Decentralising Leadership - Holacracy for Humans Sandy Mamoli
In her session ‘Decentralising leadership: a story of Holacracy in practice’ Sandy will share her story of implementing Holacracy at a New Zealand tech company, whose CTO gave her a one-line instruction: “I’d like you to make it happen.”
Formando Times Memoráveis - Como a auto-seleção proporciona excelênciaSandy Mamoli
Aqui está uma ideia radical: confie que as pessoas saibam melhor e deixe-os decidir qual equipe eles devem trabalhar. Deixe que eles mesmos escolham!
A auto-seleção é a maneira mais simples, mais rápida e eficiente para formar equipes estáveis, baseada na crença de que as pessoas ficam mais feliz e mais produtivas se elas podem escolher o que elas querem trabalhar e com quem trabalham.
Vou compartilhar nossos aprendizados e experiências de mais de dois anos de execução de processos de auto-seleção em grandes organizações. Irei mostrar um processo possível de ser reproduzido para saber como criar equipas eficientes em organizações em crescimento e irei responder a perguntas como "Por que que eu faria isso? " e "Como posso convencer a gerência?".
Creating Great Teams - How Self-Selection Lets People ExcelSandy Mamoli
Here’s a radical idea: Trust people to know best and let them decide which team they should work in. Let them Self-Select!
Self-selection is the simplest, fastest and most efficient way to form stable teams, based on the belief that people are at their happiest and most productive if they can choose what they work on and who they work with.
In October 2013, Trade Me, New Zealand’s largest eCommerce provider ran the biggest Self-Selection event in the world since WWII, using a process which has since been repeated many times in multiple locations across the world.
In this presentation I will share my learnings and experiences from more than four years of running Self-Selection processes in large organisations. I will show you a repeatable process for how to establish efficient teams in growing organisations and will answer questions such as “Why would I do that”? and “How can I convince management?”.
The Self Selecting Organisation - Total Squadification at Trade MeSandy Mamoli
Inspired by Spotify's squads and Atlassian's Fedex day we let 90 people choose what they wanted to work on and who they wanted to work with. Through telling the story of Trade Me, New Zealand's biggest ecommerce platform, we will demonstrate how good leadership can inspire and empower people using a scalable self-selection process along with a vision for an exciting picture of the future.
Flying in the face of conventional wisdom and traditional management practices a middle manager and an Agile coach didn't ask for permission, and removed significant obstacles and constraints to successfully form 18 self-chosen, fully skilled squads. In this session we will show how we facilitated self-organisation on a scale we don't believe has been done before, what we had to go through to convince people that this was a good idea, how we learned how to visualise the process and dealt with brilliant people as well as a few difficult ones!
We will describe how we had the exciting opportunity to observe and partake in a social experiment where people made decisions on the fly and stayed true to our values of being trusted, straight up and to grow great people.
All Agile teams self-organise but we took the principles to a whole other level and created the self-organising organisation.
Portfolio Kanban - Seeing the Big Picture Sandy Mamoli
This document discusses the implementation of Portfolio Kanban at Trade Me to improve project workflow and management. It describes how they visualized their workflow, limited work in progress, established prioritization and policies, and linked the Portfolio Kanban system to project squads. This resulted in fewer projects in progress and improved ability to work on the highest priority projects. The document advocates the six steps of Portfolio Kanban and shares Trade Me's experience in implementing the framework.
The evils of multi-tasking and how personal Kanban can help you Sandy Mamoli
This document discusses the evils of multi-tasking and how personal Kanban can help. It describes multi-tasking exercises that show how multi-tasking slows people down. It discusses how organizational multi-tasking leads to people working on 3-5 projects at once. Personal Kanban is presented as an alternative, with rules like visualizing workflow, limiting work in progress, and only allowing the task owner to add tasks. Benefits of Personal Kanban include improved flow, focus on achievement over activity, timeboxing, and better work-life balance.
This document provides an overview of Scrum and being Agile. It discusses why Agile is used, the ingredients of Scrum including iterative development, working software and self-organizing cross-functional teams. It then describes the roles in Scrum including the Product Owner, Scrum Master and Team. The document outlines the product backlog, sprint planning, daily standups and retrospectives that are part of the Scrum process.
Douglas Talbot & Sandy Mamoli
One of the most fundamental problems facing a project is how you decide on, document, and manage your requirements.
Obviously Agile software development promotes handling this very differently than a Waterfall approach. One mechanism used by Agile projects to track requirements is the "User Story" - but what are they, how are they created, who uses them, when and how, within the development cycle?
This document discusses challenges with integrating user experience design into agile development processes. It describes three attempted models and their shortcomings: 1) Fully agile resulted in piecemeal, inconsistent design. 2) Upfront design was difficult to change and designs went out of date. 3) Post-skinning led to drift from design intent and unnecessary refactoring. It advocates for a "Sprint 0" to define fundamentals before subsequent sprints to balance agile practices with holistic design.
Main news related to the CCS TSI 2023 (2023/1695)Jakub Marek
An English 🇬🇧 translation of a presentation to the speech I gave about the main changes brought by CCS TSI 2023 at the biggest Czech conference on Communications and signalling systems on Railways, which was held in Clarion Hotel Olomouc from 7th to 9th November 2023 (konferenceszt.cz). Attended by around 500 participants and 200 on-line followers.
The original Czech 🇨🇿 version of the presentation can be found here: https://www.slideshare.net/slideshow/hlavni-novinky-souvisejici-s-ccs-tsi-2023-2023-1695/269688092 .
The videorecording (in Czech) from the presentation is available here: https://youtu.be/WzjJWm4IyPk?si=SImb06tuXGb30BEH .
How information systems are built or acquired puts information, which is what they should be about, in a secondary place. Our language adapted accordingly, and we no longer talk about information systems but applications. Applications evolved in a way to break data into diverse fragments, tightly coupled with applications and expensive to integrate. The result is technical debt, which is re-paid by taking even bigger "loans", resulting in an ever-increasing technical debt. Software engineering and procurement practices work in sync with market forces to maintain this trend. This talk demonstrates how natural this situation is. The question is: can something be done to reverse the trend?
"Choosing proper type of scaling", Olena SyrotaFwdays
Imagine an IoT processing system that is already quite mature and production-ready and for which client coverage is growing and scaling and performance aspects are life and death questions. The system has Redis, MongoDB, and stream processing based on ksqldb. In this talk, firstly, we will analyze scaling approaches and then select the proper ones for our system.
Connector Corner: Seamlessly power UiPath Apps, GenAI with prebuilt connectorsDianaGray10
Join us to learn how UiPath Apps can directly and easily interact with prebuilt connectors via Integration Service--including Salesforce, ServiceNow, Open GenAI, and more.
The best part is you can achieve this without building a custom workflow! Say goodbye to the hassle of using separate automations to call APIs. By seamlessly integrating within App Studio, you can now easily streamline your workflow, while gaining direct access to our Connector Catalog of popular applications.
We’ll discuss and demo the benefits of UiPath Apps and connectors including:
Creating a compelling user experience for any software, without the limitations of APIs.
Accelerating the app creation process, saving time and effort
Enjoying high-performance CRUD (create, read, update, delete) operations, for
seamless data management.
Speakers:
Russell Alfeche, Technology Leader, RPA at qBotic and UiPath MVP
Charlie Greenberg, host
Discover top-tier mobile app development services, offering innovative solutions for iOS and Android. Enhance your business with custom, user-friendly mobile applications.
[OReilly Superstream] Occupy the Space: A grassroots guide to engineering (an...Jason Yip
The typical problem in product engineering is not bad strategy, so much as “no strategy”. This leads to confusion, lack of motivation, and incoherent action. The next time you look for a strategy and find an empty space, instead of waiting for it to be filled, I will show you how to fill it in yourself. If you’re wrong, it forces a correction. If you’re right, it helps create focus. I’ll share how I’ve approached this in the past, both what works and lessons for what didn’t work so well.
The Microsoft 365 Migration Tutorial For Beginner.pptxoperationspcvita
This presentation will help you understand the power of Microsoft 365. However, we have mentioned every productivity app included in Office 365. Additionally, we have suggested the migration situation related to Office 365 and how we can help you.
You can also read: https://www.systoolsgroup.com/updates/office-365-tenant-to-tenant-migration-step-by-step-complete-guide/
Have you ever been confused by the myriad of choices offered by AWS for hosting a website or an API?
Lambda, Elastic Beanstalk, Lightsail, Amplify, S3 (and more!) can each host websites + APIs. But which one should we choose?
Which one is cheapest? Which one is fastest? Which one will scale to meet our needs?
Join me in this session as we dive into each AWS hosting service to determine which one is best for your scenario and explain why!
5th LF Energy Power Grid Model Meet-up SlidesDanBrown980551
5th Power Grid Model Meet-up
It is with great pleasure that we extend to you an invitation to the 5th Power Grid Model Meet-up, scheduled for 6th June 2024. This event will adopt a hybrid format, allowing participants to join us either through an online Mircosoft Teams session or in person at TU/e located at Den Dolech 2, Eindhoven, Netherlands. The meet-up will be hosted by Eindhoven University of Technology (TU/e), a research university specializing in engineering science & technology.
Power Grid Model
The global energy transition is placing new and unprecedented demands on Distribution System Operators (DSOs). Alongside upgrades to grid capacity, processes such as digitization, capacity optimization, and congestion management are becoming vital for delivering reliable services.
Power Grid Model is an open source project from Linux Foundation Energy and provides a calculation engine that is increasingly essential for DSOs. It offers a standards-based foundation enabling real-time power systems analysis, simulations of electrical power grids, and sophisticated what-if analysis. In addition, it enables in-depth studies and analysis of the electrical power grid’s behavior and performance. This comprehensive model incorporates essential factors such as power generation capacity, electrical losses, voltage levels, power flows, and system stability.
Power Grid Model is currently being applied in a wide variety of use cases, including grid planning, expansion, reliability, and congestion studies. It can also help in analyzing the impact of renewable energy integration, assessing the effects of disturbances or faults, and developing strategies for grid control and optimization.
What to expect
For the upcoming meetup we are organizing, we have an exciting lineup of activities planned:
-Insightful presentations covering two practical applications of the Power Grid Model.
-An update on the latest advancements in Power Grid -Model technology during the first and second quarters of 2024.
-An interactive brainstorming session to discuss and propose new feature requests.
-An opportunity to connect with fellow Power Grid Model enthusiasts and users.
What is an RPA CoE? Session 1 – CoE VisionDianaGray10
In the first session, we will review the organization's vision and how this has an impact on the COE Structure.
Topics covered:
• The role of a steering committee
• How do the organization’s priorities determine CoE Structure?
Speaker:
Chris Bolin, Senior Intelligent Automation Architect Anika Systems
Essentials of Automations: Exploring Attributes & Automation ParametersSafe Software
Building automations in FME Flow can save time, money, and help businesses scale by eliminating data silos and providing data to stakeholders in real-time. One essential component to orchestrating complex automations is the use of attributes & automation parameters (both formerly known as “keys”). In fact, it’s unlikely you’ll ever build an Automation without using these components, but what exactly are they?
Attributes & automation parameters enable the automation author to pass data values from one automation component to the next. During this webinar, our FME Flow Specialists will cover leveraging the three types of these output attributes & parameters in FME Flow: Event, Custom, and Automation. As a bonus, they’ll also be making use of the Split-Merge Block functionality.
You’ll leave this webinar with a better understanding of how to maximize the potential of automations by making use of attributes & automation parameters, with the ultimate goal of setting your enterprise integration workflows up on autopilot.
5. What is Agile?
• Software development framework
• Based on adaptive planning
• Used since 1995 (Scrum)
6.
7. Responding to change
Features: 6 months
As Defined
In Changed Form
Not Wanted Anymore
In Changed Form Not Wanted Anymore As Defined
Standish
Group,
Chaos
Report
22. Story&ID:& Priority:
high
Photo album privacy
Size:
Descrip/on: 13
As&a&...
photographer
I&want&to&...
make some photo albums private
So&that&...
I can have a backup of my personal
photos online
23. Acceptance(Criteria
1. I can set the privacy of photo albums
2. I can see my private albums
3. My private albums are not visible to others
26. Acceptance tests
• Check that the implementation
matches the intent
• Focus on shared understanding by
developers, testers and business people
• End to end
27. Scenarios
• Create a new private album
• Make a public album private
• Make a private album public
<vertical slices through the acceptance criteria>
28. Examples
Given I create an album named “My holiday”
When I choose to make it private
Then I can see the album “My holiday”
But Kai cannot see the album
29. Examples
Given ... <something we accept to be true>
When ...<indicates the event in a scenario>
Then ...<indicates the expected outcome>
42. Good practices
• Hide unnecessary detail
• Make tests independent
• Don’t test absolutely everything
43. Declarative vs. imperative style
Scenario: transfer money (imperative)
Given I have $100 in checking
And I have $20 in savings
When I go to the transfer form
And I select "Checking" from "Source Account"
And I select "Savings" from "Target Account"
And I fill in "Amount" with "15"
And I press "Execute Transfer"
Then I should see that I have $85 in checking
And I should see that I have $35 in savings
44. Declarative vs. imperative style
Scenario: transfer money (declarative)
Given I have $100 in checking
And I have $20 in savings
When I transfer $15 from checking to savings
Then I should have $85 in checking
47. Why I like ATDD
• Ensures the intent is well understood
• Ensures the implementation matches the
intent
• Ensures the implementation keeps matching
the intent
51. Unit tests
• Check that the program behaves as the
developer thinks it should
• Tend to be focussed on the structural
(internal) quality of the code
• Hard for testers and business people to
understand
58. Deployment pipeline: Commit stage
• Create deployable artifacts
• Or fail fast and notify the team
• Triggered by CI server
• 5 minutes or less to run
• Jenkins, TeamCity, etc
59. Continuous integration is a practice not a tool
• Commit regularly (at least once a day)
• Fix any broken build immediately
• Write automated tests
60. Deployment pipeline: Acceptance test stage
• Verify acceptance criteria have been met
• Verify business value
• Run in parallel
• Refactor
61. How to get started
• Create a walking skeleton with placeholders
• Automate the build and deploy process
• Automate unit tests and code analysis
• Automate acceptance tests
• Evolve the pipeline
63. Call to action
• Work on Melomel & Cucumber
• Participate in CI projects (Jenkins)
• Steal from Ruby on Rails :-)
64. Contact me
Sandy Mamoli
@smamol
sandy@nomad8.com
Editor's Notes
- Debating with myself - agile or not\n- come from Agile space\n- good technical practices, increase quality & software health \n- whether agile or not great benefits - if agile even more important \n\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
- WHO?\n- ABOUT DELIVERING QUALITY\n- will focus on those 3 \n- who is doing them already? who CI? Who user stories? Who acceptance testing?\n
\n
- Who? Experience?\n
\n
- recommended development methodology for UK government projects \n-> rapidly emerging standard for organisations providing critical business functionality\n\n
- half life\n- rate of change (1980s 10 - 1990s 5 - 2000 1-2 - 2005 (3 - 6 months), \n- process to accommodate rate of change without ending in chaos\n\n
- to accommodate this rate of change we need to find a framework \n -> accept reality, manage change, flexibility - without ending up in chaos\n- Here&#x2019;s how it works\n
- primary measure of progress = working software \n- NO DEFECTS\n- 1) Planning (90%), 2) Done/ROI\n
- functionality is implemented in order of business priority (balancing people and technical risk)\n- management of risk - run out of resources, feedback\n\n
- quality obsessed\n- DoD: -> no known bugs -> airplane disasters \n=> tech. practices help us \n\n
\n
\n
- requirements bugs\n- code bugs\n
- only waterfall numbers - not for Agile => proves that testing earlier reduced the cost of fix\n- Why?\n
- Building the right thing - building the thing right\n
\n
- Step back and explain Agile requirements\n\n
\n\n\n
- Independently testable by user/business person\n\n
- define the boundaries - conditions of satisfaction\n- State an intent not a solution - Independent of implementation\n- Help a shared understanding\n
- focus on more\n
- focuses on user stories\n- 56% of all defects are requirements defects\n
- Does it do what we want?\n- Also called BDD, ATDD, Specification by Example\n
- How can we test? Define scenarios as vertical slices through the acceptance criteria\n\n
- Very useful as beginning with end in mind\n- It is okay to have more than one outcome in a scenario -> AND, BUT\n\n
- Template for examples\n- Given: not a pre-condition, true => e.g. given i have $20 in my account, given monday is a holiday\n\n
- wouldn&#x2019;t it be great if we could automate our tests?\n- of course we could test manually - would be a great achievement already - but ...\n- ESPECIALLY AGILE\n
- 1 of many free tools => anyone using?\n- BDD in a Nutshell\n-> mainly from the RoR world, Java, .Net => Flex, CF (www.cukes.info)\n\n
- Melomel =>Melomel is an API for accessing ActionScript objects in the Flash virtual machine through external languages. \n- Currently only available for Ruby but it is actively being expanded to other languages.\n\n
- Will guide you though full example - feature/scenario/example/steps/cucumber\n- Simple CRUD\n
- Feature files\n- Scenario headings \n- Happy path, 1 or 2 exception paths (if happened in the past, or risky)\n\n
- Declarative language (avoid click xyz, anything GUI specific) as much as possible \n- Keep implementation independent, keep understandable for non developers\n- Where do I hide the details? Connect the scenarios into code\n\n
- A step is a Given/When/Then/And/But expressed in code\n- Lots of steps come built in (click_link, visit url), possible to nest them\n\n\n
- The cucumber command runs all the *.feature files below the features directory\n- Cucumber is very helpful - generates stubs\n- Tags\n
- Once we have a file with a feature in it we can run it with the cucumber command\n- The cucumber command runs all the *.feature files below the features directory\n
- Tags\n
- details: avoid brittleness (GUI), keep understandable for everyone\n
- What do you think? They do +/-\n- Imperative: more composable -> need fewer step definitions, less work at beginning\n- Declarative: less dependent on GUI, less verbose\n- Balance, taste which easier to read \n\n
\n
\n
- Maintenance, brittle - GUI most expensive, Unit least\n- Happy path, 1 or 2 edge cases - high risk, most common ones\n\n
- good frameworks exist - won&#x2019;t focus to much on it\n
- To get the full benefit => need to run the tests - regular basis\n
- Tie all together - have automation need to run it to get value out of it\n\n
- Tie all together - have automation need to run it to get value out of it\n\n
- Tie all together - have automation need to run it to get value out of it\n\n
Re-iterate goals: small valuable chunks, low cycle time, hgh quality\n
- Jez Humble\n=> release candidates\n- AUTOMATED releases!!!\n\n
- done for each user story (facebook etc)\n- same exit criteria, work in parallel\n- AUTOMATED releases!!!\n
- drill down into 3 automated parts: commit, acceptance, load & capacity\n- coverage: no numbers; commit stage fail if coverage or quality increases (warnings)\n- if it breaks: team&#x2019;s highest priority to fix it!!\n
- Small increments\n- Team agreement\n=> send to other session\n\n
- CI server does this \n
- Start by having one or two of each type test and add to that\n- Unit: new code, every time a bug\n- Acceptance: Most common, if manually testing more than once automate\n- Stuff just talked about - tie back together\n