Design Driven Testing
As program manager for ESRI’s ArcGIS mapping software product, Jim is responsible for a daily build of 20 million lines of code. He previously managed the transportation and logistics department for ESRI Professional Services, where he brought many multi-million–dollar software projects in on-sche...
Đã lưu trong:
| Những tác giả chính: | , |
|---|---|
| Định dạng: | Sách |
| Ngôn ngữ: | English |
| Được phát hành: |
Apress
2012
|
| Những chủ đề: | |
| Truy cập trực tuyến: | http://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/30981 |
| Các nhãn: |
Thêm thẻ
Không có thẻ, Là người đầu tiên thẻ bản ghi này!
|
| Thư viện lưu trữ: | Thư viện Trường Đại học Đà Lạt |
|---|
| id |
oai:scholar.dlu.edu.vn:DLU123456789-30981 |
|---|---|
| record_format |
dspace |
| spelling |
oai:scholar.dlu.edu.vn:DLU123456789-309812014-01-20T06:33:17Z Design Driven Testing Stephens, Matt Rosenberg, Doug Technologies As program manager for ESRI’s ArcGIS mapping software product, Jim is responsible for a daily build of 20 million lines of code. He previously managed the transportation and logistics department for ESRI Professional Services, where he brought many multi-million–dollar software projects in on-schedule and on-budget using the design techniques described in this book. Lots of people have many strong opinions on virtually all aspects of testing software. I’ve seen or heard of varied methodologies, systems, procedures, processes, patterns, hopes, prayers, and simple dumb luck that some code paths will never get executed. With all this help, we must have figured out how to ship outstanding rock-solid bug-less software, right? Yet, with each new release of the next great, most stable revision of our software products, test engineers still make that wincing face (you know the one), drawing back a little when asked, “Do you have the appropriate tests across the entire software stack?” The wincing exists because the truthful answer to that question is almost always: “I think so, but I don’t really know all the areas I should have had tests for.” And the software shipped anyway, didn’t it—bummer. This is job security for the technical support team, because the bugs shipped out will be coming right back to your team for the next service pack or emergency hot fix. We can do much better, and this book will show you how. This book walks you through a proven software development process called ICONIX Process, and focuses on the creation and maintenance of both unit and acceptance tests based on and driven by the software design. This is design-driven testing (DDT). This is leveraging your design to pinpoint where critical tests need to be based on the design and object behavior. This is not test-driven design (TDD), where unit tests are written up front, before design is complete and coding starts. I don’t know about you, but I think it’s hard to predict the future, and even harder to get a software engineer to code something that “fits” a set of tests. While lots of folks have opinions about testing, one thing that I think we can all agree upon is that testing is often very hard and complex. As a program manager for a large development team, I know how quickly testing can get out of hand, or just stall out on a development project. Organizations have so much variance in the investment in testing, and, unfortunately, in the return on that investment. It’s possible to do way too much testing, thus wasting investment. But it’s more likely that you will do too little testing (thinking you did more than enough, of course), in the wrong areas of the software, not investing enough. This can happen because you just don’t know where the tests need to be to balance your investments, yielding the right testing coverage. 2012-06-08T09:14:51Z 2012-06-08T09:14:51Z 2010 Book 978-1-4302-2944-5 http://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/30981 en application/pdf Apress |
| institution |
Thư viện Trường Đại học Đà Lạt |
| collection |
Thư viện số |
| language |
English |
| topic |
Technologies |
| spellingShingle |
Technologies Stephens, Matt Rosenberg, Doug Design Driven Testing |
| description |
As program manager for ESRI’s ArcGIS mapping software product, Jim is responsible for a daily build of 20
million lines of code. He previously managed the transportation and logistics department for ESRI Professional
Services, where he brought many multi-million–dollar software projects in on-schedule and on-budget using the
design techniques described in this book.
Lots of people have many strong opinions on virtually all aspects of testing software. I’ve seen or heard of
varied methodologies, systems, procedures, processes, patterns, hopes, prayers, and simple dumb luck that
some code paths will never get executed. With all this help, we must have figured out how to ship outstanding
rock-solid bug-less software, right? Yet, with each new release of the next great, most stable revision of our
software products, test engineers still make that wincing face (you know the one), drawing back a little when
asked, “Do you have the appropriate tests across the entire software stack?”
The wincing exists because the truthful answer to that question is almost always: “I think so, but I don’t
really know all the areas I should have had tests for.” And the software shipped anyway, didn’t it—bummer.
This is job security for the technical support team, because the bugs shipped out will be coming right back to
your team for the next service pack or emergency hot fix. We can do much better, and this book will show you
how.
This book walks you through a proven software development process called ICONIX Process, and focuses
on the creation and maintenance of both unit and acceptance tests based on and driven by the software
design. This is design-driven testing (DDT). This is leveraging your design to pinpoint where critical tests need
to be based on the design and object behavior. This is not test-driven design (TDD), where unit tests are
written up front, before design is complete and coding starts. I don’t know about you, but I think it’s hard to
predict the future, and even harder to get a software engineer to code something that “fits” a set of tests.
While lots of folks have opinions about testing, one thing that I think we can all agree upon is that testing
is often very hard and complex. As a program manager for a large development team, I know how quickly
testing can get out of hand, or just stall out on a development project. Organizations have so much variance in
the investment in testing, and, unfortunately, in the return on that investment. It’s possible to do way too
much testing, thus wasting investment. But it’s more likely that you will do too little testing (thinking you did
more than enough, of course), in the wrong areas of the software, not investing enough. This can happen
because you just don’t know where the tests need to be to balance your investments, yielding the right testing
coverage. |
| format |
Book |
| author |
Stephens, Matt Rosenberg, Doug |
| author_facet |
Stephens, Matt Rosenberg, Doug |
| author_sort |
Stephens, Matt |
| title |
Design Driven Testing |
| title_short |
Design Driven Testing |
| title_full |
Design Driven Testing |
| title_fullStr |
Design Driven Testing |
| title_full_unstemmed |
Design Driven Testing |
| title_sort |
design driven testing |
| publisher |
Apress |
| publishDate |
2012 |
| url |
http://scholar.dlu.edu.vn/thuvienso/handle/DLU123456789/30981 |
| _version_ |
1757660381898080256 |