The tester’s mindset is often associated with attempting to break a system. Unfortunately, this leads to a competition between them and builders [Laing 2016] while a collaboration is expected between team members [Schwaber 2020]. From a team point of view, involved people’s strategy may be summarized with the following parties:
Product Owner (PO)
(*) From a Scrum point of view, Developers and Testers are supposed to be on the same boat and therefore collaborate and help each other [Schwaber 2020].
From a larger agile point of view, it is also admitted that regardless of Scrum roles, an agile team is much like a cooperative infinite game [Cockburn 2006].
Considering the gaming theory, it is generally admitted that from the “Prisoner’s Dilema” [Mero 1998] that cooperation leads to a win-win situation. Game theory applied to agile organizations effectively reveals that cooperation wins over competition [Hazrati 2010] that should be a good rationale for leading the team to aim a collaboration on designing a better system.
Unfortunately, the board above may look quite naive because it omits extra mindset such as ignorant, pressured or pragmatic people and “traitors” e.g.
While the first item is promoted with too simple acceptance criteria, the second one should be avoided to avoid negative security impacts on the product.
Under those hypotheses, some Developers have a different strategies such as
Considering the Nash equilibrium, the knowledge of everyone’s strategy should be clear to enable maximum gain for each player [Nash 1950]; this infers that people must be aware of those latest extra strategies which infer competing against them to reach an acceptable level.
Knowing this, “Designing a better system” is not limited to the delivered product but also the system that builds the product. Therefore, it appears that there could be a 5th value in Laing’s agile testing manifesto [Laing 2016]:
“Collaboration over competition”
This latest approach leads to taking competition into account but fostering collaboration first for it is noticeable that this latest form of testing also comes first because shift left testing leverages quality as soon as possible which implies built-in quality to prevent bugs.
As per pressure matters, the PO is the one that decides on the most valuable things to release with Story Splitting [Lawrence 2012] and Story Mapping [Patton 2014] techniques and eventually apply some Error Budgeting to handle low quality releases.
Relying only on acceptance tests defined at each User Story (US) notably thanks to a “3 Amigos” workshop is obviously not enough. This is why agile Teams should perform Exploratory Testing as well to spot “lazy” developments. Gemba walks ,X-Teams and Double Loop Learning [Argyris 1977] or PanTesting are also useful to compel Developers to extend acceptance testing with a User eXperience (UX) mindset and create eventually extra US that would complete the feature with extra items.
As seen above, jeopardy infers competing with the so-called “Traitors”. To do so, security testing provides different testing strategies [OSSTMM 2010] [Moustier 2019-1]:
Those many strategies show the many points of view for both Developers and Tester/Attacker and provide hints when there are some benefits with ISTQB’s independent testing approach [ISTQB 2018] and when cooperation between Developers and Testers have some added value.
Since most of Agilitest users are rather turned towards feature than coding for cultural reasons, Agilitest is often used by Business Owners located outside development teams that which leverages independent testing ; however, Agilitest can be used in any of the testing strategies, from a Reversed or Double Blind testing strategy to a collaborative way with a 3 Amigos workshop in a Tandem approach.