Agile2016

Abstract:
Regardless of whether your data warehousing (DW)/business intelligence (BI) team is dedicated to Scrum, a fan of Kanban, or focused on XP, “Agile” in any form calls for small increments of potentially deployable results – which means that QA is essential on a regular, frequent basis. As we develop these small increments, we need to not only test the new development, but also regression test what we’ve already built. Our test suite grows larger with each iteration, and manual testing quickly becomes infeasible. Agile requires that we automate our tests so that regression testing doesn’t become a development bottleneck.
Test automation is one of several key technical enablement practices that allows teams to be more successful in their agile journeys. While there are lots of test practices and automation tools out there for software development teams to leverage, very few are targeted to data-related development and testing. Agile analytics practitioner Lynn Winterboer and DW/BI architect and developer Cher Fox will share essential agile test foundations and data-focused test automation technologies to help data warehousing and business intelligence teams get a leg up on this important agile practice, including a demo of how this works!
Agenda:

• Why is test automation important for agile DW/BI teams?
• Why aren’t all DW/BI teams automating their tests today?
• What is the path to data-focused test automation?
• Where to start? What tests to automate first?
• Demo of a simple test automation tool any DW/BI team could build and use

Learning Outcomes:

• The intent of this presentation is to:
• 1) Educate DW/BI folks on why test automation is important to an agile journey;
• 2) Clarify that a solid foundation is needed in testing practices and principles before automation is useful;
• 3) Show that automation is easy to do, using simple DW/BI tools and coding languages.

Attachments:

• Test_Automation_for_DWBI_teams_Agile_2016_WinterboerAgileAnalytics.pdf

Abstract:
As more and more security-critical software applications are developed, tested, and delivered using agile, incorporating software security practices into an agile testing process becomes essential. This talk focuses on how to successfully incorporate security testing into all aspects of agile testing: development of security acceptance criteria & security stories, unit & component level security testing, security testing of user stories, and integration of security testing approaches into subsystem, integration, system, and regression testing activities. Practical lessons learned from integration security testing (both manual and automated approaches) into real-world agile projects will be discussed. Tools and automated techniques to support security testing within an agile environment are presented and demonstrated. Tips for getting started with security testing are discussed as well.
Learning Outcomes:

• How to get started integrating security into agile testing activities.
• What some of the most important security testing activities are.
• Where software developers and agile testers should focus their security testing efforts.

Attachments:

• Agile_Alliance_2016_-_Security_Testing.pdf

Abstract:
There has been a great deal of talk about the role of testers especially in agile teams. With many people questioning whether there really is a need for professional/dedicated testers in agile. Large amounts of effort and discussions have taken place regarding the use of 'automation' to replace manual testing and how testers can be replaced by this in agile teams.
During this session we will discuss some of these, and other, common misconceptions of testing and testers by means of audience participation to see how many of these misconceptions/myths are prevalent in the software testing industry.
Some examples of this include:
Testing is a bottle neck
Testing happens at the end of the sprint.
We do not need to test we can get our users to test it.
We then look at what happens during a typical software development iteration, with a focus on the software testing activities. We will discuss the problems with automation and why it may not be the 'golden goose' that is typically promoted as being able to replace testing. The discussion will introduce the test execution model and show what can and cannot be automated. The test execution model will introduce the concepts of tacit and explicit knowledge and looks at what we learn from philosophy. As part of this discussion/debate we will look at what is it that makes us unique as human rather than as automatons.
Following this we will focus on what the future holds for testers and that path they can follow. We will look at different roles that a tester can take responsibility for in agile teams, roles that utilize the unique skills of testers. During the talk John will introduce roles such as quality advocate and testing coach and draw from his own personal experience how these roles can be incorporated into agile teams. At the end of the talk as a group we will create an action plan of ideas we want to take away and trial within our own agile teams to show that testing is far more than ticking boxes.
Learning Outcomes:

• The future role of testers will become more flexible and adaptive
• Not everything can be automated nor should we automated everything we can.
• There will be less hands on testing and more supporting/consulting.

Attachments:

• Does_Agile_still_need_testers_agile2016.pdf

Abstract:
Dependencies are present in every project; some code over here needs code over there, and we can't be sure the code over here works until the code over there is done! Well, sure, that makes a kind of sense. But often teams take this to an extreme; they allow themselves to become blocked, or even worse, hinder other teams from making progress due to their demands. We'll learn how the types of dependencies (defined here as Blockers, Yaks, and Mirrors) can be recognized, and overcome and especially how true blockers can be avoided with good understanding of the system architecture and a grasp of test automation techniques.
If you're a tester or programmer:

• You'll learn how to recognize and diagnose the types of dependencies you'll face.
• You'll be (re)introduced to Agile Testing models and automated checking techniques (with a twist!) that will help you overcome these dependencies.
• You'll be confident that you can test your software without having to ALSO test the software that you depend on.
• You'll (maybe) be able to convince the people who run the software that depends on YOUR software that they don't need to test YOUR software.

If you're a manager or architect:

• You'll learn about the dependency traps you're setting by how you decide on and set up processes and tooling.
• You'll be better equipped to recognize the dependencies you're creating between teams and organizations that create the components that make up your solutions.

If you're anybody involved with software development:

• You'll approach common software dependencies that you've always assumed to be insurmountable in a new way.

You'll learn how to Test Your Own Stuff!
Learning Outcomes:

• Learn why and how dependencies are the biggest obstacle to Agile success.
• Learn ways to mitigate traditional testing bottlenecks between teams (whether Agile or not).
• Learn (or re-learn) Agile testing models and key automation techniques to specifically combat dependency traps.
• Learn from specific examples of dependencies being overcome in real-world software solutions used by millions.
• You'll be confident that you can test your software without having to ALSO test the software that you depend on.
• You'll (maybe) be able to convince the people who run the software that depends on YOUR software that they don't need to test YOUR software.

Attachments:

• Test_Your_Own_Stuff_-_Agile_2016.pdf

Abstract:
Craftspeople from all disciplines refine their language to sharpen their knowledge and communicate precisely about the way they work. A handful of practitioners have worked to expand testing language but most testers have not learned to adopted it. Some testers even reject the necessity to improve their language skills, choosing instead to perpetuate misunderstandings. We can either start improving the way we talk about testing, or continue fooling people into believing testing does not require skill.
In this session, I’ll teach you testing-related language skills that may change how you think about and explain your testing work. One example is Safety Language, which is a precise way of speaking that separates observation from inference. Safety Language can help testers highlight uncertainty to trigger important discussions. I’ll show you a technique I use to remove ambiguities from my own verbiage as well as helping other people remove them. This technique is especially helpful when collaborating with other Agile teams on tasks such as integration testing. We’ll use group discussion, videos, exercises, and lecture in an attempt to increase our command of testing language...which, in turn, may even strengthen our reputations as excellent testers.
This session targets testers but contains ideas that might be helpful to anyone working on a software development team.
Learning Outcomes:

• Exposure to more than 20 (old and new) testing terms to help discuss testing and share knowledge.
• Why and how to speak precisely about the difference between inference and observation.
• Tester language heuristics that can help improve communication.
• Awareness of personal pronoun usage and its affect on testing-related communications.
• How Agile board column names affect team language and reduce or improve teamwork.

Attachments:

• Walk_The_Talk.pdf

Abstract:
If you're fortunate enough to have convinced your organization that "quality" matters at all, congratulations! That's the first step. You've probably walked right into the next pitfall, and you may or may not know it yet: when all roles are passionate about "quality", but no one agrees on what it is. Or worse, everyone agrees, but you don't realize you're all missing something.
In this session, we'll expose how the use, overuse, and abuse of the word "quality" can mislead even the best-intentioned agile teams and organizations. It's not about role vs. role—no one is immune, not even people with "quality" right there in their job title.
You'll learn about a specific common "quality" anti-pattern, the harm it causes, how to spot it, and how to solve it. We'll practice communication strategies that will help you understand and influence your colleagues more effectively.
We all want to make our products better. It's time to stop talking about "quality" and learn to say—and more importantly, do—what we really mean.
Learning Outcomes:

• The full range of activities we (ought to) mean when we say "quality"
• What is often lost when we use "quality" as an umbrella or shortcut
• How to dig deeper and discern what a "quality"-using colleague really wants
• How to improve communication with better alternatives to "quality"
• How to improve quality by moving away from "quality"

Attachments:

• I_Do_Not_Think_It_Means_What_You_Think_It_Means_-_Why_We_Should_Stop_Saying_'Quality'_by_Cheryl_Hammond.pdf

Abstract:
Consisting of simultaneous test design, execution, reporting and learning, Exploratory Testing done well can be a powerful tool in any team member's arsenal. Done poorly, it can create confusion without adding much value. In this hands-on introduction, attendees will bring a laptop, pair with a buddy, hear a little theory on test design, open a real application and get to testing. We'll have some more theory, test a second application, then a third, and finally conduct a retrospective to cover what people have learned. In the retro, or time following, we can talk about how teams can adopt these techniques in a more formal way to compress testing into iterations, sprints, and other timeboxes while improving coverage and transparency of what is tested.
The test design elements of the class will include quick attacks and consistency heuristics, two ways to generate test ideas when time is tight and information limited.
Learning Outcomes:

• The 'what' of Exploratory Testing
• How To Perform Quick Attacks
• And how to integrate Exploratory Testing into existing practice
• The Role of ET in Agile Conversion

Attachments:

• CMoss_MHeusser_ET_Workshop_2016.pdf