Investment Banks. Investors. Investor Relations.

New York | London | Raleigh| South Africa| Nashville| www.ipreo.com

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 ConceptRole of a tester in agileHow do you build a T-shaped

TesterCulture 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

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/3rd 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 Coach Release 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 planning @ 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 planning @ 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