Quality Assurance, Quality Control & Software Testing

Hi All,

Most of the people are confused with the difference between Testing, QA and QC Engineer. Below are the definitions showing difference between these three:-

Quality Assurance (QA): A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.

Quality Control (QC): A set of activities designed to evaluate a developed work product. These activities can always include the audits conducted by the QA team to assess the cost of correcting defects, documentation etc.

Testing: It is process of finding defects by executing a system/software. (Note that the "process of executing a system" includes test planning prior to the execution of the test cases.)

Quality Assurance (QA):

- QA is planned and systematic way to evaluate quality of process used to produce a quality product.

- The goal of a QA is to provide assurance that a product is meeting customer’s quality expectations.

- QA deals with how to prevent bugs from occurring in a product being developed.

- Software Quality Assurance Engineer’s main responsibility is to create and implement methods and standards to improve development process.


- QA is associated with activities like measuring the quality of process used to develop a product, process improvement and defect prevention.

- It consists of auditing and reporting procedures related to development and testing.

Quality Control (QC):

Quality control name comes from manufacturing industry where QC inspector evaluate sample products taken from the manufacturing line, test them & if the products fail the test they have the authority to shut down the whole production line.

- QC in software industry is evaluating software product, find the defects & suggest improvements.

- QC implements the process established by QA.

- Software tester is responsible for QC.

- If required, personnel involve in QC have to carry out QA tasks as well.

Software Testing :

- Software testing is a planned process that is used to identify the correctness, completeness, security and quality of software.

- Testing is generally done to demonstrate that the software is doing what it is supposed to do as well as the software is not doing what it is not supposed to do.

- The goal of testing or software tester is to locate defects and make sure that they get fixed.

These are the basic differences between the three concepts. Sometimes there is an overlap of duties between tester, QA Engineer and QC Engineer. As per the need, some testers might be required to perform certain QA activities & some QA-ers perform testing of product.

Testing Web Forms


Forms are the only way through which the user and the website can interact with each other. Unusable forms can have a negative impact on the number of leads and hence the profit that can be generated from a website.

A] Error Messages:

Any error message should communicate the following as best it can:

Where the errors are: An error response should mention for which input field the error is related to. When referring to an input, traditionally use the name of that input field which will be helpful for the user to understand easily.

How an error may be fixed: If the error is simply to let the user know they missed a required field. It’s always best to communicate what the solution might be. For example,  if a telephone number can’t accept alphabetic characters, then tell the user. If a user didn’t enter the date in the correct format, show them an example of what the correct format is.


B] Form must retain previous data entries:

When submitting a form with errors, rather than having to fill out the entire form again, leave the correct data in the form. If the form can’t retain previous data entry, then the users might get frustrated and not fill the form again.

C] Don’t use alert dialog boxes for validation responses:

Here are a few reasons why:

1. When an alert box is displayed, it must first be closed before returning to the form.
2. Once closed, the only way to view the error again is to re-submit the form. This gives the user no information to refer back to.
3. When using alert boxes and pop-up windows, it is common that only the first error found is displayed, rather than a full list of errors. The form is then re-submitted by the user multiple times to discover multiple different errors.

D] Field Validation:

Email Field:
Valid email format aa@bb.sg / aa@bb.co.uk (and similar).
First character should not be a special character.
Special characters allowed are _ . -
Alphanumeric characters should be allowed.
For email and confirm email id fields – No copy or paste function is allowed.

Name Field:
First name should be mandatory.
Only accepts alphabets.
Lead and trail space should be truncated.
Maximum and Minimum length should be tested (Depends on requirement).

Password Field:
Typing value should be encrypted.
Minimum and Maximum length should be validated (In general Min.6 and Max.12).
Copy and Paste functionality should not be allowed for Password and Confirm Password field.
For all instance Password field should be followed by Confirm Password field.

Drop down:
Default text should be “-Select-” or “-Select item-”
Should be enabled always (depends on spec).
Menu items should be sorted with respect to the requirement (alphabetical order by default).

Amount/ fees field:
Do not allow to use comma (,) and dot (.)

Mobile or Phone Number Field:
Alphabets should not be allowed
In special characters only hyphen (-) and plus (+) signs are allowed.

Public Forms:
Public forms such as registration form, comment form, mail to support form, etc. should have “Captcha” to submit. To overcome Auto-bot registration and spam,  it should be used.

Date of Birth Field:
Should mention the format of input (mm/dd/yy or mm/dd/yyyy or dd/mm/yy  etc.)
If accepting the value for date, month and year in separate field, only then numerals should be allowed. Otherwise if you use single text box to get data then mention the separator allowed along with the format text. For example: mm/dd/yy or  mm-dd-yyyy

Calendar Range:
Should clearly explain the date format (dd/mm/yy or dd/mm/yyyy or mm/dd/yy)
End date should not be greater than current date.

Performance & Security Testing Checklist


1.1 LOAD
    1.1.1 Many users requesting a certain page at the sametime or using the site simultaneously
    1.1.2 Increase the number of users and keep the dataconstant
    1.1.3 Does the home page load quickly? within 8 seconds
    1.1.4 Is load time appropriate to content, even on aslow dial-in connection?
    1.1.5 Can the site sustain long periods of usage bymultiple users?
    1.1.6 Can the site sustain long periods of continuoususage by 1 user?
    1.1.7 Is page loading performance acceptable over modemsof different speeds?
    1.1.8 Does the system meet its goals for response time,throughput, and availability?
    1.1.9 Have you defined standards for response time (i.e.all screens should paint within 10 seconds)?
    1.1.10 Does the system operate in the same way acrossdifferent computer and network configurations, platforms and environments, withdifferent mixes of other applications?

1.2 VOLUME
    1.2.1 Increase the data by having constant users
    1.2.2 Will the site allow for large orders withoutlocking out inventory if the transaction is invalid?
    1.2.3 Can the site sustain large transactions withoutcrashing?


1.3 STRESS
    1.3.1 Increase both number of users and the data
    1.3.2 Performance of memory, CPU, file handling etc.
    1.3.3 Error in software, hardware, memory errors(leakage, overwrite or pointers)
    1.3.4 Is the application or certain features going to beused only during certain periods of time or will it be used continuously 24hours a day 7 days a week? Test that the application is able toperform during those conditions. Will downtime be allowed or is that out of thequestion?
    1.3.5 Verify that the application is able to meet therequirements and does not run out of memory or disk space.

1.4 SECURITY
    1.4.1 Is confidentiality/user privacy protected?
    1.4.2 Does the site prompt for user name and password?
    1.4.3 Are there Digital Certificates, both at server andclient?
    1.4.4 Have you verified where encryption begins andends?
    1.4.5 Are concurrent log-ons permitted?
    1.4.6 Does the application include time-outs due toinactivity?
    1.4.7 Is bookmarking disabled on secure pages?
    1.4.8 Does the key/lock display on status bar forinsecure/secure pages?
    1.4.9 Is Right Click, View, Source disabled?
    1.4.10 Are you prevented from doing direct searches byediting content in the URL?
    1.4.11 If using Digital Certificates, test the browserCache by enrolling for the Certificate and completing all of the requiredsecurity information.

Usability Testing Check List

1.1 COLORS

    1.1.1 Are hyperlink colors standard?
    1.1.2 Are the field backgrounds the correct color?
    1.1.3 Are the field prompts the correct color?
    1.1.4 Are the screen and field colors adjusted correctlyfor non-editable mode?
    1.1.5 Does the site use (approximately) standard linkcolors?
    1.1.6 Are all the buttons are in standard format andsize?
    1.1.7 Is the general screen background the correctcolor?
    1.1.8 Is the page background (color) distraction free?

1.2 CONTENT

    1.2.1 All fonts to be the same
    1.2.2 Are all the screen prompts specified in thecorrect screen font?
    1.2.3 Does content remain if you need to go back to aprevious page, or if you move forward to another new page?
    1.2.4 Is all text properly aligned?
    1.2.5 Is the text in all fields specified in the correctscreen font?
    1.2.6 Is all the heading are left aligned
    1.2.7 Does the first letter of the second word appearsin lowercase? Eg:

1.3 IMAGES

    1.3.1 Are all graphics properly aligned?
    1.3.2 Are graphics being used the most efficient use offile size?
    1.3.3 Are graphics optimized for quick downloads?
    1.3.4 Assure that command buttons are all of similarsize and shape, and same font & font size.
    1.3.5 Banner style & size & display exact sameas existing windows
    1.3.6 Does text wrap properly around pictures/graphics?
    1.3.7 Is it visually consistent even without graphics?

1.4 INSTRUCTIONS

    1.4.1 Is all the error message text spelt correctly onthis screen?
    1.4.2 Is all the micro-help text(i.e tool tip) speltcorrectly on this screen?
    1.4.3 Microhelp text(i.e tool tip) for every enabledfield & button
    1.4.4 Progress messages on load of tabbed(activescreens) screens

1.5 NAVIGATION

    1.5.1 Are all disabled fields avoided in the TABsequence?
    1.5.2 Are all read-only fields avoided in the TABsequence?
    1.5.3 Can all screens accessible via buttons on thisscreen be accessed correctly?
    1.5.4 Does a scrollbar appear if required?
    1.5.5 Does the Tab Order specified on the screen go insequence from Top Left to bottom right? This is the default unless otherwisespecified.
    1.5.6 Is there a link to home on every single page?
    1.5.7 On open of tab focus will be on first editablefield
    1.5.8 When an error message occurs does the focus returnto the field in error when the user cancels it?

1.6 USABILITY

    1.6.1 Are all the field prompts spelt correctly?
    1.6.2 Are fonts too large or too small to read?
    1.6.3 Are names in command button & option box namesare not abbreviations.
    1.6.4 Assure that option boxes, option buttons, andcommand buttons are logically grouped together in                  clearly demarcated areas“Group Box”
    1.6.5 Can the typical user run the system withoutfrustration?
    1.6.6 Do pages print legibly without cutting off text?
    1.6.7 Does the site convey a clear sense of its intendedaudience?
    1.6.8 Does the site have a consistent, clearlyrecognizable “look-&-feel”?
    1.6.9 Does User cab Login Member Area with bothUserName/Email ID ?
    1.6.9 Does the site look good on 640 x 480, 600×800etc.?
    1.6.10 Does the system provide or facilitate customerservice? i.e. responsive, helpful, accurate?
    1.6.11 Is all terminology understandable for all of thesite’s intended users?

Negative Test Cases Examples

1. Embedded Single Quote – Most SQL based databasesystems have issues when users store information that contain a single quote(e.g. Gaurav’s car). For each screen that accepts alphanumeric data entry,try entering text that contains one or more single quotes.

2. Required Data Entry – Your functional specification should clearly indicate fields that require data entry on screens. Test each field on the screen that has been indicated as being required to ensure it forces you to enter data in the field.

3. Field Type Test – Your functional specification should clearly indicate fields that require specific data entry requirements(date fields, numeric fields, phone numbers, zip codes, etc). Test each field on the screen that has been indicated as having special types to ensure it forcesyou to enter data in the correct format based on the field type (numeric fieldsshould not allow alphabetic or special characters, date fields should require avalid date, etc)

4. Field Size Test – Your functional specification should clearly indicate the number of characters you can enter into a field(for example, the first name must be 50 or less characters). Write test cases to ensure that you can only enter the specified number of characters. Preventing the user from entering more characters than is allowed is more elegant than giving an error message after they have already entered too many characters.

5. Numeric Bounds Test – For numeric fields, it isimportant to test for lower and upper bounds. For example, if you are calculating interest charged to an account, you would never have a negative interest amount applied to an account that earns interest, therefore, youshould try testing it with a negative number. Likewise, if your functional specification requires that a field be in a specific range (e.g. from 10 to 50), you should try entering 9 or 51, it should fail with a graceful message.

6. Numeric Limits Test – Most database systems and programming languages allow numeric items to be identified as integers or long integers. Normally, an integer has a range of -32,767 to 32,767 and long integers can range from -2,147,483,648 to 2,147,483,647. For numeric data entrythat do not have specified bounds limits, work with these limits to ensure that it does not get an numeric overflow error.

7. Date Bounds Test – For date fields, it is important to test for lower and upper bounds. For example, if you are checking a birth date field, it is probably a good bet that the person’s birth date is no older than 150 years ago. Likewise, their birth date should not be a date inthe future.

8. Date Validity – For date fields, it is important toensure that invalid dates are not allowed (04/31/2007 is an invalid date). Yourtest cases should also check for leap years (every 4th and 400th year is a leapyear).

9. Web Session Testing – Many web applications rely onthe browser session to keep track of the person logged in, settings for theapplication, etc. Most screens in a web application are not designed to belaunched without first logging in. Create test cases to launch web pages withinthe application without first logging in. The web application should ensure ithas a valid logged in session before rendering pages within the application.

10. Performance Changes – As you release new versions of your product, you should have a set of performance tests that you run that identify the speed of your screens (screens that list information, screens that add/update/delete data, etc). Your test suite should include test cases that compare the prior release performance statistics to the current release. This can aid in identifying potential performance problems that will be manifested with code changes to the current release.