Dev Task Estimations, Test Task Estimates

Estimations

I am still learning to provide accurate estimates @ work. Providing estimates can be more accurate when you are familiar with the application, architecture and technology. Given the focus is on SCRUM, Frequent deployments. Arriving at accurate estimate is an ongoing learning.

Being a Developer  - Learning's

• Provide X hours as Estimates thinking about coding, design documents and testing efforts
• Provided Y task time for unit testing efforts, Design Review documents would be less compared to Bug Fixes in Unit test cycle. Finally  you would have spent more than estimated time
• In the eleventh hour before release a critical scenario fails, resulting in late night work on the day before/of release, It is tough to test everything when you develop it :). Your perception is always based on how you have coded it.
• You provide an estimate based on particular approach, when the design you may identify a technical limitation/ blocker in coding/design phase
• There are cases where initial estimate is - 20% more than actually arrived effort. When you find solutions quickly, you end up having a comfortable release schedule
• Estimation accuracy depends on technology, application familiarity, and change complexity
• Practice-Practice-Nail down at every sub-task and have clarity @ granular level
• Doing testing in Dev Environment also will help in identifying bugs @ early stage, This can be no-subsitute to QA effort instead add-on effort.

Being a Tester - Learning's

• Any amount of testing is not sufficient; always there is a little suspicion. Did I check this feature
• Identifying all bugs in first round of testing is important
• If testing stops after finding few bugs then we may not identify all the bugs. Testing should not stop based on bugs identified
• Bug fix cycles and bugs introduced by bug fixes are critical to determine code quality
• Logging Actual Hours – Often you spend more time than estimated time, This has been the case for me
• A proper planning – estimated rough plan would be good to track. I have seen actual planning adding 20-30% more time but without a detailed plan it would be tough to prioritize and execute tasks
• Never commit to a timeline and work backwards, Plan for every task before you commit for schedule

Ex-

• 2-2.30 –Verify X feature
• 2.30-3 – Execute Test cases 1-5
• 3-3.30- Attend Bug Triage

Things when organized appear more simplified than ad-hoc work schedule

Approaching Test Estimation Challenges

• Understanding the Application
•  Integration Layer - Third party or External Apps that communicate with this App
•  Security Layer - Security Mechanism implemented in the App
•  Criticality of the Application - Business Impact when this App is down. Time Vs Impact
• Communication with Business, Developing Effective Acceptance Cases. Think from a Customer Perspective
• Knowledge of Domain & Technology - Previous Experience on projects worked
• Interaction with Expert Testers - Domain QA Experts, Involve-Interact and get their feedback on Scenarios, Test Plans
• Be inquistive, think of areas where it can fail, Review meeting to get feedback from all Project members
• Learn from past mistakes and try not to repeat them

More Reads

Thoughts on Testing - Breaking Down the Test Plan
How Can I Estimate My Testing?

Happy Reading!!