When I joined the test org at Microsoft what struck me was that planning test activities is particularly difficult (specially for products of the order of complexity of windows!). And there is surprisingly little academic literature on the subject. I mean all you find is "Don't forget to test your product!"
What's so difficult about it? Well, Let me try to convince you –
I start with trying to list down all the things an SDET is expected to do -
1. Test Automation -
        1.Maintenance of existing test automation.
        2.Writing new test cases/automation
2. Test Passes -
         1.Test passes execution.
         2.Test passes analysis.
3. Smoke testing a fix -
       1.Running Regression tests for a fix.
       2.Analyzing and verifying the actual scenario.
4. Investigation of Real time issues reported by an external team (trying to repro, communicating etc.)
5. Ad-hoc testing (playing with the system)
6. Closing bugs after verification
7. Infrastructure maintenance  -
      Lab management (setting up a machine with a proper safe os, troubleshooting any network problems etc.) (There could be lab engineers hired for this.)
8. Misc. activities which come by like transition to serviceability team, helping out tap customers etc.
 
Plus, a good SDET should also –
9. Be involved and contribute to design and all.
10. Participate in customer interaction and keep regularly replying on the forums,blogging etc.
 
If you want a nice hike you would want to -
11. take up a stretch goal as well (Go beyond the commitments)
12. And yes keep learning, enhancing your technical and other skills.
 
Throw in the fact that there would be meetings, cross group collaboration/communication etc.
 
So now we have a pretty long list! Testing as such is already an intractable problem.
But we can’t really give up, so we try to plan.

The most important idea around planning is measurement. If you can’t measure, any estimates you arrive at can only be hunches. And how would you measure progress?
 
Taking measurability as a criteria (and taking only the first 8 activities), we can divide the activities in three categories –
1. Ones which can be measured at as granular level as we wish - Ony 1.2 comes in this category.
2. Ones which can be measured using statistical tools like mean and median. You can estimate how much time does it take on an average – 2, 3, 1.1 fall under this.
3. Ones which offer us only one clue towards estimating them – History. Past patterns can be used to ascertain how much time will be spent on these in each product cycle – All the rest fall under this.
 
It seems regular project planning might help us in planning 1.2 only!
Well, this is not the first time man has encountered complexity! One of the approaches we have used to study complex systems is using Probability and statistics. If I can’t prove something analytically, I’ll try to conduct a survey to get historical data to prove my point! The thermodynamics guys used probability theory and invented statistical thermodynamics!
It looks like we need something like statistical software engineering.
 
In case you are wondering, Ludwig Boltzmann is the father of statistical thermodynamics.
 
That said it is this complexity that adds to the challenge of the SDET role and its fun too!
 
More later...