Meet our Consultants – Shruthi Srinivasan (Agile Test Analyst)

Listen to this article:

What do you do in your role?

I’m an Agile Test Analyst and I work on the Agile delivery model. I’m a vital and responsible member of an Agile development team, with a broader role than just testing and finding bugs. I’m involved throughout the development lifecycle to ensure the quality of the software and I work closely with Developers, BAs, Product Owners and other team members to understand the business benefit of the system as well as the detailed requirements/functionality. It’s so fascinating to be an Agile test analyst as I get involved in all of the Agile ceremonies like backlog grooming, sprint planning, daily scrum meetings, sprint reviews and sprint retrospectives.

What difference does your role make?

I test the quality of the software to ensure it not only meets but exceeds customer expectations. No project is a cakewalk. Since I believe in providing solutions rather than getting blocked by problems, I intend to initiate and be part of constructive conversations that are solution-oriented, rather than talking about the blockers.

Speaking of testing processes and deliverables, I always keep our test approach flexible and adjust it on a need basis, because being Agile means being adaptable and embracing change. Also our team dedicates ourselves to continuous learning as the tech landscape is constantly evolving. This involves staying updated on new testing tools, methodologies, and best practices. T-shaped skills I have acquired over a period of time not only helped me to see myself as a quality advocate who plays a crucial role in ensuring a high-quality software product is delivered, but it also comes handy for the clients and adapts their scope as and when needed.

Although Agile reduces the amount of documentation, I track and report testing metrics throughout the project. The data I record helps the team understand the progress, be aware of the historical mistakes made, and helps the stakeholders make informed decisions.

In addition, I help stakeholders understand their products better and build in quality earlier in the product lifecycle by providing tailored and relevant feedback throughout. I take a context-driven approach to each functional testing project, ensuring the best-fit functional testing tools, practices, and techniques are employed.

Testing is not a one-and-done kind of job. It keeps evolving and as a test analyst, it’s my responsibility to create and maintain the artefacts that are timeless and are easily comprehensible. At Ten10, we have a dedicated hub for testing artefacts called Tenology®, where we maintain a record of testing best practices followed, guides and collateral for consistently delivering successful services, ensuring that how we deliver is robust, repeatable and reliable. The templates and accelerators that our team produces helps us to provide high-quality services, leveraging the best assets produced by our consultants. Using these, and tailoring them based on the client’s needs, accelerates delivery and prevents a need for re-invention of the wheel.

What are your top five tasks/deliverables/responsibilities that make a difference to successful programmes?

Backlog grooming

Backlog grooming is an Agile ceremony I absolutely enjoy participating in because it is during this ceremony that we, as an Agile team, discuss the features of a product, its dependencies on different development and test teams, and the expected outcome. During backlog grooming, I collaborate with PO and the team to derive the acceptance criteria, definition of ‘ready’, and definition of ‘done’ of a user story. Generally, a tester’s role could be limited to assuring the quality of the product. But I always do more than what’s in the contract. I suggest potential inputs and changes that can be made to the product or the process, by leveraging all of my experience at Ten10.

I also come up with clarifications on dependencies and workflows that I might encounter during the test phase so that we are not stuck when we actually have to test the story. It gives a sense of ownership and responsibility to be a part of this meeting representing the quality aspect of a product. It is also in this meeting that I acquire and share my knowledge about different methods to approach a technical problem and provide solutions that can be of utmost benefit to the client.

Sprint planning

Sprint planning is crucial to ensure the team delivers a high-quality product within a committed time frame. During planning sessions, I explain the complexity of the story from a testing perspective and have a healthy conversation with the developers of my team to agree to a common story point estimate. I also raise concerns when I feel a story needs additional testing efforts or has a higher probability of defects so that we arrive at a realistic estimate. During this process, I feel that it is important that I say what we can and cannot do and don’t overpromise.

I make sure that my test scripts are developed and identify potential candidates for in-sprint automation. This approach is generally appreciated by the clients, because we finish when the work is done and try to accommodate stories from the next sprint and adjust the bandwidth accordingly, instead of over-committing and spilling over.

Daily scrum meetings

Generally, daily scrum meetings involve discussion of what we worked on the previous day, what we plan to do today, and if there are any impediments or issues we have encountered. In reality, it is more than just that. Besides status updates, I address queries that are raised by the developers during the stand-up calls. I also help them with the unit testing. I raise concerns related to environmental issues that the team is facing, unresolved defects that have not met the SLAs etc. I also make sure that the stakeholders are kept informed about the quality of the product on a daily basis. There may be cases when we have to revisit the priorities of the stories in the middle of a sprint and as a test analyst it’s my responsibility to raise that flag as and when needed.

Sprint review

Every Agile team has a sprint review in one form or the other. Demos are one of the effective methods of a Sprint review. My favourite agile ceremony is the sprint review because this is when I get to showcase the work we have completed to the Product Owner and, sometimes, to end users. More often than not, it’s the test team who shows the demo of the stories that are delivered in the sprint. I actively participate to show that the implemented functionality meets the specified requirements and performs as expected. As an Agile test analyst, I provide feedback on whether the product fulfils the acceptance criteria outlined in the story. I also involve the product owners on UAT to make sure usability, functionality and user experience is as expected.

Sprint retrospective

A sprint retrospective is held for every sprint to reflect on the work done to discuss what went well, what could have been better and areas for improvement. I am trained to communicate effectively and transparently to make sure my agile team enhances overall efficiency of the team and the project. I also propose suggestions for improving testing workflows, tools, techniques and methodologies, and make sure the best practices are in place. I also take retrospectives as an opportunity to discuss the test coverage achieved during the sprint, including the adequacy of test cases and the thoroughness of testing efforts to identify gaps in test coverage and propose strategies for addressing them in future sprints.

Within the test team, we discuss the root causes of defects and we try to identify key defect areas. We highlight the same in the retrospective meeting to our developers to pay more attention to those areas, by suggesting exploratory testing, risk-based testing, where we focus on defect-prone features, peer review of code, test suite and requirements to prevent defects from occurring and to proactively detect defects and fix them.

I attend the defect triage meeting being one of the three AMIGOS (developers, testers and business analysts), where I confirm the defect’s existence by replicating the issue and documenting it, assess the impact of the defect on other functionalities, providing inputs on priority and severity of the defect and proposing my plan for regression test post-defect fix. I also make it a practice to ask feedback from production to check if there are any changes needed to the test approach or coverage and act accordingly.

In essence, my role as an Agile Test Analyst is about safeguarding the quality of the software, by using all of my experience and knowledge acquired, ultimately leading to a better product and a more satisfied customer base.