Investment Banks. Investors. Investor Relations. New York | London | Raleigh| South Africa| Nashville| What’s in your cup of T?

About Mary Thorn Chief Story Teller of the book “The Three Pillars of Agile Testing and Quality” written by Bob Galen, Mary Thorn is Director of Software Test Engineering at Ipreo in Raleigh, NC. Mary has a broad testing background that spans automation, data warehouses, and web-based systems in a wide variety of technologies and testing techniques. During her more than seventeen years of experience in healthcare, HR, financial, and SaaS-based products, Mary has held manager and contributor level positions in software development organizations. A strong leader in agile testing methodologies, she has direct experience leading teams through agile adoption and beyond.

Outline  T-Shape Concept  Role of a tester in agile  How do you build a T-shaped Tester  Culture change

I - Shaped  In Waterfall everyone was a specialist!!!  In some agile companies, everyone is a generalist!!!

Transition over time

T-Concept  The idea I am presenting here is the T-Shaped people idea. It’s not mine, I believe Tim Brown (CEO of IDEO) coined it in the 1990s to describe the new breed of worker.

T-Concept

 Skilled testers, yet are skilled in a number of supporting domains.  They excel at their specific element of testing yet they bring in skills from other areas, or they use their skills to fulfill other roles within the business.  In start-ups or fast moving companies the ability to work across multiple disciplines has some obvious benefits.  One person capable of fulfilling a few roles reasonable well seems like good value and a good asset to delivering value.

T-Concept  Anyone, can contribute a lot more to the business than their standard role traditionally dictates. The tester’s critical and skeptical thinking can be used earlier in the process. Their other skills can be used to solve other problems within the business. Their role can stretch to include other aspects that intrigue them and keep them interested.  Testing is more than finding bugs; it’s about exploring the product, discovering what the product needs to be, discovering the market needs (i.e. A/B Testing), discovering what the product actually does, working out whether the product is suitable for the context of use, questioning the process, improving the process, helping to design the product, improving the product, helping to support it, helping to promote it and ultimately working with the team to deliver value.

T-Concept  And all of the above might explain why myself find it so hard to recruit great testers (for our contexts), yet other managers I speak to can find “good” candidates at every street corner.  We demand more than just testing skills. We demand many other skills that complement a testing mindset. Skills that help us deliver value.

Role of Tester in Agile  Customer Advocate  Business Analyst  Manual Tester  Automation Tester  Release Engineer  Development Peer(Pairing)  1/3 rd of the 3 Amigos  Scrum Master  Agile Process Champion  Risk Raiser  Project cordinator  Etc…

T-shaped Agile Team  We’re still working on the balance between roles and expectations, and the balance shifts, typically in response to the market.

Generalization  Generalists are testers who can fulfill a number of different roles across the organization whilst still maintaining a core skill of testing. How Google Tests Software -There isn't an actual testing organization at Google. -Test exists within a Focus Area called Engineering Productivity. -Eng Prod owns any number of horizontal and vertical engineering disciplines, Test is the biggest. Report in to Eng mgr. -Developers test Atlassian Jira - -QA assistance – 6 testers for 65 developers -Core job is to assist developers in testing and train them.

How do you build a T Shape Tester  Being a T-Shaped person means having skills that can be useful across other domains. Having T-Shaped tester roles means encouraging testers to fulfill a number of roles. Learning the skills needed, or already having the skills in place (i.e. already being a T-Shaped person) means people can either slip straight in to the role, or they may have to seek out learning's, coaching and mentoring. And that’s where good management, teams and community engagement can come in.

Dreyfus Model of Skill Acquisition

Learning  Potential trainings How to write a good user story How to be a Scrum Master How to write UI automation Sitting with Customer Support Sitting with Implementation team Domain knowledge How to write a good test cases Release process 101 Pairing with a developer Scrum 101 Risked Based testing Basic Communication skills needed for a team member.

Coaching  Coaching is training or development in which a person called a coach supports a learner in achieving a specific personal or professional goal. The learner is sometimes called a coachee. Occasionally, coaching may mean an informal relationship between two people, of whom one has more experience and expertise than the other and offers advice and guidance as the latter learns; but coaching differs from mentoring in focusing on specific tasks or objectives, as opposed to general goals or overall development

Mentoring  Mentorship is a personal developmental relationship in which a more experienced or more knowledgeable person helps to guide a less experienced or less knowledgeable person. The mentor may be older or younger, but have a certain area of expertise. It is a learning and development partnership between someone with vast experience and someone who wants to learn.

Guilds  Guilds are a self-organizing group of people with common interests. It is a natural forum for social interactions that build relationships that, in turn, promote cooperation, cohesion, and productivity.  Guilds provide a horizontal communication layer across our Product Engineering teams. Engineers, testers, and other staff use them to set their own missions, to establish technical roadmaps, to take on joint tasks for their grassroots initiatives, and to promote education through experiential learning.

Characteristics of a T-shape tester

Culture and implications  Development Builds, Testers test, and Product designs WRONG Partner in the building process Not the inspector of the process.

T-Shaped Test Manager Agile CoachRelease Manager Testing

3 Pillars of Agile Quality and Testing 23 Development & Test Automation Pyramid-based Strategy: (Unit + Cucumber + Selenium) Continuous Integration Attack technical infrastructure in the Backlog Visual Feedback – Dashboards Actively practice ATDD and BDD Software Testing Risk-based testing: Functional & Non- Functional Test Release & Sprint levels Exploratory Testing Standards – checklists, templates, repositories Balance across manual, exploratory & automation Cross-Functional Team Practices Team-based Pairing Stop-the-Line Mindset Code Reviews & Standards Active Done-Ness Aggressive Refactoring of Technical Debt User Stories, “3 Amigo” based Conversations Whole Team Ownership of “Quality” Building it ‘Right’; Building the ‘Right’ Thing Healthy – Agile Centric Metrics Center of Excellence or Community of Practice Strategic balance across 3 Pillars; Assessment, Recalibration, and Continuous Improvement

Foundation of the 3 Pillars 24 Whole Team Ownership of “Quality” Building it ‘Right’; Building the ‘Right’ Thing Healthy – Agile Centric Metrics Center of Excellence or Community of Practice Strategic balance across 3 Pillars; Assessment, Recalibration, and Continuous Improvement Whole team view includes building it right, everyone tests, Focus on features/stories, confirmation, conversation, and getting them staged properly OVER testing 4-tier metrics: Quality, Value, Prediction, Team Agile strategies need light-handed “steering”; establish a CoE (heavier weight) or a CoP (lightweight) Consider finding an assessment framework and then tying it to your strategy measurement, recalibration, and continuous improvement. Make the Foundation visible thru Information Radiators and metrics

Development and Automation Pillar 25 Development & Test Automation Pyramid-based Strategy: (Unit + Cucumber + Selenium) Continuous Integration Attack technical infrastructure in the Backlog Visual Feedback – Dashboards Actively practice ATDD and BDD A central part of agile adoption is focusing on CI, 3- tiered Automation development, and Dashboards to begin incrementally building coverage for faster feedback on changes. In the interim, Hardening or Stabilization Sprints and having a risk-based Release Train concept help It’s important that Test or QA not ‘own’ the tooling or all of the automation efforts. The strategy can come from Test, but the tactical automation development is best left to the team. Mature teams invest in automation as part of Done- ness and continually on their backlogs

Software Testing Pillars 26 Software Testing Risk-based testing: Functional & Non- Functional Test Release & Sprint levels Exploratory Testing Standards – checklists, templates, repositories Balance across manual, exploratory & automation Exploratory Testing (Charter / Session based and paired) can be an incredibly effective way to establish a whole-team, collaborative view towards quality and testing. It also emerges new tests. Leverage ‘plans’ as a whole-team collaboration mechanism…and do plan. Do not measure testing or tester progress; instead, measure throughput, output, sprint outcomes, and done-ness escapes at a team level. You need a balanced test team; not everyone needs to be able to program. But everyone needs to be skilled testers. Agile testing is a Risk-Based play in every Sprint and across a release sequence. Don’t forget your techniques!

Cross-Functional Team Pillar 27 Cross-Functional Practices Team-based Pairing Stop-the-Line Mindset Code Reviews & Standards Active Done-Ness Aggressive Refactoring of Technical Debt User Stories – 3 Amigo based Conversations One of the hardest areas to get ‘right’ culturally. It needs leadership alignment from Quality/Testing to Product to Development and a consistent voice of whole-team approaches. This is where LEAN lives, where whole-team collaboration happens, where professionalism and craftsmanship are held dear. I like the view of testers becoming the VOC, champions of quality, and consistent questioners of what is being build. Are we solving the right problems…as simply as possible. Notions of Minimal Viable Product / Feature help with focus. And yes Virginia, there ARE standards, templates, and a focus on consistency!

Wrapping it Up