-
Share
As developers we often tend to approach requests or user stories in isolation moving straight away into development. At first glance this might seem the fastest path to delivery, but very often it’s the start of a prolonged development life cycle full of defects and fixes.
Current way of Development:
Once this user story is assigned to a developer, he will try to understand the basic need and will go ahead straight away to develop that user story commencing a cycle of execution as shown in the below diagram. He may not necessarily think of all the possible scenarios, nor does he perform an impact analysis for the story and, because of this, the user story may end up being incomplete. With unit testing and test class the developer should be able to locate some issues, but they won’t be able to spot core business scenarios that may be missing. When the user story is presented to the QA team, they will raise a considerable number of defects. The development cycle starts again, fixing the defects and resubmitting to the QA team and this cycle continues till the story is signed off by the QA team.
Consider a user story that is assigned to a developer:
“As a Support Agent, I want to modify cases in order to complete the work. Acceptance Criteria:
- Use new Status value = Completed
- Replace new Status value with new value
- Status should only be visible when I am closing the case”
The developer might think this as a straightforward story and change the pick-list value on the case status from “Closed” to “Completed”
In this example, the developer didn’t consider the impact this change would have in the formula’s validation rules, workflow, process builders, flows, triggers, controllers, batch apex and webservices etc, and by the time this omission becomes apparent either by the Quality Assurance (QA) team or a user, a lot of development time will have already gone to waste.
Problems with the current approach
- Business scenarios may be missed
- Lots of iterative time spend on development unit testing and defect fixing
- More time spent by QA and developer to close the user story
- Increased number of errors in QA or UAT testing
- Focus shifts from building features to fixing defects
- Frustration for QA and Business teams
Can we try a different approach?
If we revert the process and start the development work by first writing unit test cases, creating the test classes and test data and accordingly proceed with the development as shown in the Cycle of Execution diagram. It may seem like you are spending much time on writing test cases and classes, but this will ensure that the development of the user story is full-proof and does not miss any points.
Advantages of test-driven development
A Test Driven Development Approach solves all the problems we discussed at the beginning of this blog:
- The developer has full understanding of the requirements and the business scenarios before the start of the development work
- There are significantly less defects to work on as the development cycle progresses
- With less time required in fixing defects, the developer can invest more time on development and unit testing
- The cycles for development, unit testing and defect fixing are considerably reduced
- The quality of the delivered features is improved
- QA and Business teams are happy!
If you would like to find out more about how Coforge can help you leverage Salesforce to accelerate business outcomes, give us a call or email us at Salesforce@coforge.com
Other useful links:
How to migrate legacy data to Salesforce CPQ
Guide: Performing a Successful Technical Debt Assessment in Salesforce