Lessons Learned in Software Testing: A Context-Driven ApproachJohn Wiley & Sons, 2 באוג׳ 2011 - 320 עמודים Softwaretests stellen eine kritische Phase in der Softwareentwicklung dar. Jetzt zeigt sich, ob das Programm die entsprechenden Anforderungen erfüllt und sich auch keine Programmierungsfehler eingeschlichen haben. Doch wie bei allen Phasen im Software-Entwicklungsprozess gibt es auch hier eine Reihe möglicher Fallstricke, die die Entdeckung von Programmfehlern vereiteln können. Deshalb brauchen Softwaretester ein Handbuch, das alle Tipps, Tricks und die häufigsten Fehlerquellen genau auflistet und erläutert, damit mögliche Testfehler von vornherein vermieden werden können. Ein solches Handbuch ersetzt gut und gerne jahr(zehnt)elange Erfahrung und erspart dem Tester frustrierende und langwierige Trial-und-Error-Prozeduren. Chem Kaner und James Bach sind zwei der international führenden Experten auf dem Gebiet des Software Testing. Sie schöpfen hier aus ihrer insgesamt 30-jährigen Erfahrung. Die einzelnen Lektionen sind nach Themenbereichen gegliedert, wie z.B. Testdesign, Test Management, Teststrategien und Fehleranalyse. Jede Lektion enthält eine Behauptung und eine Erklärung sowie ein Beispiel des entsprechenden Testproblems. "Lessons Learned in Software Testing" ist ein unverzichtbarer Begleiter für jeden Software Tester. |
תוכן
| 1 | |
| 7 | |
| 11 | |
| 14 | |
Lesson | 24 |
Lesson | 30 |
Testing Techniques | 31 |
Lesson | 55 |
Assign a bug hunter to the project | 176 |
Test in sessions | 177 |
Regular status reports are powerful tools | 178 |
ThereLs nothing more dangerous than a vice president with statistics | 179 |
Be cautious about measuring the projectLs progress in terms of bug counts | 180 |
The more independent coverage measures you use the more you know | 181 |
Use a balanced scorecard to report status on multiple dimensions | 182 |
HereLs a suggested structure for a weekly status report | 183 |
Lesson | 61 |
Bug Advocacy | 65 |
Lesson | 67 |
The summary line is the most important line in the bug report | 76 |
Lesson | 86 |
Automating Testing | 93 |
Test tools are buggy | 104 |
Lesson | 106 |
Select GUI test tools based on compatibility familiarity and service | 107 |
Automated regression tests die | 108 |
Test automation is a software development process | 109 |
Use pilot projects to prove feasibility | 111 |
Design automated tests to facilitate review | 112 |
Avoid complex logic in your test scripts | 113 |
Datadriven test automation makes it easy to run lots of test variants | 114 |
Keyworddriven test automation makes it easy for nonprogrammers to create tests | 115 |
Use automated techniques to generate test inputs | 116 |
Separate test generation from test execution | 117 |
Automate tests using programming interfaces | 119 |
Encourage the development of unit test suites | 120 |
Beware of using automators who donLt understand testing | 121 |
Avoid automators who donLt respect testing | 122 |
Testability is visibility and control | 123 |
Start test automation early | 124 |
Give centralized automation teams clear charters | 125 |
Automate for immediate impact | 126 |
Documenting Testing | 129 |
To apply a solution effectively you need to understand the problem clearly | 131 |
They foster consistent communication | 132 |
DonLt use the IEEE Standard 829 | 133 |
Analyze your requirements before deciding what products to build this applies as much to your documentation as to your software | 136 |
Summarize your core documentation requirements in one sentence with no more than three components | 141 |
Interacting with Programmers | 143 |
Lesson | 144 |
Managing the Testing Project | 151 |
Lesson | 158 |
Lesson | 164 |
Lesson 186 | 171 |
To create a schedule for a set of tasks estimate the amount of time needed for each task | 172 |
The person who will do the work should tell you how long a task will take | 173 |
There is no right ratio of testers to other developers | 174 |
Rotate testers across features | 175 |
A project dashboard is another useful way for showing status | 184 |
Milestone reports are useful when milestones are well defined | 185 |
DonLt signoff to approve the release of a product | 186 |
If you write a release report describe your testing work and results not your opinion of the product | 187 |
Managing the Testing Group | 189 |
Treat your staff as executives | 190 |
Read your staffLs bug reports | 191 |
If you really want to know whatLs going on test with your staff | 193 |
Build your testing staffLs domain expertise | 194 |
Work actively on skills improvement | 195 |
Have new testers check the documentation against the software | 196 |
Familiarize new testers with the product through positive testing | 197 |
DonLt put novice testers on nearly finished projects | 198 |
The morale of your staff is an important asset | 199 |
DonLt let yourself be abused | 200 |
DonLt let your staff be abused | 202 |
Your hiring decisions are your most important decisions | 203 |
Plan in terms of the tasks you need to do in your group and the skills needed to do them | 204 |
Hire opportunity candidates | 205 |
Hire by consensus | 206 |
During the interview have the tester demonstrate skills heLll actually use on the job over informal aptitude tests | 207 |
Hire quickly after you make up your mind | 208 |
Your Career in Software Testing | 209 |
TestersL incomes can be higher than programmersL incomes | 211 |
Feel free to change your track and pursue something else | 212 |
Extend your career beyond software testing | 213 |
Conferences are for conferring | 214 |
If you donLt like your company look for a different job | 215 |
Build and maintain a list of companies where youLd like to work | 216 |
Use your resume as a sales tool | 217 |
Get an inside referral | 218 |
Learn about companies when you apply for jobs with them | 219 |
Ask questions during job interviews | 220 |
Negotiate your position | 221 |
Be cautious about Human Resources | 223 |
Download demo copies of testing tools and try them out | 224 |
Planning the Testing Strategy | 231 |
| 261 | |
Bibliography | 265 |
| 275 | |
מהדורות אחרות - הצג הכל
מונחים וביטויים נפוצים
apply approach automated tests better bug report build clients common complete configuration cost create critical customers detailed documentation don't effective effort engineering error esson evaluate example executives expect experience fail failure field focus follow functions give happen ideas important interesting interface involves issues it's knowledge L esson less look matter means meetings never performance person possible practice probably problems programmers project manager questions reasonable release requirements risk situation skills software testing someone sometimes specification staff standard suggest tasks technical techniques tell test automation test documentation test plan test strategy testers things understand variable write you're