Posts

Showing posts from December, 2007

v model to w model

Image
V-Model: The V-model promotes the idea that the dynamic test stages (on the right hand side of the model) use the documentation identified on the left hand side as baselines for testing. The V-Model further promotes the notion of early test preparation. The V-Model of testing Early test preparation finds faults in baselines and is an effective way of detecting faults early. This approach is fine in principle and the early test preparation approach is always effective. However, there are two problems with the V-Model as normally presented. The V-Model with early test preparation There is rarely a perfect, one-to-one relationship between the documents on the left hand side and the test activities on the right. For example, functional specifications don’t usually provide enough information for a system test. System tests must often take account of some aspects of the business requirements as well as physical design issues for example. System testing usually draws on several sources of re

v model to w model

Image
V-Model: The V-model promotes the idea that the dynamic test stages (on the right hand side of the model) use the documentation identified on the left hand side as baselines for testing. The V-Model further promotes the notion of early test preparation. The V-Model of testing Early test preparation finds faults in baselines and is an effective way of detecting faults early. This approach is fine in principle and the early test preparation approach is always effective. However, there are two problems with the V-Model as normally presented. The V-Model with early test preparation There is rarely a perfect, one-to-one relationship between the documents on the left hand side and the test activities on the right. For example, functional specifications don’t usually provide enough information for a system test. System tests must often take account of some aspects of the business requirements as well as physical design issues for example. System testing usually draws on several sources of re

Equivalence partitioning

Equivalence partitioning: Equivalence partitioning is a method for deriving test cases. In this method, classes of input conditions called equivalence classes are identified such that each member of the class causes the same kind of processing and output to occur. In this method, the tester identifies various equivalence classes for partitioning. A class is a set of input conditions that are is likely to be handled the same way by the system. If the system were to handle one case in the class erroneously, it would handle all cases erroneously. Equivalence partitioning drastically cuts down the number of test cases required to test a system reasonably. It is an attempt to get a good 'hit rate', to find the most errors with the smallest number of test cases. To use equivalence partitioning, you will need to perform four steps: Determining conditions to be Tested Defining Tests Designing test cases Identifying Final set of Test Cases Defining Tests A number of items must be cons

Cyclomatic complexity

Cyclomatic complexity is a software metric (measurement). It was developed by Thomas McCabe and is used to measure the complexity of a program. It directly measures the number of linearly independent paths through a program's source code. It is computed using a graph that describes the control flow of the program. The nodes of the graph correspond to the commands of a program. A directed edge connects two nodes if the second command might be executed immediately after the first command. Definition M = E − N + 2P where M = cyclomatic complexity E = the number of edges of the graph N = the number of nodes of the graph P = the number of connected components. "M" is alternatively defined to be one larger than the number of decision points (if/case-statements, while-statements, etc) in a module (function, procedure, chart node, etc.), or more generally a system. Separate subroutines are treated as being independent, disconnected components of the program's control flo

test coverage matrix vs traceblity matrix

Test coverage matrix: Test coverage matrix is a checklist which ensures that the functionality of the given screen(unit) is checked in all possible combinations (positive and negative) which have not been covered in test cases. Test coverage matrix is usually prepared for a screen having large number of controls (textboxes, dropdowns, buttons etc) usually, test coverage matrix is prepared in a spread sheet having all the controls (textboxes, dropdowns, buttons etc) in the columns and then all possible entries in those fields in the rows with an ''yes'' or ''no'' in the rows against the controls listed in the columns. For example, consider a ''login'' screen wherein we have ''username'' and ''password" textfields. While preparing test coverage matrix, the first column will be ''s.no'' and the second will be ''username" and ''password" will be the third field followed b

Top 24 replies by programmers when their programs don't work:

Top 24 replies by programmers when their programs don't work: 24. "It works fine on MY computer" 23. "Who did you login as ?" 22. "It's a feature" 21. "It's WAD (Working As Designed)" 20. "That's weird..." 19. "It's never done that before." 18. "It worked yesterday." 17. "How is that possible?" 16. "It must be a hardware problem." 15. "What did you type in wrong to get it to crash?" 14. "There is something funky in your data." 13. "I haven't touched that module in weeks!" 12. "You must have the wrong version." 11. "It's just some unlucky coincidence." 10. "I can't test everything!" 9. "THIS can't be the source of THAT." 8. "It works, but it's not been tested." 7. "Somebody must have changed my code." 6. "Did you check for a virus on your system?" 5. "Ev

A software BUG

Image