Tech Notes

In any agile program, it is important to track both business and development progress metrics. Agile metrics helps a team to better understand their development process and also releasing quality software easier and faster. There is a big debate on the usage of some metrics and there are concerns of using it in teams. Usually, usage of metrics is guided by three rules - When a measure becomes a target, it ceases to be a good measure ( Goodhart's Law ) Measures tend to be corrupted/gamed when used for target setting ( Campbell's Law ) Monitoring a metric may subtly influence people to maximize that measure ( The Observer Effect ) Below are some popular key agile metrics at the sprint level as the sprint progresses. Pre Sprint Execution Business Value A value given to user story by

Sprint becomes a mini-waterfall and testers are involved late in the sprint Lack of focused testing as for many other things testers time is required like prepare stories for future sprints, keep an eye on broken build on CI, work with product owner for demo, help developers with test data, environment setup etc. Complexity of test environment especially when quick fix need to be tested before deploying to the production Need to learn on continuous basis especially new tools & technologies Due to frequent requirement changes, ensuring full test coverage is not straight forward Support of testing for daily or semi builds Lack of documentation Code accidently broken due to frequent builds, which results loss in testing time Support testing for the last minute changes especially with the deadline approaching Test team gets squeezed due to over commitment and sprint durations

Integration of Testing Process in Sprint 1. Understanding the stories context from testability perspective Phase: Sprint Planning Stories should be understood from end users perspective It should be clear for testers, what are the changes and the reasons behind those changes Missing test requirements (e.g. login / password, contest id, test environment accessibility, access to new features etc.) What should be done to overcome the requirements? Track missing requirements and make it available as soon as possible Features or requirements or part of requirements is not testable (e.g. not permissible to login to Salesforce etc.) 2. Create a running document, containing clarifications and its resolution Phase: Sprint Planning A document that contain history of all questions or concerns being raised A reference document for tester, when in doubt Document for product owner to know how well equipped his / her testers are 3. Add notes to testers, testing ideas or

User Story One template that can be used while writing user stories could be – “As a (role) I want (functionality) so that (benefit).” For example – As a ‘Bank Customer’, wants to ‘Transfer Funds’ to one of their friends / acquaintances online, which is fast and auditable. Or, the user story could be described as a single line item (2-5 words) as well. For example – Fund Transfer Test Cases Few of the test cases (summary) for above user story could be as follows.  These test cases should be developed with the help of Business analyst. Transfer fund when fund is in range of acceptable limit and existing balance is sufficient. Or, Fund transfer amount less than existing balance Transfer fund when fund is in range of acceptable limit but existing balance is not sufficient. Or, Fund transfer amount more than existing balance Transfer fund when fund amount is beyond acceptable limit. Or, Fund transfer amount more than

Build Tools Build automation involves scripting or automating the process of compiling computer source code into binary code.   These tools are particularly useful for continuous integration (CI) builds where frequent calls to the compile process are required and incremental build processing is needed. Core activities involved in build automation: Compiling source code into binary code Packaging of binary code Running of tests Deployment of binary code to test environments / production environment Creation of documents or release notes Advantages: Accelerate compile and link processing Eliminate redundant tasks Have history of build and releases in order to investigate issues Features of build tools that need to be considered before picking it: Frequent / Scheduled Builds Support for Source Code Management system Incremental Build Processing Reporting on build’s status Generation of release notes and other documentations Some Popular Ope

CI is one of the modern software development practices for applying quality controls in small pieces.  CI involves automatically building and testing an application at frequent intervals on a dedicated integration server.  Developers regularly commit small updates and are notified rapidly if their changes cause the build to fail. Core activities involved in CI: Maintaining a code repository Committing the code to the baseline everyday Automating the build process Deploying the build to test environment Making the build self-testing Reporting the build status to the team Advantages: Reduces the risk of integration issues appearing late in the project Improve communication between team members Reduce the time needed to prepare a release Most fundamental feature of CI tool is the automatic build cycle.  The CI tool, either at a scheduled time or whenever any changes are detected in the source code repository, fetches the source code latest version