techiehenry

This is the seventh part in a mini-series here in this blog.

Now that everything has been checked with regards to how each unit would work with each other, it would be time to test the application as the client would see it.

7. Test the target as a whole

   We are now into the final testing before the product reaches the client’s hands.

   Just like other testing procedures done in the previous steps, this is still based on a set criteria. We will now base our testing on the checklist we made during the first step — when we were trying to determine what the client wants us to develop for them.

   However, there are still other points to consider when testing the software, which is listed below:

   1. Stability of the software

      Stability here would denote that the software could run under varying loads with the least downtime possible. However this doesn’t mean that the software should be bug-free, as there isn’t really any such thing. What is important is that if ever an unknown error occurs, the application should be smart enough to close ‘graceully’. Open files should be closed, temporary files deleted, etc. This is important, since data could be lost once the application suddenly stalls or quits when the user is in the middle of an operation. Error handling methods are the ones on check for this part.

   2. Consistency of the user interface

      Are the OK and Cancel buttons of the same size? Are the text of the same type? Are the shortcut keys following the standard for a particular platform’s GUI? Are the icon size consistent throughout the application? How do the toolbar buttons react when clicked on? Does the mouse change its appearance when it hovers on text that is editable? Are all the text boxes properly aligned? You get the point.

   3. Size of the final application

      This is particularly important if you develop embedded applications. Since most devices don’t really have the processing power, memory, nor the storage space of a regular computer, some parts of the code may need to be modified to reduce its final binary size.

   4. Speed at how the application does its intended purpose

      I guess you wouldn’t want your users to stare at an hourglass icon till kingdom come, waiting for a sort or a search to finish. Profilers may help for this case. You can time each loop, each function, or each operation, then modify the code to weed out performance bottlenecks.

That will be all there is for this step. Again if you have comments or questions, please leave a comment so that we can clarify things. Keep visiting this site for more updates on the series.

Software Development Series: Part 1 Part 2 Part 3 Part 4 Part 5 Part 6