Heuristics
Testing vs. Checking ... my 2 cents.
Submitted by sbarber on Wed, 23/09/2009 - 07:10. context-driven testing | functional testing | general software testing | heuristics | people issues | perspectivesI was pleased to see Michael Bolton's series on Testing vs. Checking. If you haven't been following, what I consider to be the central thread of the topic (and the unfortunately inevitable fallout that seems to happen in "testerland" almost any time someone says something that makes sense).
From Michael:
- http://www.developsense.com/2009/08/testing-vs-checking.html
- http://www.developsense.com/2009/09/transpection-and-three-elements-of.html
- http://www.developsense.com/2009/09/pass-vs-fail-vs-is-there-problem-here.html
- http://www.developsense.com/2009/09/elements-of-testing-and-checking.html
From James Bach:
From Scott Barber:
- http://www.perftestplus.com/resources/014PeakPerf.pdf Original, ST&P Magazine, 2005
- http://www.logigear.com/newsletter/investigation_vs_validation.asp Reprinted by Logigear, 2007
A refactored assertion-based test oracle........for US presidents???
Submitted by Erik Petersen on Sun, 02/11/2008 - 12:52. agile | heuristics | perspectivesAn Assertion-based (also known as programmer tests in Test Driven Development) Test Oracle (an information source of what makes a test correct) was developed 27 years ago, well before TDD was thought of but probably around the time test oracles were thought of. That was also long before refactoring was thought of, simplifying the logic to its simplest form.
It was designed by US history professor Allan Lichtman and mathematician Volodia Keilis-Borok. It is 13 assertions (that is refactored all right) that can each be true or false, and has picked every US federal election result since 1984. If more than half of the assertions are true, the governing party will win, otherwise they will lose. The majority of the assertions first went false in early 2006, at which point Lichtman said “Long before the nomination contest unfolded, the Democrats could take a name out of a phone book and still win.” I guess they must have used a Chicago phone book, or maybe even a Brazilian one! (where there are now multiple Barack Obamas) This year the test oracle has evaluated False, but if we look at it vice-versa, True or even Yes we can! [grin]
If the test oracle is correct, newspapers will print this mock headline on Wednesday the 5th of November 2008. (There’s another agile word, mock!)
June Issue of AST Update Now Available
Submitted by sbarber on Fri, 22/08/2008 - 18:48. general software testing | heuristics | industry recognition | metaphors | other online resources | perspectives
June 2008 Issue of the Association for Software Testing Magazine and Newsletter Now Available
Latest Column -- Inspired by taking AST's Bug Advocacy Class
Submitted by sbarber on Fri, 04/07/2008 - 05:54. bug tracking/incident management | context-driven testing | functional testing | heuristics | other online resources | perspectives | project management | test managementSoftware testing is improved by good bug reporting
I recently completed (successfully, I might add) the second of the Association for Software Testing's all online, free to members Black Box Software Testing course. Each of these courses is four weeks in length. I've been involved with this program since years before it became a program, and I am an instructor for the first course in the series, called Foundations. For this course, called Bug Advocacy, I was a student.
Grey-box techniques for excluding tests
Submitted by Ainars Galvans on Mon, 30/06/2008 - 13:33. heuristics Don’t test the reused code tested previously – you will have more time to test new code. This heuristic for a black-box tester is basically all the idea of this blog – one I was creating for a week … I started this as blog about techniques, but wanted to be clear about grey box. A research on the term ended quite a long story below. If you don’t care about it – scroll down to the last chapter describing the techniques.
Linguistic heuristics
Submitted by Karen N. Johnson on Sun, 22/06/2008 - 06:05. databases & SQL | heuristicsSearching. I’m currently testing a product that has a search feature. I’ve tested search functionality before but not a multilingual search engine that utilizes two different search engines based on the language selected. Nor have I previously worked with a search engine that uses stemming and stop words.
I almost didn’t want to write about this – figured I would wait until I resolved my challenges before writing about it – but it occurred to me why? It’s not as though in software testing I haven’t learned that first understanding the complexities of a problem is an essential starting point.
I almost didn’t want to write about this – figured I would wait until I resolved my challenges before writing about it – but it occurred to me why? It’s not as though in software testing I haven’t learned that first understanding the complexities of a problem is an essential starting point.
Testing Lessons From Civil Engineering
Submitted by sbarber on Sat, 21/06/2008 - 07:13. context-driven testing | development methodology | events | functional testing | general software testing | heuristics | patterns | perspectives | test analysisBelow is the paper I submitted as a prologue to an experience report, discussion, and (hopefully) additional research that I'm presenting for the first time during:
Reliability is not only about overload: RANDOMize your system state
Submitted by Ainars Galvans on Thu, 24/04/2008 - 17:15. heuristics | reliability testingI never used mnemonics. Never say never... Here is my own mnemonic. Double RANDOM stands for ReadRights AalternativeAccess, NoNetwork, DesynchronyzedData, OutOf(whatever resource), MinMax(installation). Depending on context (e.g. reliability requirements, etc.) I spend more or less time trying to emulate system states unexpected by developer and thus unhandled by code.