One of the benefits of being a member of Association for Computing Machinery (ACM) is a variety of professional development resources online. I have taken advantage of the online book programs but not the online training. While starting a new job, I decided to refresh my perl knowledge by taking the online course “Fundamentals of Perl Programming” which is offered by SkillSoft.
As a refresher course, it was adequate. I learned perl years ago. My new company uses perl extensively, so I thought a refresher would be useful. The course pointed out some areas in which I am weak. However, the course did not provide enough depth (nor pointers to additional resources) to improve my skills in those areas.
If I were new to perl, I doubt the usefulness of the course. The course is structured such that snippets of perl syntax and converntions are presented. But there is very little overview and structure to provide guidance and tie it all together. If I did not know perl beforehand, I would not be able to write a perl program after completing the course.
There is a follow up perl course in the catalog. I am goint to take it and see if it exhibits the same issues as this first course.
This week I received an email from a graduate student in Sweden. He was asking about the abstraction level of test cases. My response to the email is below:
A couple of comments on the decomposition of test cases. When I submitted the paper, the conference committee was very divided on the paper. Half of the reviewing committee was saying that the topic was obvious and not worth including in the conference program. The other half of the reviewers commented that this was a worthwhile topic because there was (and still is) very little written on the topic. When I first started out in the software testing field, this is what I discovered — there was much written on test case design but very little on how to organize the test cases.
The situation today is different but still there is very little written on organizing test cases. Some of the best work I think that has been done organizing testing is the work by James and Jon Bach on exploratory testing / session based testing. Jon has a Google TechTalk video. There is a Wikipedia article on session based testing that might give you some pointers to more information.
In general, the move towards agile and test-driven development has led to less documentation. However, in a lot of cases, I think this has led to less planning of testing. (Perhaps with better quality planning on some development projects.) Test driven development has focused more on organizing test cases around the structure of the source code — which evades the question of the best way to decompose the testing.
With respect to your second question about executing “sub test cases” and the percent that they cover the “parent test case”, I have not given much thought to this topic. I generally look at eliminating redundancy – so if I can eliminate any test case I generally will do so. However, the question I think you are asking points to the larger question of how deeply do you test a particular feature before moving on to some other portion of the project. For example, say the “parent test case” is test feature A – how thoroughly do you test feature A before you say you are done. Obviously, it depends on the importance of the feature, the risk involved if the feature, etc.
I am not sure if this is helpful. Best of luck on your thesis and continued studies.