While testing software, we do come across with cases where some kind of input is needed. Whether this is a manual input, e.g. user name for a login screen or a machine input, e.g. screen resolution or some kind of DB input, e.g. db triggers (do this if its a sunday, send SMS if there is a credit in a account), we need to worry about a large number of inputs. When we plan test cases for these scenarios, the nightmarish task is to identify a small set of these input values, since inputting each one of them is impractical and non-feasible solution.

For example, if we have to test Login Screen, I would probably start with normal alpha names, then probably alpha-numeric name and then the ones with special characters and so on. While for a Login screen, the problem is not very complex, it does tend to get complex if we have to identify inputs for a photo-share program, specifically a photo-uploader part. In this case probably it would be

1. low res files

2. high res files

3. files of a particular format

4. invalid files

and so on. The big question is that how do we decide on that golden set of inputs which we think would sort of solve our problem. Continue reading →

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,

Continue reading →

Software Configuration Management or SCM in short is one of those terms which either you know or you dont. Most of the folks who know it would actually believe it to be a source code control system or just a set of processes and documents or worse a change control procedure. While all of this is true, I am not sure how many of us have actually tried to think about its true meaning, its need and why its called SCM.

The truth is that I never thought about SCM as well and in my all test plans, I would invariably have a section on SCM and that in turn would mean that how we would keep code, documents, how the revisions would be stored but it never bothered me to brood on why its called ‘Software Configuration Management”. So after reading about it at places like http://en.wikipedia.org/wiki/Software_configuration_management and thinking about it for a while, here’s my take on this.

Lets separate the words, so we have “Software”, then we have “Configuration” and finally “Mangement”. I thought that if I could somehow understand “Configuration” well enough and then if I could link that with first and last word, then I am done.

Continue reading →

Software testing is about executing a set of test cases which are well documented and probably anyone after a few rounds of rehearsal can do it well. While practitioners would not agree with this since in practice, you dont find all the bugs from documented test cases. At most you document the basic workflows or the core cases but its not realistic to assume that one would be able to document all the test cases. Typically you would document the ones which are most important, so the big questions is that ‘how much to document’.

I am sure all of us have been into a situation where we found a bug at some crucial time and then everyone would want to look at test cases and while the witch hunting is going on, you as a test manager wonder that we never document everything. So after testing for many years and then managing a small team and complete products, here are some tips on test-case documentation. Continue reading →