- Learning to Program—The stages of programming
- Learning to Program – Some Terms You Should Understand
- Learning to Program – IPO Charts (Stage 1)
- Learn to Program- Flowcharting (Stage 2)
- Learning to Program – Flowcharting (Stage 2). — Decisions and Loops
- Learning to Program—Flowcharting (Stage 2) – Case Statements
- Learning to Program (Stage 2)—Flowcharting – Methods and Classes
- Learning to Program – Structure and Spaghetti Code
- Learning to Program – Pseudocode (Stage 3) an overview
- Learning to Program – Stage 3 Pseudocode commands and reserved words
- Learning to Program—Stage 3 Pseudocode examples Part 1
- Learning to Program – Stage 3 Psuedocode (Arrays)
- Learning to Program – Stage 3: Pseudocode—Methods
- Learning To Program—Stage 3.5 (UML Diagrams)
- Learning to Program – (Stage 4) Coding
- Learning To Program—Stage 5 Testing
- Learning to Program—Stage 6 (Documentation)
- Learning to Program – Stage 7 (Maintenance)
- Learning to Program—Random Thoughts with a Theme
- Learning to Program- Two Main Types of Errors
- Learning to Program – Integrated Development Environments (IDE’s)
- Learning to Program
As I mentioned in my Stages of Programming post, this stage typically runs concurrently with Stage 4. As you create an executable version of the program, you’ll have people test it out. They’re looking for bugs, making suggestions for features that they want, and testing out the overall quality of the program.
Even a perfectly written program with all of the features is worthless, if it doesn’t do what the client/customer/end-user wants or needs. So one measure of quality is whether or not your testers want to use your program to accomplish the task. Another is the fact that the program runs, and they aren’t able to crash it (or get unexpected results).
If you’re programming for a limited customer (such as a corporation or a person), then you will have a small group of their employees testing your program. If possible, you will want to be on-site, although it’s possible to do it remotely.
If you’re programming for a larger audience (such as an Operating System or an application that the public will use) then you’ll want to get as large of a test-base as possible. For example, Microsoft has tens or hundreds of thousands of testers in their private betas—and countless more in the public betas, for their Windows Operating System releases. In the event that you are doing a public application (and a public beta) you will probably want to assemble a team for coding and triaging bug reports.
Even if your program is a simple upgrade to an existing program, you need testers. If you don’t test before releasing the upgrade, you could potentially break something that the users need, introduce logic (run-time) errors, corrupt data, or countless other problems. Any way you look at it, if you cost your customer money because of shoddy code, you’ll cost yourself more money.
Depending on the complexity of the program, your testing could be a few days to a year or more. And you could release one build or multiple builds. But it all needs to be planned in to the project. And you shouldn’t skimp on time, money, or resources for the testing.
For more information about the stages of testing, please look at this post.
Next we will cover Stage 6 (Documentation).
Have a great day:)