Project discovery workshops, most reading this article will be familiar with the term and what generally takes place during them and therefore why they are so critically important to the success (or failure) of a software development project.

The way we go about them at Arrk follows our defined and flexible EmbArrk methodology, which means we usually spend a two or three week period at the customer’s location (the gemba) where our team collaborates with all customer stakeholders to envision and elaborate, even if at a high level, the solution for the customer enunciated and (Arrk) elicited business needs/problems that the customer is facing.

The moot question that this article looks to answer is what value the tester brings during discovery workshops and why we need their participation. The EmbArrk crew, at most times, comprises a Business Analyst, a Technical leader, a UX/UI champion and a Test leader. As much as the Business Analyst drives these discovery workshops, the technical and testing member play much-needed complementary roles (i.e. 3 Amigos).

The tester’s contribution to the discovery process can be better understood if her role is clarified.

The Case for Curiosity

Testing happens better on the basis of understanding of what the domain is; be it the business, its mechanics, or the application in use. Testers, by nature, possess the needed inquisitiveness and more to probe deeper through questions, observations and hypothesis.

This curiosity complements that of Business Analyst and helps the domain knowledge to unfold broader and deeper benefiting the entire group. The tester by virtue of the customer provided overview sessions, understands first-hand what the business drivers are, what it expects to gain from the solution, what the quantifiable measures linked with the objectives are, the product roadmap and so forth.

The knowledge and her interaction with the business stakeholders facilitates the drawing of system boundaries, components within which interact and how, the workflow, who uses them etc. She even mentally or physically creates user personas to focus her tests and impersonate these stakeholders when testing.

The Case for Testability

The user story development benefits as the tester influences the story details, the acceptance criteria, questioning the likely implementation and so on. A key element that will be at play when the stories get discussed is that of ‘testability’ and the tester is the (Wo)Man Friday that the team desperately needs. Testability at its simplest refers to ‘how we test’. But testing is never truly simple and testability as such is greatly influenced by:

How much is known about the application?

”The difference between what we know and what we need to know is why we test in the first place” – James Bach

It follows then that more the information about the application, its users, testing can get better.

Documentation available (including test cases)?

This aids the application working knowledge thereby helping test better.

Application complexity?

Simply put, the higher the complexity, the harder it is to test. Example; a mission-critical product requires deeper careful testing than a shopping cart application.

Application size?

Example: a multi-module application interfaced with 3rd party apps requires more elaborate testing… more the code, more the bugs that can be expected so tests need to travel far and deep.

User interaction with the application?

When this is learned through observation, usability tests, etc. testers can mindfully work the application like the ‘user’ would.

What technology is used for the application?

Example: an iOS app has different standards to meet requiring a specific testing approach than an Android app. The tester may have knowledge specific to the language, tool and technology which she will utilise to ease the testing effort and efficiency.

What tools can be used to test better?

Example; certain application protocols used may necessitate specific plug-ins to be used when using LoadRunner tool which the tester is best aware of.

Competence of tester?

A more competent tester tests better and faster and highlights issues to ensure a faster feedback loop:

• Technical skills | A more ‘technical’ tester can have richer conversations with the developers so as to target areas to test.
• Soft skills | A tester having more skills on communication, collaboration, negotiation, assertiveness, initiative front is likely to more positively contribute to testing.

Past experience of the tester?

Example; prior exposure to data-warehouse product based testing will make future testing experiences in the same area more effective

Time available for testing?

The more time made available for testing the more stringent the testing will be and conversely, less time allocated for testing can have a negative impact on the effectiveness of testing.

Therefore it should now be apparent the benefit of having a tester present during project discovery workshops. Who can better speak for and determine testability than the tester who has spent her life in testing, day and night, thinking and doing, dreamt tests, laid awake at night thinking data combinations to provoke a defect or many, etc. As much as testing may be done by anybody, it requires great perseverance, thought, creativity and an exploratory problem-solving mindset to transform testing into an art and a craft form. Such testers provide fantastic value to a team tasked to tango together for a discovery workshop.

The Case for Testing Thought Leadership

Based on the above, a high-level strategy or a mind-map representing the thought-process of the tester in how she will test the application, types of tests, tools that will be employed, data, risks and so forth is created as one of the outcomes of the workshop.

Based on understanding through first-hand information, observation, discussions, clarifications, mental models – the strategy is expected to be well-designed and rich in content that will go a long way to begin testing on the right note. Along the way, the smart tester will likely make a point or two in letting the customer know that the application-whenever-under-test is in safe hands.  The assurance so provided to the customer is worth its weight in gold which may or may not be verbalised.

To conclude…

As much as the benefits of having the tester in discovery workshops / EmbArrk should be understood by now, let me express explicitly which puts a lid on this article as well:

• Assist in collective knowledge acquisition.
• Apply unique mindset that thinks functional, non-functional, testability, user-centric, business-centric, destructively and constructively to question, challenge and clarify the knowledge build-up
• Assist in solutioning aspects from story development to estimates to a release plan
• Ensure customer expectations of the application quality are understood so as to be taken care of through strategy formulation and testing carry-out.
• Ensure incorrect assumptions about testing are nipped in the bud
• Build rapport, provide assurance and demonstrate capability to test