QA Focus Briefing Documents: Print All - Software
[ Home Page - Surveys - Documents - Presentations - Search ]
This page is for printing out briefing papers on software. Note that some of the internal links may not work.
This document gives high-level advice for people who develop software for use either internally within a project or for use externally as a project deliverable.
Each computer programming language has its own coding conventions. However there are a number of general points that you can follow to ensure that your code is well organised and can be easily understood by others. These guidelines are not in any way mandatory but attempt to formalise code so that reading, reusing and maintaining code is easier. Most coding standards are arbitrary but adopting some level of consistency will help create better software.
The key point to remember is that good QA practice involves deciding on and recording a number of factors with your programming team before the onset of your project. Having such a record will allow you to be consistent.
In order for programmers to use your software it is important that you include clear documentation. This documentation will take the form of internal and external documentation.
Naming conventions of files, procedures and variables etc. should be sensible and meaningful and agreed on before the projects starts. Use of capitalisation may vary in different programming languages but it is sensible to avoid names that differ only in case or look very similar. Also avoid names that conflict with standard library names.
There are a number of key points to remember when writing your code:
Standards are "documented agreements containing technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose" (ISO 1997). The aim of international standards is to encapsulate most appropriate current practice. The International Organization for Standardization (ISO) [1] is the head of all national standardisation bodies. The most relevant ISO standard for software code development is ISO 9000-3: 1997 (QA for the development, supply, installation and maintenance of computer software). For other relevant standards also check the Institute of Electrical and Electronics Engineers [2] and the American National Standards Institute [3].
At the start of development it may help to ask your team the following questions:
Further information on Software QA at Sticky Minds
<http://www.stickyminds.com/>
A Web form is not dissimilar in appearance and use to a paper form. It appears on a Web page and contains special elements called controls along with normal text and mark up. These controls can take the form of checkboxes, text boxes, radio buttons, menus, etc. Users generally fill in the form by entering text and selecting menu items and then submit the form for processing. The agent could be an email or Web server.
Web forms have a variety of uses and are a way to get specific pieces of information from the user. Web sites with forms have their own specific set of problems and need vigorous testing to ensure that they work.
Some of the key things to consider when designing your form are:
Making fields compulsory can cause problems. Occasionally a user may feel that the question you have asked is inappropriate in context or they just can't provide the information. You need to decide if the information needed is absolutely necessary. Users will be more likely to give information if you explain why the data that you're asking for is needed. It is acceptable to ask the user if they meant to leave out a piece of information and then accept their answer.
Validation of forms can be carried out either client side or by processing on the server. Client side validation requires the use of a scripting language like JavaScript and can be problematic if the user's browser disallows scripting. However server side validation can be more complicated to set up.
Sometimes the categories you offer in a drop down list do not match the answer that the user wants to give you. Sites from the USA often ask for states, which UK users cannot provide. If you want to use a drop down list make sure that your error messages are helpful rather than negative and allow users to select an 'other' option. If you have given a good selection of categories then you should rarely get users picking this.
Also consider if the categories you have provided are subjective enough. There may be issues over the terms used to refer to particular countries (for example if a land area is disputed. If you have to provide a long drop down list then it might be worth offering the common categories first. You could also try subdividing the categories into two-drop downs where the selection from the first dynamically creates the options in the second.
You may wish to have the user see a new page or sidebar when filling in a form. A new page may be easier to look at but can be annoying if it is perceived as a diversion or, even worse, an advertisement. It may also be prevented from opening by window blocking software available on newer browsers.
Users will often make typing or transcription errors when filling a form in. These errors can occur in any free text fields on the form.
Occasionally users will press the submit or send button either deliberately or inadvertently when only part-way through the form. Make sure that you have an appropriate error message for this and allow users to go back to the unfinished form. Users also often fill in part of a form and then click on the back button. They may be doing this to lose the data they have filled in, to check previous data or because they think they have finished. These activities suggest poor user interface design.
It is important to provide a helpful message on the submission screen explaining the form has been submitted successfully. You could also give replicate the details inputted for users to print out as hard copy.
Once you have created your Web form you need to test it thoroughly before release. There are a number of different free software products available that will help you with your testing. Tools such as Roboform [1] are freely available and can be used to store test data in and automatically fill in your forms with data.
When testing your form it is worth bearing in mind some problem areas:
It is desirable to minimise the time a Web site is unavailable. However it may be necessary to bring a Web server down in order to carry out essential maintenance. This document lists some areas to consider if you wish to minimum down time.
The key to any form of critical path situation is planning. Planning involves being sure about what needs to be done and being clear about how it can be done. Quality Assurance is vital at this stage and final 'quality' checking is often the last act before a site goes live or a new release is launched.
Advance preparation is vital if you want to minimise time your site downtime and avoid confusion when installing new releases.
This document provides 10 tips which can help to ensure that databases can be easily exported and manipulated with the minimum of difficulties.
Significant time can be saved by creating the structure in a simple desktop database (such as Microsoft Access) before finalising the design in one of the enterprise databases. The developer will be able to recognise simple faults and makes changes more rapidly than would be possible at a later date.
Unlike paper-based structures, databases do not require the storage of all fields in a single table. For large databases it is useful to split essential information into multiple tables. Before creating a database, ensure that the data has been normalised to avoid duplication.
The developer should avoid field names that are not instantly recognisable. Acronyms or internal references will confuse users and future developers who are not completely familiar with the database.
It is considered good practice to avoid exotic characters in file or field names. Exotic characters would include ampersands, percentages, asterisks, brackets and quotation marks. You should also avoid spaces in field and table names.
Remain consistent with data entry. If including title (Mr, Miss, etc.) include it for all records. Similarly, if you have established that house number and address belong in different fields, always split them.
Blank fields can cause problems when interpreting the data at a later date. Does it mean that you have no information, or you have forgotten to enter the information? If information is unavailable it is better to provide a standard response (e.g. unknown).
Date and time can be easily confused when exporting database fields in a text file. A date that reads '12/04/2003' can have two meanings, referring to April 12th or December th, 2003. To avoid ambiguity always enter and store dates with a four-digit century and times of day using the 24 hour clock. The ISO format (yyyy-mm-dd) is useful for absolute clarity, particularly when mixing databases at a later date.
Currency data types are designed for modern decimal currencies and can cause problems when handling old style currency systems, such as Britain's currency system prior to 1971 that divided currency into pounds, shillings and pence.
Care should be taken when using proprietary extensions, as their use will tie your database to a particular software package. Examples of proprietary extensions include the user interface and application-specific commands.
Commas, quotation marks and semi-colons are all used as methods of separating fields when databases are exported to a plain text file and subsequently re-imported into another database. When entering data into a database you should choose an alternative character that represents these characters.
This document provides top tips which can help to ensure that databases are created that can be easily exported and manipulated with the minimum of difficulties.
The majority of database performance issues are caused by un-normalised or partially normalised data. Normalisation is the technique used to simplify the design of a database in a way that removes redundant data and improves the efficiency of the database design. It consists of three levels (1st, 2nd and 3rd) normal forms that require the removal of duplicate information, removal of partial (when the value in a field is dependent on part of the primary key) and transitive (when the value in one non-key field is dependent on the value in another non-key field) dependencies.
About 70% of good SQL performance can be attributed to proper and efficient indexes. Indexes are used to provide fast and efficient access paths to data, to enforce uniqueness on column values, to contain primary key values, to cluster data, and to partition tables.
Indexes have many benefits, but they have disadvantages. Each index requires storage space and must be modified each time a new row is inserted or deleted, as well as each time a column value in the key is updated. You should ensure that indexes are only used when necessary. In many circumstances it may be more appropriate to modify the structure of an existing one? Use the EXPLAIN statement to find the access path chosen by the optimiser.
Ensure the query is structured correctly by rechecking the WHERE clause. Are the host variables defined correctly and are the predicates designed to use existing indexes?
Unnecessary data sorting can also have a detrimental impact upon processing speed. You should ensure that all sorts (ORDER BY, GROUP BY, UNION, UNION ALL, joins, DISTINCT) only refer to the necessary data.
When developing stored procedures (a series of SQL commands), use the SET NOCOUNT ON option at the start of your procedure. This will prevent the superfluous "row count" messages from being generated, and will improve performance by eliminating wasted network traffic.
Remove unnecessary JOINS and sub queries - Would the application be more efficient without the join or sub-query? Are simple or multiple queries more efficient?
Many problems can be encountered when connecting to an organisational database from home or anywhere outside the faculty. Many delays are caused by DNS lookup timeout. Check that the database server can resolve the IP address. If the intervening firewall uses NAT, then the IP address will match the firewall's interface closest to the database server. If you are troubleshooting the connection, gather more information using 'tcpdump' and examine the packet timings to determine where the delay is occurring.
Many performance issues are caused by the host application rather than the database itself. When identifying performance issues it is useful to perform an Internet search using application keywords to identify problematic combinations. For example, tests have found that the use of a MS Access database run from a NetWare server can dramatically increase the query time if the database is not stored in the drive root.
Though it is theoretically possible to use SQL (Structured Query Language) script files between databases, the range of implementations in desktop databases differ. This may cause significant delays. In practice code needs to be recreated altered to account for implementation differences.
A relational database is a set of structured data, organised according to a data model. When exporting data from one application to another, it is a simple process to export the data as an ASCII text file that will describe every field within a table. However, many problems can be encountered that will increase the amount of effort and time required to import the data. This paper describes specific quality-based techniques that should be used in the development process to minimise the difficulty encountered at a later date.
The key to continued access of a digital resource is documentation. This avoids the problems that arise when an administrator leaves the project and essential knowledge is lost. Before exporting data you should make a note of the table relationships and primary keys. This will allow the data to be recombined using the same structure in an alternative package. You should also identify specific requirements of each field. For example, the field size, import mask, validation rules, default value, indexing, etc.
Two problems relating to the database organisation can be avoided by the use of appropriate descriptors. The first is to understand the importance of table and field names when identifying information. A row of numbers has little meaning until we identify the context, i.e. payroll numbers, lottery numbers, etc. This will make it easier to interpret and recombine the data at a later date.
The second issue to consider when choosing fields names is the possibility that this data will become corrupt at a later date or will be misinterpreted by the application. This is caused when specific reserved characters used for distinguishing between field (commas, semi-colons, tabs, quotations, etc.), or system-illegal characters (ampersands, asterisks, hash, or other mathematical symbols) are used.
It is important to avoid such issues by restricting yourself to the English alphabet or numerical values, and avoiding other symbols.
When handling data from multiple databases it is good practice to standardise the responses so that they can be understood and manipulated more easily. This may involve a simple process of replacing all reference to one value with another (e.g. changing 1,2,3 to Mr, Mrs, Miss). In other circumstances you may need to write a query to split the postcode from the main address field.
You should also ensure that date and time are referenced correctly. These can be easily confused when exporting database fields in a text file. For example, a date that reads '12/04/2003' can be interpreted as April 12th or December 4th, 2003. To avoid ambiguity always enter and store dates with a four-digit century and times of day using the 24 hour clock. The ISO format (yyyy-mm-dd) is useful for absolute clarity, particularly when mixing databases at a later date.
Care should be taken when using proprietary extensions, as their use will tie your database to a particular software package. Unlike SQL commands, these application-specific elements cannot be exported to other applications without extensive work to convert or recreate the resource. Examples of proprietary extensions include the user interface and application-specific commands.
Performance and reliability are the principal criteria for selecting software. In most procurement exercises however, price is also a determining factor when comparing quotes from multiple vendors. Price comparisons do have a role, but usually not in terms of a simple comparison of purchase prices. Rather, price tends to arise when comparing "total cost of ownership" (TCO), which includes both the purchase price and ongoing costs for support (and licence renewal) over the real life span of the product. This document provides tips about selecting open source software.
Does the software have a good reputation for performance and reliability? Here, word of mouth reports from people whose opinion you trust is often key. Some open source software has a very good reputation in the industry, e.g. Apache Web server, GNU Compiler Collection (GCC), Linux, Samba, etc. You should be comparing "best of breed" open source software against its proprietary peers. Discussing your plans with someone with experience using open source software and an awareness of the packages you are proposing to use is vital.
Is there clear evidence of ongoing effort to develop the open source software you are considering? Has there been recent work to fix bugs and meet user needs? Active projects usually have regularly updated web pages and busy development email lists. They usually encourage the participation of those who use the software in its further development. If everything is quiet on the development front, it might be that work has been suspended or even stopped.
Choose software which implements open standards. Interoperability with other software is an important way of getting more from your investment. Good software does not reinvent the wheel, or force you to learn new languages or complex data formats.
Does the project have an active support community ready to answer your questions concerning deployment? Look at the project's mailing list archive, if available. If you post a message to the list and receive a reasonably prompt and helpful reply, this may be a sign that there is an active community of users out there ready to help. Good practice suggests that if you wish to avail yourself of such support, you should also be willing to provide support for other members of the community when you are able.
Third party commercial support is available from a diversity of companies, ranging from large corporations such as IBM and Sun Microsystems, to specialist open source organizations such as Red Hat and MySQL, to local firms and independent contractors. Commercial support is most commonly available for more widely used products or from specialist companies who will support any product within their particular specialism.
When was the last stable version of the software released? Virtually no software, proprietary or open source, is completely bug free. If there is an active development community, newly discovered bugs will be fixed and patches to the software or a new version will be released. For enterprise use, you need the most recent stable release of the software, be aware that there may have been many more recent releases in the unstable branch of development. There is, of course, always the option of fixing bugs yourself, since the source code of the software will be available to you. But that rather depends on your (or your team's) skill set and time commitments.
Open source projects usually follow the "release early and often" motto. While in development they may have very low version numbers. Typically a product needs to reach its 1.0 release prior to being considered for enterprise use. (This is not to say that many pre-"1.0" versions of software are not very good indeed, e.g. Mozilla's 0.8 release of its Firefox browser).
Open source software projects may lag behind in their documentation for end users, but they are typically very good with their development documentation. You should be able to trace a clear history of bug fixes, feature changes, etc. This may provide the best insight into whether the product, at its current point in development, is fit for your purposes.
Consider the skill set of yourself and your colleagues. Do you have the appropriate skills to deploy and maintain this software? If not, what training plan will you put in place to match your skills to the task? Remember, this is not simply true for open source software, but also for proprietary software. These training costs should be included when comparing TCOs for different products.
Arguably, open source software is as much about the license as it is about the development methodology. Read the licence. Well-known licenses such as the General Public License (GPL) and the Lesser General Public License (LGPL) have well defined conditions for your contribution of code to the ongoing development of the software or the incorporation of the code into other packages. If you are not familiar with these licenses or with the one used by the software you are considering, take the time to clarify conditions of use.
Many open source products are generalist and must be specialised before use. Generally speaking the more effort required to specialise a product, the greater is its generality. A more narrowly focused product will reduce the effort require to deploy it, but may lack flexibility. An example of the former is GNU Compiler Collection (GCC), and an example of the latter might be Evolution email client, which works well "out of the box" but is only suitable for the narrow range of tasks for which it was intended.
This document was written by Randy Metcalfe of OSS Watch. OSS Watch is the open source software advisory service for UK higher and further education. It provides neutral and authoritative guidance on free and open source software, and about related open standards.
The OSS Watch Web site ia available at http://www.oss-watch.ac.uk/.
[ Home Page - Surveys - Documents - Presentations - Search ]
Web page by Brian Kelly of UKOLN.
Last Modified 31-May-2005
Email comments to webmaster@ukoln.ac.uk