Few days back, I tried to explain in my last post about SCM. If you are not a regular reader here, then I would encourage you to read that and then come back to this one. Click here to read about whats SCM.
Having understood SCM, the other key question for test practioners would be to dive into its relevance vis-a-vis software testing. Going back to basics, SCM is management of a configuration of various modules (which as a whole is user-facing software). For Software testing connection, lets try to figure out the ‘configurations’ and ‘modules’ which are related to software testing.
‘Test Plan’ is a good module to start with. A test plan is virtually like the bible or the constitution, its a set of rules, methods, priorities which help you to make day-to-day decisions. Well thats sounds very theorish. But it is. It may happen that you dont really go back to that document to confirm your action but its that way. To give you an example, a ‘Test Plan’ mentions that if you find a defect in a third-party component then you would follow a process and you follow it all the while. Or for that matter, a ‘Test Plan’ mentions the tools which you are going to utilize or whether you would have a ‘Bug Hunt’ for all major features or not. It also mentions some more key decisions like “what all you wont be testing”, whats your assumptions,
which OS you would be covering and which Browser you wont be covering. While lot of us might think that ‘Test Plan’ document is more of a formality, the truth is that while you are writing, all these things get ingrained and sort of drive you when you need to make a call. And no ‘Test Plan’ is set in stone, it evolves as you go down the path and its a ‘Live’ document.
So for the benefit of time, lets assume that ‘Test Plan’ is indeed a module. Its more of a core kind of module which doesn’t change too much near the end. Something like a core library or a UI-Building framework (say MFC) but its indeed a module and it does change.
Lets take another example, a ‘Test Cases’ document. This is much more lively and probably you would agree thats its another module. Then comes test data, test input table, test scripts, test results inventory and so on. All of these are one kind of modules.
The other big thing is ‘Bug Management’.Usually there are evolved systems to track bugs, just like a ‘Source Code Control System’ and whether an organization has a ‘Test Case Management’ system or not, they would definitely have some ‘Bug Tracking’ system.
The other things which comes to my mind is Test Lab inventory, test runs/cycles management, result reporting, automation related stuff.
All of these modules change, evolve and are configured so as to help us move with Software Testing and management of all this would be called ‘SCM’ in context to software testing. Management of this would entail things like, format, template, how to save results, version control of these docs, review mechanisms of changes, who would do what and so on.
I have sort of gone very generic but there would be cases where testing is much more integrated (design verification, something which might be happening at Texas Instruments, or testing against new things like a new OS which would result in adding some new piece of code) or has a greater impact on overall SCM.
So go ahead and read it again and ask questions. This is all my personal cooked up theories which I have learnt ( or I think I have) over time.