Comparison of Change Management Systems

More documents

Recommendations

Info

56 Software Testing Equivalence partitioning is a good basic technique! Remember combination testing! Finally, there is all the test material. A worst-case scenario is if the tester has to admit that the test cannot be done or has been wrong. A big problem is the test environment, which should be prepared and tested early. Waiting for the test environment to work can kill any testing effort (and everybody else will point fingers!). After that, a defect may not be in the object under test, but in the test data or the output analysis. Be self-critical! Test the test environment – well before test execution! Check you test data! And finally, there is test automation. A software product should be soft, i.e. easy to change. Change, however, is a risk. This means there is a need to test after any change. Retesting and regression testing may help. Running tests by using robots helps regression testing. But test automation is more than that: Tools may read specifications and automatically generate test cases. Tools may automatically create environments. Tools may be used to manage the testing effort and the test material. Automate testing tasks! Be aware that there is more automation than using test robots! 9. Selected References • Bach 2005: James Bach. A blog note about possible causes of intermittent bugs: http://blackbox.cs.fit.edu/blog/ james/ • Beizer 95: Boris Beizer, Black Box Testing, John Wiley, 1995 • Better Software Magazine, www. bettersoftware.com. www.stickyminds. com Very practical! • BS7925: British Standard: www. testingstandards.co.uk/bs_7925-1.htm • Copeland 2004: Lee Copeland, A Practitioner’s Guide to Software Test Design, Artech House, 2004. • Crispin: Lisa Crispin, Tip House, Testing Extreme Programming, Addison-Wesley, 2002, also http://home.att.net/~lisa. crispin/XPTesterBOR.htm • Gilb 2003: "Testers Rights: What Test should demand from others, and why?"., Keynote at EuroSTAR 2003 • GTB: German Testing Board: www. german-testing-board.info The German Testing Board developed an earlier version of the current ISTQB certification. • IEEE Standards: See www.ieee.org • ISEB: Information Systems Examinations Board of British Computer Society. http://www.bcs.org/BCS/ Products/Qualifications/ISEB/ has run a certification scheme for software testers since 1999. • ISTQB: www.istqb.org International Software Testing Qualifications Board. Develops and runs an international software tester certification scheme. • ISTQB Glossary: www.istqb.org/ fileadmin/media/glossary-current.pdf • Kaner 99: C. Kaner, J. Falk, H. Q. Nguyen, “Testing Computer Software (3rd ed.), John Wiley, 1999. • Kaner bugadvoc: A presentation about how a tester should report issues. http:// www.kaner.com/pdfs/BugAdvocacy.pdf • Myers 79: Glenford Myers: The Art of Software Testing, John Wiley, 1979. • Schaefer 2004; Hans Schaefer, “What Software People should have known about Software Testing 10 years ago - What they definitely should know today. Why they still don't know it and don't use it”, EuroSTAR 2004 • About famous software errors: http://wired.com/news/technology/ bugs/0,2924,69355,00.html?tw=wn_ tophead_1 • About assumptions: “Never Assume”, Sofie Nordhammen from St. Jude Medical at EuroSTAR 2005. (“Knowing What’s Right, Doing What’s Wrong”)
Efficient Testing with All-Pairs basic intermediate advanced About the author: Acknowledgements: This presentation draws upon material from various sources, especially Lessons Learned in Software Testing by Kaner, Bach and Pettichord. Many thanks to them for their time and advice. Thanks to the AETG team who developed the all-pairs approach. Thanks to the reviewers of this paper for their insightful feedback: Lawrence Nuanez, Michael Steinhart, Dmitry Shchelokov Introduction If you’re a software tester who’s been in the field for a few years, you may have found yourself in one of the following situations: • You’re working as hard as you can to find bugs in a huge system and you can’t get to everything within the deadline. You’ve already stumbled across some good bugs, and you think there are more in there, but the deadline comes and the software is released. A week later, a major client finds a serious problem with the new release and lets everyone know about it in an industry press release. You begin thinking about what went wrong and how you can improve your testing coverage. • You’re on a job interview, and the person across the desk asks you how to test a product, especially when there’s too much to do in so little time. • Your management has an elementary understanding of software testing, and as a result, sets unrealistic expectations for you to “test everything.” They demand 100% coverage, including testing all possible inputs, from all possible interfaces, into all possible system paths, into all possible outputs. You know these are ridiculous demands, and you start thinking about alternate testing methods. (and/or alternate employment opportunities). Well, I’m able to cite these examples because I’ve been in each of these situations myself. A few years ago, I started thinking about the Coverage question of testing software – how can you “test everything” without really testing everything? How can you test efficiently: to minimize testing efforts but maximie testing results? I found a method that I enjoy so much that I use it and talk about it as often as possible. I’ve seen this technique referred to as “Pairwise Testing,” “Combinatorial Method,” and “Orthogonal Arrays” (actually, each of these is similar but different), but I’ll use the term “All-Pairs.” In All-Pairs test design, we are concerned with variables of a system, and the possible values each variable could take. We will generate testcases by pairing values of different variables. Don’t re-read that last sentence -- generating testcases using All-Pairs is easier than it sounds. It’s like learning a new card game – at first you have to learn the object of the game, all the rules, and all the exceptions to the rules, and then the tips and strategies. But after you’ve played a few times, it seems naturally easy to play. It’s the same here. The best way to explain how it works is with an example, so keep reading… Cartesian Products A good starting point for a discussion about all-pairs is with Cartesian Products. A Cartesian product is a scenario in which every unit of a group is matched with every unit of every other group, so that all combinations of units are achieved Software Testing Author: Bernie Berger across all groups. For example, imagine the following simple software application: A one-screen GUI, with two drop down lists and an ‘OK’ button. List1 contains three values, ‘0’, ‘1’, and ‘2’; List2 contains two values, ‘10’, and ‘20’. The user selects one value from each list, and after clicking OK the product of the two values is displayed on the screen. The variables and their List1 0 1 2 List1 0 0 1 1 2 2 List2 10 20 values look like this: How would you test this program? How many input combinations are there? How long will it take to test all input combinations? There are 3x2= 6 possible combinations. The 6 resulting combinations are a result of the Cartesian product of the two inputs, List2 10 20 10 20 10 20 and would look like this: Each value of each variable is matched so that you have achieved all combinations. You can execute these tests manually in less than two minutes. Let’s add a 57
Page 1:
Engineering Productivity: Some ways
Page 4 and 5:
04 Welcome Editor’s note Quarterl
Page 6 and 7: 06 Management Agile software develo
Page 8 and 9: 08 Management driven development—
Page 10 and 11: 10 Management for are developing. O
Page 12 and 13: 12 Management Important factor here
Page 14 and 15: 14 Management behavior. They all lo
Page 16 and 17: 16 Management Figure 2 - Buffer man
Page 18 and 19: 18 Quality in Project Productivity
Page 20 and 21: 20 Quality in Project Engineering O
Page 22 and 23: 22 Quality in Project For example i
Page 24 and 25: 24 Quality in Project measure of en
Page 26 and 27: 26 Quality in Project Figure 1 What
Page 28 and 29: 28 Quality in Project early complet
Page 30 and 31: 30 Software Engineering Comparison
Page 32 and 33: 32 Software Engineering has a poor
Page 34 and 35: 34 Software Engineering or function
Page 36 and 37: 36 Software Engineering Let’s loo
Page 38 and 39: 38 Software Engineering What’s fu
Page 40 and 41: 40 Software Engineering Note, unles
Page 42 and 43: 42 Software Engineering Usability.I
Page 44 and 45: 44 Software Engineering Figure 11 A
Page 46 and 47: 46 Software Engineering cyclical le
Page 48 and 49: 48 Software Testing motivating if t
Page 50 and 51: 50 Software Testing This concept of
Page 52 and 53: 52 Software Testing defects, or the
Page 54 and 55: 54 Software Testing 5. A Critical M
Page 58 and 59: 58 Software Testing little more com
Page 60 and 61: 60 Software Testing Good, now let
Page 62 and 63: 62 Software Testing an important pa
Page 64 and 65: 64 Software Testing the software de
Page 66 and 67: 66 Software Testing Five Types of R
Page 68 and 69: 68 Software Testing Figure 2 A typi
Page 70 and 71: 70 Software Testing Figure 4 Typica
Page 72 and 73: 72 Software Testing Confrontation o
Page 74 and 75: 74 Software Testing Quality Managem
show all

Comparison of Change Management Systems

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?