hand, we implemented scalable platform to support the best practices.
Build a Mechanism for Dealing with Dynamic Requirements
Appropriate realization of requirements seems to be one of the biggest challenges of Distributed Agile development. This is also one of the biggest causes for software failing in distributed product development. Thus, product engineering teams need to adopt best practices that are capable of accommodating dynamic requirements coming from different stakeholders at any given point in time. A business requirement may be coming from a customer, product manager, developer, tester, or support team. Further, there may be different modes of communicating requirements, e.g., via instant messaging, stand-ups, market requirement document, verbal communication, e-mails, etc. One of the important roles of quality engineers at this stage is to validate business requirements and ensure that all the market requirements are well satisfied. It becomes necessary that all stakeholders collaborate to keep the requirements-related defects away. Another important aspect of requirement testing is to be able to determine missing pieces of requirements. Agile practices recommend seeking early feedback by involving customers from the beginning since they are the best judge of their business needs. Moreover, early involvement of customer also enables product teams to keep pace with continuously changing needs and wants of their customers.
All these objectives can be successfully attained by designing a requirement management system that allows dynamically storing and tracking business requirements. To help facilitate distributed environment, this system was accessible to various teams over the Web so that all stakeholders can collaborate on real-time basis. Such a dashboard promotes collaboration amongst various stakeholders and helps to track the changes and the progress. It allows a common view for all stakeholders. It also helps in building a knowledge-base of requirements over a period of time. This knowledge-base provides distributed teams an opportunity to leverage product knowledge without depending on subject matter experts.
Creating an Integrated Tracker
Ability to properly derive test cases from raw requirements is important in product testing. In traditional approaches testing is typically done with the purpose to find defects. We believe that in Agile approaches, software testing in a simplistic sense is about realization of requirements. All the tasks associated with fulfilling the delivery of the requirement needs to be finally mapped, inter-linked, and driven by its priority. These tasks can be associated with activities like writing use cases, code reviews, writing test cases, test automation, etc. This also helps in proper collaboration in scenarios of rapidly evolving requirements.
In addition to test cases and use cases, requirement mapping is also necessary for test results, defects, and code changes. When a defect is fixed, one should be able to instantaneously map this fix with associated business requirement. This mechanism also helps improving effectiveness of testing since one can easily figure-out the more stable or unstable business requirements. This information allows product teams to pay more attention to business requirements that are mission-critical and most susceptible.
Establishing traceability for business requirements, use cases, test cases, test results, and defects requires robust method and tool. This can be achieved by designing a common framework that enables integration of various repositories (e.g., business requirements, test cases, test data, automation scripts, and test results) with issue tracking system. The workflow of this framework should be designed so that it provides tracking from one artifact to other on a single click.
In order to ensure effectiveness of tracker, one should adopt suitable nomenclature and configuration for various iterations and associated artifacts. The requirement tracker should also be simple so that traceability and accountability are easy to maintain and the visibility requires no