TestCon Europe 2021

Hybrid Edition

September 7-9

Vilnius and Online

Joel Montvelisky

Chief Solution Architect, Co-Founder & International Speaker

PractiTest, Israel


Joel Montvelisky is a Co-Founder and Chief Solution Architect at PractiTest. He has been in testing and QA since 1997, working as a tester, QA Manager and Director, and a Consultant for companies in Israel, the US and the EU. Joel is also a blogger with the QA Intelligence Blog, and is constantly imparting webinars on a number of testing and Quality Related topics. Joel is also the founder and Chair of the OnlineTestConf, and he is also the co-founder of the State of Testing survey and report. His latest project is the Testing 1on1 podcast with Rob Lambert, released earlier this year – https://qablog.practitest.com/podcast/. Joel is also a conference speaker, presenting in various conferences and forums worldwide.

Test Management when Testing is the Whole Team’s Responsibility

Time & Date

9:00, 13 October







So the mantra goes, in today’s development world testing is the responsibility of the whole team. But for 90% of organizations (or more) this does not really translate into practice and testing is still mostly the responsibility of the testers.

There are many reasons for this, but one of the most common is that people who were never asked to test formally (in the present or past) do not really know how to test correctly. Even if and when they want to test, they still approach the task afraid of not doing the right thing, and in desperate need for someone to manage the process, guide their testing work, and orchestrate the process for the project or team.

Testing can be everyone’s responsibility, but Test Management still needs to be the responsibility of a Test Architect or Test Specialist. In this workshop, we will review some of the main responsibilities and differences between managing testing in a traditional team versus the work needed on a whole-team-testing-approach.


Part 1: Why whole team testing?

  • Understand why all team testing is more important today than in the past.
  • What organizations are pushing this forward and which organizations still prefer to continue working with more traditional approaches..

Part 2: Why developers can’t test and what can we do about it?

  • The main difference between a tester and any other member of the team (not only developers) when it comes to testing.
  • Analysis of testing tasks that can be done better by other team members and not a tester.
  • Why whole team testing is a better approach when done correctly

Part 3: Whole team test management:

  • Common pitfalls when testing tasks are performed by the whole team.
  • How to enable your team to test and motivate them to do it as part of their process.
  • What is different about the approach to use when you need to manage non-testers as part of your testingtask force.

Part 4: From Test management to Quality management

  • Shifting left and right as part of the inclusion of additional resources into your testing team.
  • How to enable your team to test and motivate them to do it as part of their process.
  • What is the role of the Quality Architect in today’s integrated development teams.


– Understanding the differences between the different team members when it comes to testing and creating testing artefacts for each team member accordingly.
– Demonstrating the differences in the infrastructure needed to facilitate whole-team-testing.
– Plan and apply recommended practices for ensuring testing tasks are done by all team members, focusing on understanding what tasks can be done by what team member and what do you need to ensure this happens correctly.
– Introduce and recognize common pitfalls of all-team-testing and create & implement ways to work around them.

Target audience

The target audience includes those test managers and team leaders that are part of organizations where they practice All-Team-Testing, as well as individuals who want to understand how to correctly deploy this type of approach in their organizations. The workshop does not require any previous knowledge or experience, but it will help if the people attending have experience working in Agile environments.

Technical requirements

There are no technical requirements for this workshop.

« Back