Software Testing Basics<\/p>\n
Note: Different testing strategies are described here. In practice, a detail test plan is helpful that may be formed with a subset of these strategies [and delivered to the testers] according to the need of the customers, and the company policies.<\/p>\n
Five Fold Testing System<\/p>\n
Any testing can be described in five dimensions:
\n1. Testers: Who does the testing?
\n2. Coverage: What needs to be tested? function, domain, extreme value?
\n3. Potential Problems: Why you are testing?
\n4. Activities: How you test?
\n5. Evaluation: How to measure the success of testing?<\/p>\n
Some Forms of Testing<\/p>\n
1. Function testing: Test all functions
\n2. Extreme Value Testing: Test for errors when extreme values of the variables are used
\n3. beta testing: make other people test your product<\/p>\n
All testing involve five dimensions. When we tell to do function testing, we can list: who will do the test (programmers, testers, users of the product, internal employees), what needs to be tested like functions, what kind of problems they need to address such as pass by value or pass by reference, test method, evaluate your test<\/p>\n
People Based Techniques<\/p>\n
1. User Testing: Tests by the real users of the product
\n2. Alpha testing: By Test team, firendly insiders
\n3. Beta testing: Not insiders, not clients, but may be part of the target market, volunteers
\n Design Beta tests: appraise the design
\n marketing beta tests: to justify will customers buy the product?
\n compatibility beta tests: test hw\/sw platform compatibility
\n4. bug bashes: in house testing, just before release one full day\/half day testing
\n5. subject matter testing: give an expert on the subject to use and test the product
\n6. Paired testing: two person together do the tests and shares ideas
\n7. eat your own dogfood: use the software in-house for your own purpose and check reliability<\/p>\n
Coverage based testing<\/p>\n
1. Function testing: Test each function
\nWhite box function testing: testing in respect of code
\nBlack box function testing: test functions in respect of features and commands
\n2. Function integration testing: test several functions together
\n3. Menu tour: check all menu items, all available choices
\n4. Domain testing: Test variable domains and their effect on functions. Find the possible values that a variable can take, classify the value domain, take representative values from each domain, test the variables and related functions
\n5. Equivalence class analysis: find equivalent domains and tests for one of them
\n6.Boundary test: Check for smallest and largest values for a variable
\n7. best representative testing
\n8. input field test catalogs or matrices
\n9. Map and test all the ways to edit a field
\n10. Logic testing: use logics like if then else. cause effect graphing is used for logic based testing
\n11. state based testing:
\n12. Path testing: All possible paths to come\/go to a state
\n13. Statement and branch coverage: execute all statements and all branching
\n14. Configuration coverage: test how many types of printers your software support
\n15. Specification based testing: Test all claims made in the manual\/specification
\n16. Requirements-based testing: test if all requirements are met
\n17. combination testing: testing two or more variables in combination with each other<\/p>\n
Problems based techniques
\n1. Input constraints Tests: Check what kinds of input the program can handle. Also check input error protection
\n2. Output constraints: The inputs are legal but check if they lead to corresponding out value
\n3. computation constraints : the program may fail while calculating a value
\n4. Storage constraints: out of memory tests, too big output file to process
\n5. timimg: race condition, ordering of events<\/p>\n
Activity based Testing<\/p>\n
How you test?
\n1. Regression Testing: Test the same issue again.
\na. Bug fix regression : bug is fixed but do the test again to prove the bug is not fixed
\nb. old bugs regression: new bug fix has unfixed old bugs. so test again
\nc. side effect regression\/stability regression : the bug fix has created new bugs\/side effects
\n2. Scripted Testing: execute step by step methods written by senior tester
\n3. smoke testing : kind of side effect regression testing. but test to prove that no side effect has come. show everything is working. assume may be some simple stuffs have caused the problems not the bug fix. if you can not prove then the new bug fix has created new errors
\n4. exploratory testing: keep the testers known about the project, product, market, risks. So new tests will be stronger than earlier ones as experience is more
\n5. guerilla testing: a fast and extensive exploratory test done by senior tester. test whole day a particular part extensively and decide if that area needs much\/more testing or can be ignored
\n6. scenario testing:
\na. test what the customer will really do
\nb. complex feature testing
\nc. easy to decide success\/failure<\/p>\n
tests that come from use cases.<\/p>\n
7. Installation testing: install in various platform, in different methods, check the files, check if the program works?, check uninstallation
\n8. Load testing: Test the system at high enough load
\n9. long sequence testing: run the program for days, weeks. problems like wild pointers, memory leaks, stack overflows, and bad interaction among multiple features are caught by this duration testing
\n10. Performance testing: test the speed\/efficiency of the software. A significant change in speed from time to time is a bad indication and the software need to be optimized<\/p>\n
Evaluation based testing
\nMethods to determine if a test has passed or failed
\n1. Self verifying data:
\n2. compare with saved results: if results vary over the week\/day, something is wrong
\n3. compare with specification: mismatch with the specification, failure
\n4. consistency:
\na. with history: software behavior consistent with past behavior?
\nb. with company image: matches with the image that company focuses on?
\nc. with claims: does what it is supposed to do
\nd. user’s expectations: meets users expectations
\ne. within product: consistent with other functions
\nf. purpose: consistent with it’s purpose?
\n From: http:\/\/sitestree.com\/?p=282
Categories:Software Development, Root, Software Testing, By Sayed Ahmed
Tags:
Post Data:2013-04-26 03:29:34<\/p>\n
\t\tShop Online: https:\/\/www.ShopForSoul.com\/<\/a> Software Testing Basics Note: Different testing strategies are described here. In practice, a detail test plan is helpful that may be formed with a subset of these strategies [and delivered to the testers] according to the need of the customers, and the company policies. Five Fold Testing System Any testing can be described in five … <\/p>\n
\n\t\t(Big Data, Cloud, Security, Machine Learning): Courses: http:\/\/Training.SitesTree.com<\/a>
\n\t\tIn Bengali: http:\/\/Bangla.SaLearningSchool.com<\/a>
\n\t\thttp:\/\/SitesTree.com<\/a>
\n\t\t8112223 Canada Inc.\/JustEtc: http:\/\/JustEtc.net (Software\/Web\/Mobile\/Big-Data\/Machine Learning) <\/a>
\n\t\tShop Online: https:\/\/www.ShopForSoul.com\/<\/a>
\n\t\tMedium: https:\/\/medium.com\/@SayedAhmedCanada <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"