What are function points ?
-----------------------------
Function points are a unit measure for software much like an hour is to measuring time, miles are to measuring distance or Celsius is to measuring temperature. It is a measure of software size. A product of five defined data components (inputs, outputs, inquiries, files, external interfaces) and 14 weighted environment characteristics (data comm, performance, reusability, etc.). Examples are
A 1,000 line Cobol program would typically have about 10 function points
A 1,000-line C program would have about eight.
Many attempts have been made to establish a relationship between function points and the effort associated with software development. Much of the difficulty in establishing this relationship is due to the fact that only the relationship between function points and the entire software lifecycle is examined. This blog examines the relationship between function points and testing -- in particular the relationship between test cases and function points.
The relationship between function points and the number of test cases is very strong. Capers Jones estimates that the number of total number of test cases will approximately equal the number of Function Points raised to the 1.2 power (FP 1.2). Data gathering and laboratory research indicates that Function Points times 1.2 estimates the number of acceptance test cases. Again the difference between the two is that FP raised to the 1.2 power estimates all test cases and FP times 1.2 estimates only acceptance test cases. That is, test cases grow at a faster rate than function points. This is intuitive because as an application grows the number of interrelationships within the applications becomes more complex. The test cases Capers estimates includes all test cases not just acceptance test cases.
For example, if a development application has 1,000 function points there should be approximately 4,000 total test cases and 1,200 acceptance test cases. Obviously, the development team should begin creating test cases as soon as possible. If the development team waits until coding has been completed, they will more than likely create far fewer than 4,000 test cases or 1,200 acceptance test cases.
-- Sanat Sharma
Thursday, December 21, 2006
Friday, December 15, 2006
International Testing Conference, (8, 9 Dec 06), Hyderabad
I attended the "International Testing Conference" that was on 8th and 9th of December 2006 in Taj Krishna Hotel, Hyderabad. It was really good. Around 25 speakers from different companies (like IBM, Microsoft, Infosys, Wipro, AppLabs) presented different techniques of testing that they are using in their current projects. Some are quite interesting but some are too boring. Well I was quite shocked that how these boring guys are applying their boring thoughts in their respective testing projects.
On one side, each and every speaker talked about the different testing methodologies. Those were useful but only for freshers in Testing area. But on the other side, one person that really impressed me was Michael Bolton. He is really a great testing guy. He simply talks about the current scenarios that is happening with the testing team in every company and how the testing team should work under this environment. I am going to point out some points that I remembered from his presentations.
** -- ** About Automation : Automation should be ROBUST and DYNAMIC. Robust means your automation tool should be designed in such a way that it should test the application in a appropriate way. Dynamic means your automation tool can survive with the application after making some good amount of changes in it. It should be dynamic in terms of editing. Management should take care before going for automation that Automation needs some bandwidth in initial stage.
** -- ** Automation Testers vs. Business testers : There is a big difference between Automation testers and Business Testers. Automation testers are those testers who tests the application according to the test cases that they have created. Those test cases were created keeping only the technical aspects of the application. On the other hand, Business testers are those testes who have business view for that application. These kind of testers tests the application keeping only the business prospective in their mind. Normally Business testers are the higher management person of a company and Automation testers are the proper testing team.
** -- ** "I solve the testing problems that other people can't solve" : This should be true for each Testing Lead/Manager so that they can resolve the testing problems.
** -- ** "THE ONLY THING ONE POWERFUL THAN A GREAT IDEA, IS A GREAT IDEA POWERFULLY EXECUTED".
** -- ** Testing department view : Well, this is a most common view among almost all the testing departments. They viewed the quality of the product as the absence of bugs. But this is not true.
** -- ** Testers were not the QUALITY GATEKEEPERS.
** -- ** About Bug : A bug is anything that threatens the value of the project/product.
** -- ** "TESTING IS QUESTIONING A PRODUCT IN ORDER TO EVALUATE IT".
** -- ** Crime of Testing : It is like a Bank robbery. If you robbed a Bank and police catches you, you will be in jail. And if you are planning to rob a Bank and police catches you, you will be in Jail. So be prepared for performing the Crime of Testing.
** -- ** Asking the Right questions vs. getting the right answers : Now this comparison is very important for testing team. Just think about this.
** -- ** Remember "THE TEST IS WHAT YOU THINK AND DO".
** -- ** Documentation : Your manager says "That should be documented". This can be in terms of test cases, test plans, reports etc. But this really means "That should be documented if and when how it serves our purpose. Who will read it? Will they understand it?".
** -- ** Test cases are not the briefcases. Measuring the quality of a product/project in terms of number of test cases that have been executed is not a right procedure to measure the quality of it.
** -- ** Its up to testing team that whether they want to be steered or wants to work as a puppet.
** -- ** Now the most important question : When one should say that the testing is done?
1. When you have no more questions about the product.
2. When your management believes that the product can be shipped.
3. You addressed all important risks.
4. And most important : When your customer is satisfied.
That's all.
-- Sanat Sharma
On one side, each and every speaker talked about the different testing methodologies. Those were useful but only for freshers in Testing area. But on the other side, one person that really impressed me was Michael Bolton. He is really a great testing guy. He simply talks about the current scenarios that is happening with the testing team in every company and how the testing team should work under this environment. I am going to point out some points that I remembered from his presentations.
** -- ** About Automation : Automation should be ROBUST and DYNAMIC. Robust means your automation tool should be designed in such a way that it should test the application in a appropriate way. Dynamic means your automation tool can survive with the application after making some good amount of changes in it. It should be dynamic in terms of editing. Management should take care before going for automation that Automation needs some bandwidth in initial stage.
** -- ** Automation Testers vs. Business testers : There is a big difference between Automation testers and Business Testers. Automation testers are those testers who tests the application according to the test cases that they have created. Those test cases were created keeping only the technical aspects of the application. On the other hand, Business testers are those testes who have business view for that application. These kind of testers tests the application keeping only the business prospective in their mind. Normally Business testers are the higher management person of a company and Automation testers are the proper testing team.
** -- ** "I solve the testing problems that other people can't solve" : This should be true for each Testing Lead/Manager so that they can resolve the testing problems.
** -- ** "THE ONLY THING ONE POWERFUL THAN A GREAT IDEA, IS A GREAT IDEA POWERFULLY EXECUTED".
** -- ** Testing department view : Well, this is a most common view among almost all the testing departments. They viewed the quality of the product as the absence of bugs. But this is not true.
** -- ** Testers were not the QUALITY GATEKEEPERS.
** -- ** About Bug : A bug is anything that threatens the value of the project/product.
** -- ** "TESTING IS QUESTIONING A PRODUCT IN ORDER TO EVALUATE IT".
** -- ** Crime of Testing : It is like a Bank robbery. If you robbed a Bank and police catches you, you will be in jail. And if you are planning to rob a Bank and police catches you, you will be in Jail. So be prepared for performing the Crime of Testing.
** -- ** Asking the Right questions vs. getting the right answers : Now this comparison is very important for testing team. Just think about this.
** -- ** Remember "THE TEST IS WHAT YOU THINK AND DO".
** -- ** Documentation : Your manager says "That should be documented". This can be in terms of test cases, test plans, reports etc. But this really means "That should be documented if and when how it serves our purpose. Who will read it? Will they understand it?".
** -- ** Test cases are not the briefcases. Measuring the quality of a product/project in terms of number of test cases that have been executed is not a right procedure to measure the quality of it.
** -- ** Its up to testing team that whether they want to be steered or wants to work as a puppet.
** -- ** Now the most important question : When one should say that the testing is done?
1. When you have no more questions about the product.
2. When your management believes that the product can be shipped.
3. You addressed all important risks.
4. And most important : When your customer is satisfied.
That's all.
-- Sanat Sharma
Subscribe to:
Comments (Atom)