July 10th, 2008 chris
Programming is in many ways a conversation with a computer. You write code that tells the computer what to do, and it responds by doing exactly what you tell it. In time you close the gap between what you want it to do and what you tell it to do. Programming in this mode is all about saying exactly what you want. But there is another user of your source code. Someone will try to read your code in a few months’ time to make some changes. We easily forget that extra user of the code, yet that user is actually the most important. Who cares if the computer takes a few more cycles to compile something? It does matter if it takes a programmer a week to make a change that would have taken only an hour if she had understood your code.
The trouble is that when you are trying to get the program to work, you are not thinking about that future developer. It takes a change of rhythm to make changes that make the code easier to understand. Refactoring helps you to make your code more readable. When refactoring you have code that works but is not ideally structured. A little time spent refactoring can make the code better communicate its purpose. Programming in this mode is all about saying exactly what you mean.
Posted in Design & Programming
July 10th, 2008 chris
White box testing is a strategy in which testing is based on the internal paths, structure, and implementation of the software under test (SUT). Unlike its complement, black box testing, white box testing generally requires detailed programming skills.
The general white box testing process is:
- The SUT’s implementation is analyzed.
- Paths through the SUT are identified.
- Inputs are chosen to cause the SUT to execute selected paths. This is called path sensitization. Expected results for those inputs are determined.
- The tests are run.
- Actual outputs are compared with the expected outputs.
- A determination is made as to the proper functioning of the SUT.
Posted in Software Testing
July 10th, 2008 chris
Black box testing is a strategy in which testing is based solely on the requirements and specifications. Unlike its complement, white box testing, black box testing requires no knowledge of the internal paths, structure, or implementation of the software under test (SUT).
The general black box testing process is:
- The requirements or specifications are analyzed.
- Valid inputs are chosen based on the specification to determine that the SUT processes them correctly. Invalid inputs must also be chosen to verify that the SUT detects them and handles them properly.
- Expected outputs for those inputs are determined.
- Tests are constructed with the selected inputs.
- The tests are run.
- Actual outputs are compared with the expected outputs.
- A determination is made as to the proper functioning of the SUT
Posted in Software Testing
July 10th, 2008 chris
Early views saw testing as a phase that occurred after software development, or “something that programmers did to get the bugs out of their programs.” The more modern view sees testing as a process to be performed in parallel with the software development or maintenance effort incorporating the activities of planning (determining risks and selecting strategies); analysis (setting test objectives and requirements); design (specifying tests to be developed); implementation (constructing or acquiring the test procedures and cases); execution (running and rerunning the tests); and maintenance (saving and updating the tests as the software changes).
This lifecycle perspective of testing represents a major change from just a few years ago, when many equated testing with executing tests. The contribution of planning, analyzing, and designing tests was under-recognized (and still is by many people), and testing was not seen as really starting until tests started running. Now we understand the evaluation power of test planning and analysis. These activities can be more powerful than test execution in defect prevention and timely detection. We also understand that an accurate interpretation of the situation when “all tests are running successfully” requires a clear understanding of the test design.
The lifecycle model for testing that has emerged borrows heavily from the methodology we’ve grown accustomed to for software. Considering that a test set is made up of data and procedures (which are often implemented as executable test programs), it should not come as a surprise that what it takes to build good software is also what it takes to build good testware!
Posted in Software Testing