[Improvement in progress - 21/05/14]
Lessons learnt from BCS Requirements engineering course:
Business , Project and External stakeholders, all have knowledge/information about System/Applications. This knowledge can be very valuable and aids in requirements,development & testing.
Having attended the course it highlighted that: Business Analyst gather information about problems to document them, Testers gather information about problems to exploit them. The challenge we all face is understanding the system, the stakeholders and their requirements.
"There are things we know we know. Things we do not know and Things we don't know we know." Donald Rumsfeld
The knowledge from Stakeholders falls into two groups - Individual and Corporate and are grouped under Tacit and Explicit.
Explicit knowledge covers that which is documented in some shape or form.
Tacit knowledge includes Skills, values, culture, organisation history and so on, which are usually overlooked. Tacit information is that which has not been documented or formalised in any way but is current information which still apply s. This knowledge is also just as important to the test team.
Business Analyst using Elicitation techniques to drive out both Tacit and Explicit information. This includes Interviews, Workshops, Observations, Focus groups, Scenarios, Document Analysis.
These are techniques/tools applied in requirements gathering which can be used during test design to generate test ideas.
The Key with using these is to identify who is best to apply which technique to, with a goal of getting the right information.
Workshops with subject matter experts can be very effective in identifying possible problematic areas and tests that can target these areas.
Observations can be used with users to build knowledge and identify tests which users might take for granted. eg a shortcut used in an old system might cause issues with a newly implemented system. Users attitudes can also be examined to assist testers in designing tests. This can be achieve by watching staff using the systems, wandering about the work place or shadowing individuals of teams.
Document analysis which testers usually do is the reading and analysis of source documentation, such as functional specifications, requirements documents, user guides, forms etc to identify test conditions. This involves breaking down testable statements in documents and questions and writing tests against them.
Scenarios can be very effective in breaking down tests into activities rather than individual tasks. Some situations require this due to their complexity and where actions have several dependencies.
Quick summary: Elicitation techniques are used by testers, it is a skill worth expanding to aid in becoming better testers. The better our ability to extract information the more test ideas we could come up with.
NB: Please note this is yet to be reviewed!