Program Testing is Never To Show the Absence of Bug!

September 14, 2010

Actually the complete quotes is:

“Program testing can be used to show the presence of bugs, but never to show their absence!”

Stated by the famous computer scientist, E. W. Dijkstra.  And yes, we know him from his famous Dijkstra Algorithm.

I think this statement is true. When we perform a software testing process, what we look for and find are the bugs. The bugs is almost always exists in software development. But to show that the bug is no longer in the software, that is  an impossible task practically.

Testing a program requires planning.

  • The planning to assigned the right people to do the job,
  • the planning of the procedures to finalised the testing process
  • managing the cost and time that is required to do the proper testing.

Some  cases are proposed to properly test the program, but it is not practical to find all the cases, and thus it is impossible to tell that the bug is absence.  The only conclusion that can be drawn is that the testing may have revealed  some bugs which  was found after exercising some test cases.

More Dijkstra’s quotes can be found here:

How software engineers work

February 3, 2010

Satish Mishra (1997). “Visual Modeling & Unified Modeling Language (UML) : Introduction to UML”. Rational Software Corporation.

Newton Laws for Software Engineers

December 14, 2008

Law 1: Every Software Engineer continues his state of chatting or forwarding mails unless he is assigned work by manager.

Law 2: The rate of change in the software is directly proportional to the payment received from client and takes place at the quick rate as when deadline force is applied.

Law 3: For every Use Case Manifestation there is an equal but opposite Software Implementation


PS 1:

  • excerpt from
  • Original Newtons’ Law:

Law 1: Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it.

Law 2: The rate of change of velocity of a body is directly proportional to the
applied force & takes place in the same direction in which force is applied.

Law 3: For every action there is an equal and opposite reaction.

Software Engineering Journals and Proceedings

November 29, 2008

ACM journals and proceedings

ACM proceedings Read the rest of this entry »

Easy Statistics Book – a recommendation

November 21, 2008

uMost of statistics books are boring for regular people who want to learn statistics. Most of the books teach the basic, and how to get to the formula. I don’t say that they are bad, but most people need statistics just to analyze their data, some people might just want to know what a statistic is. Learning how the formula in statistics might not be necessary for most folks.

We recommend the books below to read. The books can be used for a starter, or somebody who have learned the statistics and wants to refresh their knowledge.

So here are the list of simple and easy to understand statistics:

  • Statistics for People who (think they) hate statistics, by Neil J. Salkind
    • This book teaches most statistics terms in an easy way.
  • Statistics for Dummies, by Deborah Rumsey (2003)
    • This book ask the reader to see how people spread the statistics word in the media, and how  to interpret them. The book doesn’t teach how a formula was generated, but how the a formula should be used.

10 Classic Software Engineering Books

November 17, 2008

We propose that these books below has been judged over a period of time to be of the highest quality. The author of these books has put fundamental ideas towards a better software engineering tools, method and methodologies. These books has been an influential for new software engineering ideas.

  1. Structured Programming by O.J. Dahl, E.W. Dijkstra, C.A.R. Hoare, Academic Press  (1972).
  2. The Mythical Man Month: Essays on Software Engineering by Frederick P. Brooks, Jr (1975)
  3. Software Engineering Economics by Barry Boehm,  Prentice-Hall, (1981).
  4. Software Engineering: A Practitioner’s Approach by Roger S. Pressman,  McGraw Hill (1988) – sixth edition now (2005)
  5. Managing the Software Process structured System by Watts S. Humphrey:, Addison-Wesley, Reading Mass., (1989).
  6. Object-Oriented Software Construction (2nd Edition) by Bertrand Meyer,
  7. Software Engineering by Ian Sommerville,  Pearson Education (Addison Wesley), 2001- 8th Edition now (2006)
  8. Design Patterns by Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley (1995).
  9. The Unified Modeling Language Reference Manual, by James Rumbaugh, Ivar Jacobson, Grady Booch, Addison-Wesley (1999).
  10. Component Software – beyond object-oriented programming by Clemens Szypersky, Addison-Wesley, (1997).

The books have been listed sorted by their first published year.

How to Evaluate Programmers

November 16, 2008

A matrix is proposed to evaluate the programmer’s compentency by Sijin Joseph, and it is posted in The matrix, that is called Programmer Competency Matrix, helps in determining the skill levels of a programmer. It actually examine the skill in the areas of Computer Science, Software Engineering, Programming, Experience and Knowledge. For each areas, there specific categories as follows:

  • Computer Science
    • Data Structures
    • Algorithms
    • System Programming
  • Software Engineering
    • Source Code
    • Build Automation
    • Automated Testing
  • Programming
    • Problem Decomposition
    • System Decomposition
    • Communication
    • code organization within a file
    • code organization across files
    • source tree organization
    • code readability
    • defensive coding
    • error handling
    • IDE
    • API
    • Frameworks
    • Requirements
    • Scripting
    • Database
  • Experience
    • Languages with personal experience
    • platforms with professional experience
    • years of professional experience
    • domain knowledge
  • Knowledge
    • tool knowledge
    • languages exposed to
    • codebase knowledge
    • knowledge of upcoming technologies
    • platform internals
    • books
    • blogs

For each categories, Sijin Joseph classifieds further into level 0, 1, 2, and 3. Level 3 is the highest level.

This is an interesting proposal to find the programmers competency, however the writer also realized that the matrix is more biased towards non-visual programmers. Therefore the current web developers might not be suitable to use this matrix. However SERLAB thinks that  the web developers are still able to use this matrix because the matrix has associated with some basic knowledge for good programmers.

Details of the matrix can be found here Programmer Competency Matrix.

Software Product Metrics

November 13, 2008

Software products are source code programs, and their documentations. Therefore software product metrics are measurements taken from an actual body of source code or their documentations. An example of a product metric is the size of a piece of software, typically expressed as lines of code. The documentation can be a requirement documents or design documents. A UML diagram is an example of software product that documents the application specification.

Product metrics can be viewed as being either internal attributes or external attributes. Some examples of product metrics are as follows:

  • Lines of Code
  • Function Point
  • Halstead Metrics
  • Complexity Metrics
      • McCabe’s Cyclomatic Metrics
      • Hope and Sherif’s Relative Complexity Metrics
      • Henri Kafura’s Information Flow

Some researchers categorized the Lines of Code, or Halstead Metrics are actually the complexity metrics.

Resource Metrics

November 13, 2008

The resources available to be measured include the people, materials, software tools and hardware tools. Resources are measured to define their size, cost and quality. For example we need to know the number of people who should be employed in a process, the cost to finish a process and the quality of the team.

Some examples of resource metrics are:

  • Hours of programmer time available and spent per week
  • The years of experience of the programmers
  • The price of software tools
  • The memory size required for a process

Process Metrics

November 12, 2008

Process metrics are collected over periods of time. The main intention is to improve the software process, so that a developer can assess the status of the process, the risks involved, identify potential problems, adjust the work schedule and evaluate the project team. These metrics are collected during the running of the software project. This metric data is analyzed and compared with historical metric data. Then assessment is done to determine whether there is an improvement in the process. The following are some examples of process metrics:

  • Rate of Requirements Changes
  • Rate of Program Errors
  • Rate of software fault introduction
  • Rate of software failure
  • Number of pending trouble reports
  • Measures of developer productivity
  • Cost information
  • Software process improvement (SPI) costs
  • Return on investment (ROI)
  • Number of errors introduced per developer hour

A methodology called the Capability Maturity Model Integration (CMMI) developed by the Software Engineering Institute of Carnegie Mellon University has focused on processes’ monitoring and controlling a software development process. Another standard defined by ISO, ISO/IEC 15504, offers a standard for a process assessment framework. This standard includes the management of planning, monitoring, controlling and improving products and services.