ABSTRACT: There are many techniques which Business Analysts (BA) use from their toolkit which we, as testers, can equally make use of. This whitepaper explores some of these and looks at how you can use them.
There are a number of cross overs in the roles of the Business Analyst and the tester. Some techniques appear to be common however there are few BA tools that I believe will be useful to the tester. I have selected a few which I believe can provide benefit to the tester.
There are a number of factors that contribute to successful reviews. Reviews need not be difficult to perform, but they can go wrong in various ways if factors such as these are not considered:
- Technical factors
- Organisational factors
- People issues
These are discussed in detail in the ISTQB Advanced syllabus, however a few examples to consider are:
Technical factors (known as Process by BAs)
- Ensure the defined process for the review type is followed correctly, particularly for more formal types of review such as inspection
- Record the costs of reviews (including time spent) and benefits achieved
- Review early drafts or partial documents to identify patterns of defects before they are built into the whole document
- Ensure that the documents or partial documents are review-ready before starting a review process (i.e. apply entry criteria)
- Use organisation-specific checklists of common defects or defect taxonomies
- Use more than one type of review, depending on objectives, such as document cleanup, technical improvement, transfer of information, or progress management
- Ensure managers allow adequate time to be spent on review activities, even under deadline pressure
- Remember, time and budget spent are not in proportion to the errors found
- Ensure that the right people are involved in the different types of review
- Provide training in reviews, particularly the more formal review types
- Apply the strongest review techniques to the most important documents
- Ensure a well-balanced review team of people with different skills and backgrounds
- Educate stakeholders to expect that defects will be found and to allow time for rework and re-review
- Welcome the identification of defects in a blame-free atmosphere
- Ensure comments are constructive, helpful and objective, not subjective
If you are new to a company and are asked to write a Test Strategy then another technique that you many want to consider is MOST analysis which helps to understand the a company’s current business strategy and the inherent strengths and weaknesses of the organisation. If this organisation is a large one I would suggest that you only do this for the Business Unit that you are working with.
Swipe to see more
This should define what business the organisation undertakes and what it is intending to achieve
The target against which the organisation’s successes can be measured
The methodology that is going to be taken by the organisation to achieve its mission and objectives
The detail defining how the strategy will be implemented.
Understanding where the Business direction is headed, and how this is going to be supported and enabled by technology, will help with the writing of the Test Strategy. This technique can also be used to highlight the lack of clarity and weaknesses within the organisation which may then manifest as Risks that you need to be aware of and look to mitigate within the Strategy.
Another useful analysis tool is SWOT which pulls together results from the examination of both the external and internal environments. This tool summarises the key strengths, weakness, opportunities and threats of the organisation. It is often represented by the following matrix. Again the threats and weakness could result in risks and issues for the testing team and the earlier they are known the easier it is to manage.
This is probably the most common set of tools that are used by both testers and Business Analysts. Each has its pros and cons and sometimes it is best to do a combination of a number of these.
These techniques are:
- Quantitative approaches
These are probably being use to gather slightly different information and have different objectives however the techniques are the same. Interviews are very good at getting the high level issues from Management and drilling down to get detail from others.
Workshops have become the most popular approach nowadays to investigate issues probably as they take less time than individual interviews and they allow for the cross-checking of information and generation of ideas in groups.
Observation allows for the study of the business users in their normal office environment. There are different types such as formal observation, protocol analysis and shadowing.
Prototyping is useful where the users are not entirely clear what they want from the information system. This could be used when developing test cases.
Quantitative approaches such as questionnaires may be used for example to gain feedback from users as part of the Post Implementation Review or as part of a Test Process Improvement programme.
Stakeholders have the capacity to either seriously derail your project, if not cancel it completely or to provide support and often remove obstacles from your path. It is important, especially at the management level that you quickly identify the stakeholders and their likely influence on your project.
Here are a number of different stakeholders which may influence your project:
The power / interest of each of these stakeholders are critical when assessing their influence on your project. This can be assessed using the following table.
Once you have worked out the stakeholders power / influence and their interest in the project and plotted them on the grid this will indicate how you might handle the stakeholder.
As well as the above grid it would be helpful to discover more information that will help manage the stakeholder most effectively such as their current interest, their attitude to the project and what messages/information that we need to convey to them. As well as classifying stakeholders as above you may want to consider their attitude to the project. One classification scheme is:
- Champion – will work for the success of the project
- Supporter – in favour of the project but not active
- Neutral – neither for or against the project
- Critic – not in favour of the project but not actively opposed
- Opponent – will work to disrupt or derail the project
- Blocker – will obstruct progress
As can be seen there are lots of crossovers between the disciplines of Business Analysis and testing. As more companies move to Agile, those boundaries between roles will blur as IT professionals become multi-functional. I would encourage you to broaden your competencies and use what tools are available to you.