以下內容大部分來自 ron-patton-software-testing第2章
文章目錄
Product Components
What Effort Goes Into a Software Product?
A lot of hidden effort goes into a software product
The term used in the software industry to describe a software product component that’s created and passed on to someone else is deliverable.
The easiest way to explain what all these deliverables are is to organize them into major categories.
-
Customer Requirements
Some teams simply guess, but most collect detailed information in the form of surveys, feedback from previous versions of the software, competitive product information,magazine reviews, focus groups, and numerous other methods, some formal, some not -
Specifications
-
Schedules
The goals of scheduling are to know which work has been completed, how much work is still left to do, and when it will all be finished -
Software Design Documents
• Architecture.
• Data Flow Diagram.
• State Transition Diagram.
• Flowchart.
• Commented Code. -
Test Documents
Test plan
test cases
bug reports
metrics statistics, and summaries
What Parts Make Up a Software Product?
Help files
Users manual
Samples and examples
Labels and stickers
Product support info
Icons and art
Error messages
Ads and marketing material
Setup and installation
Readme file
Software Project Staff
• Project managers, program managers, or producers drive the project from beginning to end. They’re usually responsible for writing the product spec, managing the schedule, and making the critical decisions and trade-offs.
• Architects or system engineers are the technical experts on the product team. They’re usually very experienced and therefore are qualified to design the overall systems architecture or design for the software. They work very closely with the programmers.
• Programmers, developers, or coders design, write, and fix bugs in the software. They work closely with the architects and project managers to create the software. Then, they work closely with the project managers and testers to get the bugs fixed.
• Testers or QA (Quality Assurance) are responsible for finding and reporting problems in the software product. They work very closely with all members of the team as they develop and run their tests, and report the problems they find.
• Technical writers, user assistance, user education, manual writers, or illustrators create the paper and online documentation that comes with a software product.
• Configuration management or builder handles the process of pulling together all the software written by the programmers and all the documentation created by the writers and putting it together into a single package.
Software Development Lifecycle Models
The process used to create a software product from its initial conception to its public release is known as the software development lifecycle model.
Each model has its advantages and disadvantages.
As a tester, you will likely encounter them all and will need to tailor(調整） your test approach to fit the model being used for your current project.
Big-Bang Model
A huge amount of matter (people and money) is put together, a lot of energy is
expended—often violently—and out comes the perfect software product…or it doesn’t.
優：
it’s simple.
There is little if any planning, scheduling, or formal development process.
All the effort is spent developing the software and writing the code.
It’s an ideal process if the product requirements aren’t well understood and the final release date is flexible.
It’s also important to have very flexible customers, too, because they won’t know what they’re getting until the very end.
In most cases, there is little to no formal testing done under the big-bang model. 在大多數情況下，幾乎沒有正式測試在大爆炸模型下完成
If you are called in to test a product under the big-bang model, you have both an easy and a difficult task.
Because the software is already complete, you have the perfect specification—the product itself. And, because it’s impossible to go back and fix things that are broken, your job is really just to report what you find so the customers can be told about the problems.
缺點：
The downside is that, in the eyes of project management, the product is ready to go, so your work is holding up delivery to the customer(您的工作阻礙了交付給客戶).
The longer you take to do your job and the more bugs you find, the more contentious the situation will become.
Try to stay away from testing in this model.
Code-and-Fix Model
“There’s never time to do it right, but there’s always time to do it over.”
A team using this approach usually starts with a rough idea of what they want, does some simple design, and then proceeds into a long repeating cycle of coding, testing, and fixing bugs. At some point they decide that enough is enough and release the product.
Waterfall Model
A project using the waterfall model moves down a series of steps starting from an initial idea to a final product. At the end of each step, the project team holds a review to determine if they’re ready to move to the next step. If the project isn’t ready to progress, it stays at that level until it’s ready.
優點：
It’s simple, elegant, and makes sense. And, it can work well on the right project.
測試優點：
From a testing perspective, the waterfall model offers one huge advantage over the other models presented so far. Everything is carefully and thoroughly specified.
By the time the software is delivered to the test group, every detail has been decided on, written down, and turned into software.
From that, the test group can create an accurate plan and schedule. They know exactly what they’re testing, and there’s no question about whether something is a feature or a bug.
缺點：
in today’s fast moving culture, with products being developed on Internet time, by the time a software product is so carefully thought out and defined, the original reason for its being may have changed.
測試缺點：
testing occurs only at the end, a fundamental problem could creep in early on and not be detected until days before the scheduled product release.
they become too costly.
Spiral Model
you don’t define everything in detail at the very beginning. You start small, define your important features, try them out, get feedback from your customers, and then move on to the next level. You repeat this until you have your final product.
您一開始並沒有詳細定義所有內容。 從小處着手，定義重要功能，進行嘗試，從客戶那裏獲得反饋，然後再進行下一個階段。 重複此步驟，直到獲得最終產品。
Each time around the spiral involves six steps:
- Determine objectives, alternatives, and constraints
- Identify and resolve risks.
- Evaluate alternatives.
- Develop and test the current level.
- Plan the next level.
- Decide on the approach for the next level.
優點：
The lower costs of finding problems early