Can a Software Tester become a Business Analyst?
Can Business Analyst take up the role of a Software Testing professional?
Do roles like a BA Tester or a Tester BA exist? How to switch you role from Software Testing professional to a Business Analyst, and vice versa?
This case study is an attempt to answer these questions!
In this case-study, myself and my friend (tester!) Anamitra Majumdar tried to explore what if the same person performs the role of a Business Analyst and a Tester?
We first try to understand the roles of a Business Analyst and that of a Tester.
We then tried to explore both the options – an individual changing role from Business Analyst to a Tester, and on the other hand another case where a Tester changes his role to become a Business Analyst.
Note: You are free to use this case-study or snippets from this case-study as a reference in your work as long as you give due credit to QuickSoftwareTesting.com.
So, let’s get started!
Case Study: Can Software Tester Become a Business Analyst?
Rapidly changing market conditions are requiring companies to shorten delivery cycles and become more responsive to customer expectations.
Read: How the world tests? – Latest trends in software testing
Agile development methodologies are leading the way in helping software development teams adjust to the new economy.
Agile challenges our notion of software engineering best practices, project management methodology and how we lead our teams.
In a project based on Agile Development methodologies, a BA and a Tester have some pre-defined roles to do wherein the BA’s involvement is more towards start of the cycle and testers are involved towards the end.
The agile movement impacts every role on the project team differently and creates opportunities to learn new skills and develop new ways of working together.
Exchanging the roles in an innovative way could unleash the hidden capabilities of each of them to help the project overall.
Introduction:
Agile development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.
It is a conceptual framework that promotes foreseen interactions throughout the development cycle.
Agile introduces a significant shift in how teams look at requirements and when they are defined in the process.
In an Agile methodology, Business Analyst is more involved during the initial stages of SDLC while a tester’s involvement increases during the final stages of SDLC.
A tester is involved from the start of Sprint planning sessions till the delivery into production but a BA might start working on other projects as soon as requirements are frozen and tester/developer’s queries are answered.
In this white-paper, we are trying to present the feasibility of a single person playing the role of a Software Tester and a Business Analyst.
Role of a Business Analyst (BA)
In an Agile Development project, the role of a Business Analyst is broadly divided into:
Writing User Stories – The Business Analyst is supposed to define and write detailed Requirements after understanding the expectations from Business Stakeholders.
Feedback from Users – The BA produces and explores requirements in collaboration with the end users which can include Testers and Developers as well.
Acceptance Criteria – Defining Acceptance criteria after discussing with Testing Team and Business teams is also a BA’s responsibility.
Planning Sessions – During Sprint Planning Sessions, the BA explains requirements to the team and expresses the expectations of the Product Owner to the team
Clarifications & Query Resolutions – Starting right from the Sprint Planning sessions, the BA clarifies any development and testing queries related to the requirements.
Show and Tell Session – The BA also attends the Show and Tell sessions to make sure the requirements are developed in line with what the BA had envisaged at the start of the Sprint.
Role of a Tester
The tester is normally involved in an agile world from the Sprint planning sessions till the delivery into production. Below are the major roles of Tester in Agile Development model.
Sprint Planning Sessions – The tester understands the User Story requirements from the BA in the sprint planning sessions and discusses on a high level, the feasibility of the User Stories to be tested.
The testers also give a high-level test estimation of each User Story based on an initial understanding.
Acceptance Criteria – The testers are also involved in reviewing the Acceptance criteria as defined by the BA and POs. The testers can also suggest amendments to the acceptance criteria after discussing with BA/PO.
Test Estimations – Based on the understanding of the User Stories, detailed test estimation is done using standard test estimation techniques.
Test Planning / Strategy – During planning phase, the tester prepares a detailed test planning document which underlines the testing approach for testing the User Stories during the project.
Test/Scenario Design – Once the estimations and planning for the Agile Project is done, the testing team writes Test Scenarios followed by detailedTest Cases.
Once completed, the Test Cases undergo a peer review among the test team followed by business sign-off after which Test execution is done using these test scripts.
Check out: 13 excellent tips for effective test case writing which is all you need during test case design activity.
Test Execution & Defect Tracking – The Test Execution cycle is started on the signed-off Test Cases and Defects are logged for any behaviour not ‘as expected.’ The tester also needs to report the progress on a daily/weekly basis.
Recommended Reading
Show and Tell Sessions – The tester chairs the ‘Show and Tell’ sessions to show to the business (including the BA) about what is developed and tested so far. During the session, the tester makes a note of any review comments provided.
Retrospective Meetings – Once the Sprint is over, the tester attends Sprint Retrospective / Review Meetings to make a note of ‘What went well?’, ‘What could be improved?’ and ‘What needs to continue?’ so that the same mistakes are not repeated in the future sprints.
Tester as a Business Analyst
As you can infer from above, the BA is more involved during the initial stages of SDLC while a tester’s involvement is more during the final stages of SDLC.
Imagine a case where we have a Software Tester with enough understanding of the systems and, who is given the challenge to play the role of a BA!
That could be exciting!
Tester Business Analyst in Agile (Click Image to Enlarge)
Below are some of the benefits which could be achieved:
Early involvement in SDLC – In this hybrid model, where the same person is playing a dual role, the tester is now involved much earlier in the SDLC cycle – right from the requirements shaping.
This proves really beneficial in delivering the project with optimum quality as the tester now knows of any new changes coming up his way down the line. This helps to plan testing much effectively.
Well-defined Requirements – With the tester having in-depth knowledge of the system from a technical point of view, the requirements written by the tester (in the role of a BA) will be pretty straight forward and understandable.
Push Back Requirements & Feasibility Study – Having an in-depth knowledge of the system from a technical point of view, the tester (playing a BA) can easily reject requirements with valid justifications.
This is really helpful as he/she gets to know the feasibility of implementing the given requirement upfront.
Any infeasible requirement can be rejected at the very start during the shaping phase itself – this saves a lot of time and effort which otherwise would have been lost later during the design/execution phase.
Reduced testing times – In a normal Agile model, if a tester has any query, it goes to the BA who in turn has to go to the Product Owner or business stakeholder in case he is not able to answer.
Now, because Tester is the BA, the turn-around time would be much less as we are cutting down on one level of clarifications as tester (playing as a BA) can now directly approach the business stakeholders or Product Owners.
Defects Prioritization – As a tester is now more involved with the business (being a BA), tester has better understanding of the impacts to the business due to defects/change to an existing functionality.
Reusability – As Tester is now a BA as well, the visibility of re-using the existing resources is much easier from both technical and business point of view, which, in the end benefits the team effort and cost.
Business Analyst as a Tester
Now, let’s think the other way around!
We have a BA who has been on a team for years now and has in-depth knowledge of the end-to-end systems.
His boss calls him to his cabin and gives him a surprise, offering the dual role of a BA and a Tester.
We still have a lot of benefits that this package comes with!
Requirements Traceability: As the BA has written the requirements on his own and is also testing them, he/she gets the privilege to trace the requirements from start till the requirements get delivered to production.
Impact Assessment: Having a better understanding of the requirements from the business point of view, the BA (now playing a tester!), can easily access the cross-impact of any new requirement or change on the existing system. This helps in improving the overall quality of the system.
No Dependency on Testers: As BA is now playing the role of a tester, he doesn’t have to depend on testing teams’ inputs to get any functional queries clarified and to run through any user journey.
Involvement in SDLC and Accountability: In this dual-role model, the BA (playing the role of a tester) now has a major role to play throughout the SDLC.
Also, this model makes the BA much more accountable towards the delivery of the product which otherwise is solely considered the testers responsibility (well, in most cases!).
Quick turnaround on Change Requests – Imagine a scenario where a Change Request comes in during the execution cycle and business needs a quick turnaround.
In this case, the BA (playing the tester in the execution cycle) can easily monitor the impacts of it and help in the approval/rejection of the CR
Overall Advantages
Here I have summarized some overall advantages of exchanging, or rather merging roles of Tester and Business Analyst.
- Cost saving as the same person plays 2 roles.
- During the start of SDLC, Tester is not fully occupied, and towards the end BA doesn’t have too much to deliver – combining the 2 roles helps in better resource utilization hence, saving costs.
- Cuts down testing cycle time.
- Quick turnaround from business / stakeholders which otherwise happens from tester to BA to Business.
- Requirements are well-defined for a clear understanding for the testing phase.
- BA writes requirements on his own interpretation of what is required. If Testers are positioned far away from the original BA, then they test the system on their interpretation of the interpretation of the BA. This risk is reduced by making Tester the BA and BA the tester.
- For any Change Request time is saved in updating user stories/test cases.
Disadvantages
This exchanges of roles between business analyst and tester has some disadvantages too!
- As the same person is playing 2 roles there will be more effort for an individual.
- As the tester has written the requirements, he/she would hesitate to log defects due to missed requirements (happens!).
- If 2 sprints overlap it will impact this dual role as now tester testing in one sprint will not be able to write requirements for the next sprint and vice versa.
- An individual playing a Tester BA role should have adequate skills to fit in both the roles seamlessly.
Conclusion
Having the BA doing testing, you remove one level of the indirection and at least get something close to what the BA had envisaged.
Because the BA was the person who dealt with the source of the requirements, it is the best you can get. Of course, intensive testing involvement by the key business users will give even a better result.
However, you should never only rely on them because there the risk is too high they only do it superficially and won’t go through all the scenarios you will encounter during normal business use.
Specialist testers in combination with the original Business Analyst(s)and end users will give the best results. However, I am open to alternate options if you can think of any which you can feel free to voice in the comments section below.
And yes, testers should be involved in early stages of the requirements and design!
No comments:
Post a Comment