Agile2019

Abstract:
Microservices are becoming more prevalent. External behavior of an application depends on multiple services working together. Each service needs to be checked that it both provides the desired behavior as well as handles exceptions and error conditions, such as the inability to communicate with a dependency. Interactions between these services needs to be checked and monitored. Checking behavior does not stop at deployment but needs to continue after release.
From a testing perspective, microservices can be viewed both as mini-applications with external behavior and as internal components. For applications, the externally facing triad (tester, developer, and customer) collaborates to create tests for behavior; for internal components, a different triad (tester, consumer, producer) generates these tests. To properly test microservices, we need to see, feel, touch, heal, and explore them.
See it: Tests need to be visible so that all members of the triad share the understanding of the behavior.

Feel It: Behavior for cross-functional (non-functional) aspects of microservices can be documented in tests.

Touch It: Testing for interactions of microservices can include injection or simulation of faults.

Heal It: Check that telemetry which records microservice interactions can be used to determine failure causes.

Explore It: Testing ought to go beyond just the behaviors described.
With so many aspects, testers need to work as collaborators in specification and tests, not just the test executors. The primary audience for this interactive workshop is for testers involved in microservices. However, it is also appropriate for any role which collaborates on the construction or delivery of these microservices. The session includes both lecture and a set of exercises on specifying and testing microservices.

Learning Outcomes:

• Collaborate on creating microservice specifications with tests
• Create appropriate cross-functional behavior tests for microservices
• Determine a strategy to test microservice interactions
• Explore ways to test telemetry

Attachments:

• Testing Microservices - See It, Feel It, Touch It, Heal It, Explore It - Ken Pugh - Agile 2019.pdf

Abstract:
Automation framework development can be considered similar to application development. The framework would greatly improve if the the same design principles used to write application code are leveraged to build it. By leveraging the 4 pillars of Object Oriented Programming in writing your automation framework, we can achieve the same level of efficiency as your application. Here are some examples we will discuss during the presentation:

• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

Software development is built on the foundation of reusability and reliability. By making the steps in scenarios reusable and scenarios or test cases independent, we can lower the test maintenance costs and improve stability.

Learning Outcomes:

• We expect that attendees will have a better understanding of software development principles such as abstraction, encapsulation, inheritance and polymorphism and how to use these concepts in the development of automation frameworks

Attachments:

• OOP Principles.pdf

Abstract:
Imagine if you could add a more time to your testing, where would you spend it? Although we can't add more hours to our day, we can find time by discovering inefficiencies in our current approach.
Many of us feel like we never have enough time to fully test in a given sprint, cycle or other timeframe. We plan for the best case scenario, but, undoubtedly, something happens with our best-laid plans that cause us to feel like we "just didn't test enough." In this session, we will talk about the five areas that may be causing inefficiencies in your overall approach - to include test planning and duplication of testing to the left of QE. Melissa will discuss these five areas and you'll have a chance to share yours with the outcome to be practical solutions that can be implemented quickly. Once we have the plan to reduce or eliminate the inefficiencies, we'll talk about areas you may be able to spend more time in or add to your overall testing strategy – effectively adding more time to do what you do best!

Learning Outcomes:

• Why is there Never Enough Time?
• What Testing Activities do we Emphasize?
• Where do we Find Inefficiencies?
• How do we Fix them?
• What would you do with that Time Saved?

Attachments:

• Finding Efficiencies in Software Testing_.pdf
• 
  
  • 
    

Abstract:
When should we test our data? From an application development perspective, a unit test against a database isn't a unit test at all. Which makes sense -- connected systems introduce overhead and dependency, both of which reduce stability and decrease productivity during test-driven development (TDD). But if we wait for integration testing, critical functionality can get missed. In this session, we will discuss strategies for filling the data testing gap, directly within a Microsoft SQL Server environment. If you do a lot of work in T-SQL but aren't familiar with TDD, you'll learn the why and how of test-first development. If you're accomplished with unit tests, but never tried them in your database, you'll learn how to apply familiar concepts like setup, mocking, and assertion. We'll spend most of our time walking through a solution based on a real-world project, specifically using the open source tSQLt database unit testing framework.

Learning Outcomes:

• what TDD is
• benefits of TDD
• the practice of TDD
• how to obtain and install the tSQLt unit testing framework in SQL Server
• how to write unit tests in SQL using the tSQLt framework
• experience walking through an example scenario

Attachments:

• HeyYouGotYourTDDInMySQLDB_JeffMcKenzie_Agile2019_2019-08-07.pdf

Abstract:
Sometimes we allow ourselves to drown in work… We hear it all the time: we as testers complaining at retrospectives to our teams that we do not have enough time to test everything. We, as testers, often work overtime the last week of a sprint to ensure the definition of done is accomplished. Why do they do this? Why do we, as testers, enable the bad behaviors of “Scrummerfall” or a lack of whole-team ownership of quality? In this talk you will learn techniques that allow you to test smarter, not harder, and enable the team to have better conversations that make it clear what they are testing in the sprint. Most importantly, we want you to come out of this session being able to answer the question, “What are you not going to test this sprint?” As well as, how do you receive buy in from stakeholders on such "risk based" approaches. You will be able to take home 5 practical risk based approaches that allow you to swim, not sink, by focusing your own and your team’s efforts on testing the right thing.

Learning Outcomes:

• The attendees will come away with five risk based testing techniques to take back to their scrum teams teach them in ways limit scrummerfall
• - 3 amigos
• - Test Ideas
• - Test Case Gaps
• - Pareto
• - All Pairs
• Team based conversation techniques
• Stakeholder buy in on the risk based decisions

Attachments:

• Help! I am Drowning In 2 Week Sprints...How do I determine what NOT to Test!_Agile 2019.pdf

Abstract:
Testing software is a critical responsibility, but testing is not a synonym for quality. Shifting your approach to software quality from black box testers, to quality coaching could lead to delivering higher quality products. In this talk, learn about QA coaching and what value these coaches can add to development teams.

Learning Outcomes:

• An introduction to a new model for QA + tips for collaborating with developers and coaching quality.

Attachments:

• Rethinking quality and the engineers who protect it - Agile 2019 (1).pdf