Don't Write Your Own Test Plans

Not only should you not be the sole tester of your own software, but you should also not be responsible for generating the test data, test scenarios, or test plans for your software. If you are, you may make the same mistakes in test generation that you made in software creation. For example, if you made a false assumption about the range of legal inputs when engineering the software, you would likely make the same assumption when generating test plans.

If you are a programmer and/or designer and your manager has asked you to write your test plans, I recommend you switch the test plan generation responsibility with a fellow programmer and/or designer. If you are a member of a requirements engineering team, with responsibility for system test generation as well, I recommend that members of your team subdivide the responsibilities so that no individual generates tests for requirements that she or he wrote.

Don't Test Your Own Software

Software developers should never be the primary testers of their own software. It is certainly appropriate to do initial debugging and unit testing.

Independent testers are necessary:

1. To check a unit for adequacy before starting integration testing.
2. For all integration testing.
3. For all system testing.

The correct attitude during testing is that of wanting to expose bugs. How can a developer possibly embrace that attitude? Testing is difficult enough without burdening it further with testers who have a bias toward no finding bugs.

Reference:

Myers, G., The Art of Software Testing, New York: John Wiley & Sons, 1979.

Plan Tests Long Before It Is Time To Test

Often software developers create their software product, then scratch their heads and say, "Now, how are we going to test this thing?" Test planning is a major task and must occur in parallel with product development so that test planning and initial (that is, pretesting) development activities are completed in synchrony.

For software system testing, test planners should review the SRS for testability before it is baselined and provide feedback to requirements writers. Serious development of the tests should start soon after baselining requirements. For integrations testing, test planners should review the preliminary design before it is baselined. They should also provide feedback to the project managers and designers concerning (1) sensible allocations of resources to ensure that the "right" components (from a testing point of view) are produced in the right order and (2) modifications to the design to make it inherently easier to test. Serious integration test development should start soon after baselining the preliminary design. For unit testing, unit test plan development can start immediately after the completion of detailed design.


Reference:
Goodenough, J., and Gerhart, S., "Toward a Theory of Test Data Selection," IEEE Transactions on Software Engineering, June 1975.

It's Superman

It's Superman! by Tom De Haven
My rating: 3 of 5 stars

I enjoyed Tom De Haven's writing style and the story was good. But there were too many liberties taken with the idea of Superman for me to really enjoy it. De Haven puts a heavy gloss of reality on the story of Superman and sets the origin story in the 30s.

View all my reviews

Trace Tests To Requirements

It is important to understand which tests verify which requirements. There are two reasons:

1. When generating tests, you'll find it useful to know if all requirements are being tested.
2. When performing tests, you'll find it useful to know which requirements are being checked.

Furthermore, if your requirements have been prioritized, you can easily derive the relative priorities of the tests; that is, the priority of a test is the maximum of the priorities of all its corresponding requirements.

Maintain a large binary table in which rows correspond to all software tests and columns correspond to every requirement in the software requirements specification (SRS). A 1 in any position indicates that this test helps to verify this requirement. Notice that a row void of 1's indicates that a test has no purpose and that a column void of 1's indicates an untested requirement. The successful creation of such a table depends on your ability to refer uniquely to every requirement.

Reference:

Lindstrom, D., "Five Ways to Destroy a Development Project," IEEE Software, Sept. 1992.

Travel Ireland

It has been over a decade since I visited Ireland. Above is a photo of me at Blarney Castle. I like to watch the various travel videos that Expedia makes to remind me of places I've been and places that I would like to go.

Check out "Visit Dublin –Things To Do and See in Dublin, Ireland":

Obviously, I would recommend visiting Blarney Castle once you're done in Dublin.

   

Don't Code Too Soon

Coding software is analogous to constructing a building. Both require much preliminary work. Constructing a building without a solid and stable foundation will not work. Coding without a solid and stable foundation of requirements and design will not work. Think about how much more difficult it is to modify a building after the foundation is poured!
    Don't be coerced into coding prematurely because management wants to see "progress." Be sure the requirements and design are correct and appropriate before baselining them and certainly before coding the final product. Incidentally, don't conclude from this principle that prototyping is bad. There is nothing wrong with experimenting with coding long before requirements are baselined. Just don't consider it the final product. Manny Lehman adds a counterpoint to this principle: Don't code too late!


Reference:
Berzins, V., and Luqi, Software Engineering with Abstractions, Reading, MA: Addison-Wesley, 1991.

Format Your Programs

The understandability of a program is greatly enhanced by using standard indentation protocols. Which protocol you choose to follow matters little, but, once you select it, use it consistently.

The only thing worse than inconsistent indentations is incorrect indentation (such as, aligning an ELSE with the wrong IF)! To prevent accidental misalignments, use a pretty printer.


Reference:
McConnell, S., Code Complete, Redmond, WA: Microsoft Press, 1993.

Harry Potter and the Order of the Phoenix

Harry Potter and the Order of the Phoenix by J.K. Rowling
My rating: 5 of 5 stars

Harry Potter and the Order of the Phoenix assaulted my emotions more than any of the previous books. There were plenty of unfair issues to feel sympathy for in the earlier books but emotions are more quickly evoked in this book. I do hope that Harry is able to better control his anger in the next book. And Snape is such a sad example of what happens to a person when they can't let go of past grievances. Seriously, a study of Snape should be a required course so people can think about would sort of sad sack they might turn into if they hang onto anger and hate. I am thoroughly enjoying the different characters in this series.

View all my reviews

Language Knowledge Is Not So Important

Good programmers are good regardless of the language used. Poor programmers are poor regardless of the language used. Nobody is a "great Java programmer" and a "poor Python programmer." If they really are poor at Python, they probably were not great at Java! In addition, a really good programmer should be able to learn any new language easily. This is because a really good programmer understands and appreciates the concepts of quality programming, not just the syntactic and semantic idiosyncrasies of some programming language.

So the primary driver of language selection for a project should be appropriateness, not the surge of programmers who whine, "But all we know is Ruby." If some quit because the project selected a different language, the project is probably better off!


Reference:
Boehm, B., Software Engineering Economics, Englewood Cliffs, NJ: Prentice Hall, 1981.

https://www.youtube.com/watch?v=fkY7W6kCRY4