Testing is not an isolated activity. It interacts with and influences other disciplines in software development such as design, coding, release management, and deployment. As testers, our skills and experiences add value far beyond the immediate context of verifying functionality. Threats to value other than software errors exist.
Yet our discussions are often constrained to the testing space, omitting the connections to, and dependencies on, other roles and activities. Testing is an integral discipline of software development, and often plays an active and important role in bridging gaps between technical and business-focused roles, between leaders and engineers, and between makers and users.
How does the testing piece fit into the software development puzzle? How does – and how should – testing interact with other disciplines in software development? How can we most effectively add value to the software development projects we participate in?
Please join us for our 11th annual conference at the Simon Fraser University Harbour Centre campus in downtown Vancouver, Canada, August 8-10 2016.
IMPORTANT NOTE: Creating a profile on this site does not constitute registering to attend the conference. If you would like to attend and have not yet registered, please Learn More »
If I wake you up in the middle of the night, are you able to tell me, as a good tester, what risks are still applicable in your system under test? And what impact these risks can have when this software goes to production? Although I never had to wake my testers up, in many cases they couln't answer the question! In my opinion: covering risks is underestimated because we don't like the subject: it is too abstract, sometimes too philosophical or negative. While on the other hand if we have to deal with problems in production because we underestimated risks, fingers are pointed at those who were able to cover the risks (such as testers). Dealing with riks determines the success of a product and therefore the success of a organization. I will look how organizations should be organized to get the maximum commitment of their empoyees and if this is the case: motivated testers who feel free to communicate about risks. Nowadays I am working in an organization using the agile/scrum approach and my role changed from test manager to test facilitator. This doesn't mean that the focus on risks disappeared. On the contrary: I see a lot of risks at the integration level of systems that are not recognized and not covered because no scrum team feeds responsible. Therefor I like to discuss the following question: 'how to communicate with the focus on risks?". This should be a focus point in the communication between testers, developers, analysts and stakeholders. I will look at 2 kind of risks I see: product risks and project/process risks. After this elaboration I like to discuss how to communicate effectively as testers in a scrum team and as a test facilitator on risks without being sees as the guy who is constantly looking at the dark sight. So how can we improve communcation within and amount scrum teams and with an implementation manager responsible for a release with risks as important subject? I will use my current assignment as the experience report for the discussion.
Take aways:
Do you know the meaning of your organization, system, product?
Can you deliver the important risks right away?
How can you communicate about the (process and product) risks your dealing with?
