Custom Search

Thursday, April 23, 2009

What is Traceability Matrix from Software Testing perspective?


The concept of Traceability Matrix is very important from the Testing perspective. It is document which maps requirements with test cases. By preparing Traceability matrix, we can ensure that we have covered all the required functionalities of the application in our test cases.



What is Traceability Matrix from Software Testing perspective?


The concept of Traceability Matrix is very important from the Testing perspective. It is document which maps requirements with test cases. By preparing Traceability matrix, we can ensure that we have covered all the required functionalities of the application in our test cases. Some of the features of the traceability matrix:
It is a method for tracing each requirement from its point of origin, through each development phase and work product, to the delivered product


Can indicate through identifiers where the requirement is originated, specified, created, tested, and delivered Will indicate for each work product the requirement(s) this work product satisfies


Facilitates communications, helping customer relationship management and commitment negotiation


Traceability matrix is the answer of the following basic questions of any Software Project:
How is it possible to ensure, for each phase of the lifecycle, that I have correctly accounted for all the customer’s needs?
How can I ensure that the final software product will meet the customer’s needs? For example I have a functionality which checks if I put invalid password in the password field the application throws an error message “Invalid password”. Now we can only make sure this requirement is captured in the test case by traceability matrix.


Some more challenges we can overcome by Traceability matrix:
Demonstrate to the customer that the requested contents have been developed
Ensure that all requirements are correct and included in the test plan and the test cases
Ensure that developers are not creating features that no one has requested
The system that is built may not have the necessary functionality to meet the customers and users needs and expectations. How to identify the missing parts?
If there are modifications in the design specifications, there is no means of tracking the changes
If there is no mapping of test cases to the requirements, it may result in missing a major defect in the system
The completed system may have “Extra” functionality that may have not been specified in the design specification, resulting in wastage of manpower, time and effort.
If the code component that constitutes the customer’s high priority requirements is not known, then the areas that need to be worked first may not be known thereby decreasing the chances of shipping a useful product on schedule
A seemingly simple request might involve changes to several parts of the system and if proper Traceability process is not followed, the evaluation of the work that may be needed to satisfy the request may not be correctly evaluated


Step by step process of creating a Traceability Matrix from requirements:



step1: Identify all the testable requirements in granular level from various requirement specification documents. These documents vary from project to project. Typical requirements you need to capture are as follows:Used cases (all the flows are captured)Error MessagesBusiness rulesFunctional rulesSRSFRSSo on…
example requirements: login functionality, generate report, update something etc.



step2: In every project you must be creating test-cases to test the functionality as defined by the requirements. In this case you want to extend the traceability to those test-cases. In the example table below the test-cases are identified with a TC_ prefix.Put all those requirements in the top row of a spreadsheet. And use the right hand column of the spreadsheet to jot down all the test cases you have written for that particular requirement. In most of the cases you will have multiple test cases you have written to test one requirement. See the sample spreadsheet below:


Sample traceability matrix


step3: Put cross against each of the test case to each requirement if that particular test case is checking that particular requirement partially or completely. In the above table you can see REQ1 UC1.1 is checked by three test cases. (TC1.1.1, TC1.1.3, TC1.1.5).
Another example of traceability matrix where requirement documents (use case) are mapped back to the test cases.

Database Testing: Five Key Elements

Programs that interact with databases have common elements, and testing each requires a different approach. These elements include
1. Mapping application layer interactions
2. Mapping the data layer interactions
3. Functional interactions between the application and database
4. Embedded code
5. Database Migration


Mapping application layer interactions are often more easily handled through the normal segregation unit testing techniques; mapped objects can often be replaced by stubs. When testing larger subsystems, databases stubs may be useful, although the existence of integrated databases and in memory databases reduces the need for them.

Mapping the data layer interactions often benefit from using a real database of any kind. Differences in behavior between different types of target databases can be identified or verified prior to integration. Run of cases, this needs to be available to each developer. These days, a multi-processor desktop has more than enough power to run multiple virtual machines hosting "real" databases such as Oracle, Microsoft SQL Server or Sybase. For the consistency check of the base mapping layer, which is usually sufficient to use something like SQLite.
No development work should never be done against the production database. This is a recipe for disaster. Mistakes can easily destroy data production successfully withdraw amendments to the database from a known state, which has the potential of automation to the ruine. If a problem can not be replicated in the development or quality assurance, which suggests that something is wrong with the development and quality assurance resources.

Functional interactions between the application and the database are processed using real databases. As mentioned earlier, VM is useful for this. Indeed, I know that several organizations in which a reduced version of the entire production network runs on every PC developer. In the coming years, we can expect this kind of comprehensive simulation environment to become more frequent.

Embedded code refers to code that runs in the database. Triggers and stored procedures are most commonly used types of embedded code. The only way to test this code with a database directly.

Database migration must be tested against the target databases. Migration should be tested against both the patterns and realistic data sets.

Wednesday, April 15, 2009

SQL Introduction


What is SQL?
SQL stands for Structured Query Language
SQL lets you access and manipulate databases
SQL is an ANSI (American National Standards Institute) standard

What Can SQL do?
SQL can execute queries against a database
SQL can retrieve data from a database
SQL can insert records in a database
SQL can update records in a database
SQL can delete records from a database
SQL can create new databases
SQL can create new tables in a database
SQL can create stored procedures in a database
SQL can create views in a database
SQL can set permissions on tables, procedures, and views

SQL is a Standard - BUT....
Although SQL is an ANSI (American National Standards Institute) standard, there are many different versions of the SQL language.
However, to be compliant with the ANSI standard, they all support at least the major commands (such as SELECT, UPDATE, DELETE, INSERT, WHERE) in a similar manner.
Note: Most of the SQL database programs also have their own proprietary extensions in addition to the SQL standard!

Using SQL in Your Web Site
To build a web site that shows some data from a database, you will need the following:
An RDBMS database program (i.e. MS Access, SQL Server, MySQL)
A server-side scripting language, like PHP or ASP
SQL
HTML / CSS
RDBMS

RDBMS stands for Relational Database Management System.
RDBMS is the basis for SQL, and for all modern database systems like MS SQL Server, IBM DB2, Oracle, MySQL, and Microsoft Access.
The data in RDBMS is stored in database objects called tables.
A table is a collections of related data entries and it consists of columns and rows.

Tuesday, April 14, 2009

Test Director Interview Questions ...

1.What is Test Director?
Its a Mercury interactive's Test management tool. It includes all the features we need to organize and manage the testing process.

2.What are all the main features of Test Director?
It enables us to create a database of tests,execute tests, report and track defects detected in the software.

3.How the assessment of the application will be taken place in Test Director?
As we test, Test Director allows us to continuously assess the status of our application by generating sophisticated reports and graphs. By integrating all tasks involved in software testing Test Director helps us to ensure that our software is ready for deployment.

4.What the planning tests will do in Test Director?
It is used to develop a test plan and create tests. This includes defining goals and strategy,designing tests,automating tests where beneficial and analyzing the plan.

5.What the running tests will do in Test Director?
It execute the test created in the planning test phase, and analyze the test results

6.What the tracking defects will do in Test Director?
It is used to monitor the software quality. It includes reporting defects,determining repair priorities,assigning tasks,and tracking repair progress

7.What are all the three main views available in What the running tests will do in Test Director?? Plan tests? Run tests?
Track defectsEach view includes all the tools we need to complete each phase of the testing process

8.What is test plan tree?
A test plan tree enables you to organize and display your test hierarchically,according to your testing requirements

9.What are all the contents of test plan tree?
Test plan tree can include several type of tests.
Manual test scripts Win Runner test scripts. Batch of Win Runner test scripts. Visual API test scripts. Load Runner scenario scripts and Vuser scripts

10.What is test step?
A test step includes the action to perform in our application,input to enter,and its expected output

Wednesday, March 11, 2009

GUI Testing Standards

Section 1 - Windows Compliance Standards
1.1. Application

1.2. For Each Window in the Application
1.3. Text Boxes
1.4. Option (Radio Buttons)
1.5. Check Boxes
1.6. Command Buttons
1.7. Drop Down List Boxes
1.8. Combo Boxes
1.9. List Boxes

Section 2 - Tester's Screen Validation Checklist
2.1. Aesthetic Conditions
2.2. Validation Conditions
2.3. Navigation Conditions
2.4. Usability Conditions
2.5. Data Integrity Conditions
2.6. Modes (Editable Read-only) Conditions
2.7. General Conditions
2.8. Specific Field Tests
2.8.1. Date Field Checks
2.8.2. Numeric Fields
2.8.3. Alpha Field Checks

Section 3 - Validation Testing - Standard Actions
3.1. On every Screen
3.2. Shortcut keys / Hot Keys
3.3. Control Shortcut Keys
1. Windows Compliance -->
Windows Compliance Testing
For Each Application

Start Application by Double Clicking on its ICON
The Loading message should show the application name, version number, and a bigger pictorial representation of the icon.
No Login is necessary
The main window of the application should have the same captionas the caption of the icon in Program Manager.
Closing the application should result in an "Are you Sure" message box
Attempt to start application Twice
This should not be allowed - you should be returned to main Window
Try to start the application twice as it is loading.
On each window, if the application is busy, then the hour glass shouldbe displayed. If there is no hour glass (e.g. alpha access enquiries)then some enquiry in progress message should be displayed.
All screens should have a Help button, F1 should work doing the same.
For Each Window in the Application
If Window has a Minimize Button, click it.
Window Should return to an icon on the bottom of the screen
This icon should correspond to the Original Icon under Program Manager.
Double Click the Icon to return the Window to its original size.
The window caption for every application should have the name of theapplication and the window name - especially the error messages.
These should be checked for spelling, English and clarity , especiallyon the top of the screen. Check does the title of the window makes sense.
If the screen has an Control menu, then use all ungreyed options. (see below)


Check all text on window for Spelling/Tense and Grammar.
Use TAB to move focus around the Window. Use SHIFT+TAB tomove focus backwards.
Tab order should be left to right, and Up to Down within a group box on the screen.
All controls should get focus - indicated by dotted box, or cursor. Tabbing to an entry field with text in it should highlight the entire text in the field.
The text in the Micro Help line should change - Check for spelling, clarityand non-updateable etc.
If a field is disabled (greyed) then it should not get focus. It should not be possible to select them with either the mouse or by using TAB. Try this for every greyed control.
Never updateable fields should be displayed with black text on a grey background with a black label.
All text should be left-justified, followed by a colon tight to it.
In a field that may or may not be updateable, the label text and contents changes from black to grey depending on the current status.
List boxes are always white background with black text whether they are disabled or not. All others are grey.
In general, do not use goto screens, use gosub, i.e. if a button causes another screen to be displayed, the screen should not hide the first screen, with the exception of tab in 2.0
When returning return to the first screen cleanly i.e. no other screens/applications should appear.
In general, double-clicking is not essential. In general, everything can be done using both the mouse and the keyboard.
All tab buttons should have a distinct letter.
Text Boxes

Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar. If it doesn't then the text in the box should be grey or non-updateable. Refer to previous page.
Enter text into Box
Try to overflow the text by typing to many characters - should be stopped Check the field width with capitals W.
Enter invalid characters - Letters in amount fields, try strange characters like + , - * etc. in All fields.
SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box.
Option (Radio Buttons)
Left and Right arrows should move 'ON' Selection. So should Up and Down.. Select with mouse by clicking.
Check Boxes
Clicking with the mouse on the box, or on the text should SET/UNSET the box. SPACE should do the same

Command Buttons

If Command Button leads to another Screen, and if the user can enter or change details on the other screen then the Text on the button should be followed by three dots.
All Buttons except for OK and Cancel should have a letter Access to them. This is indicated by a letter underlined in the button text. The button should be activated by pressing ALT+Letter. Make sure there is no duplication.
Click each button once with the mouse - This should activate
Tab to each button - Press SPACE - This should activate
Tab to each button - Press RETURN - This should activate
The above are VERY IMPORTANT, and should be done for EVERY command Button.
Tab to another type of control (not a command button). One button on the screen should be default (indicated by a thick black border). Pressing Return in ANY no command button control should activate it.
If there is a Cancel Button on the screen , then pressing should activate it.
If pressing the Command button results in uncorrectable data e.g. closing an action step, there should be a message phrased positively with Yes/No answers where Yes results in the completion of the action.
Drop Down List Boxes
Pressing the Arrow should give list of options. This List may be scrollable. You should not be able to type text in the box.
Pressing a letter should bring you to the first item in the list with that start with that letter. Pressing ‘Ctrl - F4’ should open/drop down the list box.
Spacing should be compatible with the existing windows spacing (word etc.). Items should be in alphabetical order with the exception of blank/none which is at the top or the bottom of the list box.
Drop down with the item selected should be display the list with the selected item on the top.
Make sure only one space appears, shouldn't have a blank line at the bottom.

Combo Boxes

Should allow text to be entered. Clicking Arrow should allow user to choose from list
List Boxes

Should allow a single selection to be chosen, by clicking with the mouse, or using the Up and Down Arrow keys.
Pressing a letter should take you to the first item in the list starting with that letter.
If there is a 'View' or 'Open' button beside the list box then double clicking on a line in the List Box, should act in the same way as selecting and item in the list box, then clicking the command button.
Force the scroll bar to appear, make sure all the data can be seen in the box.
2. Screen Validation Checklist
Aesthetic Conditions:

1. Is the general screen background the correct color?.
2. Are the field prompts the correct color?
3. Are the field backgrounds the correct color?
4. In read-only mode, are the field prompts the correct color?
5. In read-only mode, are the field backgrounds the correct color?
6. Are all the screen prompts specified in the correct screen font?
7. Is the text in all fields specified in the correct screen font?
8. Are all the field prompts aligned perfectly on the screen?
9. Are all the field edit boxes aligned perfectly on the screen?
10. Are all groupboxes aligned correctly on the screen?
11. Should the screen be resizable?
12. Should the screen be minimisable?
13. Are all the field prompts spelt correctly?
14. Are all character or alpha-numeric fields left justified? This is the default unless otherwise specified.
15. Are all numeric fields right justified? This is the default unless otherwise specified.
16. Is all the microhelp text spelt correctly on this screen?
17. Is all the error message text spelt correctly on this screen?
18. Is all user input captured in UPPER case or lower case consistently?
19. Where the database requires a value (other than null) then this should be defaulted into fields. The user must either enter an alternative valid value or leave the default value intact.
20. Assure that all windows have a consistent look and feel.
21. Assure that all dialog boxes have a consistent look and feel.
Validation Conditions:

1. Does a failure of validation on every field cause a sensible user error message?
2. Is the user required to fix entries which have failed validation tests?
3. Have any fields got multiple validation rules and if so are all rules being applied?
4. If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message.?
5. Is validation consistently applied at screen level unless specifically required at field level?
6. For all numeric fields check whether negative numbers can and should be able to be entered.
7. For all numeric fields check the minimum and maximum values and also some mid-range values allowable?
8. For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?
9. Do all mandatory fields require user input?
10. If any of the database columns don’t allow null values then the corresponding screen fields must be mandatory. (If any field which initially was mandatory has become optional then check whether null values are allowed in this field.)

Navigation Conditions:
1. Can the screen be accessed correctly from the menu?
2. Can the screen be accessed correctly from the toolbar?
3. Can the screen be accessed correctly by double clicking on a list control on the previous screen?
4. Can all screens accessible via buttons on this screen be accessed correctly?
5. Can all screens accessible by double clicking on a list control be accessed correctly?
6. Is the screen modal. i.e. Is the user prevented from accessing other functions when this screen is active and is this correct?
7. Can a number of instances of this screen be opened at the same time and is this correct?
Usability Conditions:
1. Are all the dropdowns on this screen sorted correctly? Alphabetic sorting is the default unless otherwise specified.
2. Is all date entry required in the correct format?
3. Have all pushbuttons on the screen been given appropriate Shortcut keys?
4. Do the Shortcut keys work correctly?
5. Have the menu options which apply to your screen got fast keys associated and should they have? 6. Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
7. Are all read-only fields avoided in the TAB sequence?
8. Are all disabled fields avoided in the TAB sequence?
9. Can the cursor be placed in the microhelp text box by clicking on the text box with the mouse?
10. Can the cursor be placed in read-only fields by clicking in the field with the mouse?
11. Is the cursor positioned in the first input field or control when the screen is opened?
12. Is there a default button specified on the screen?
13. Does the default button work correctly?
14. When an error message occurs does the focus return to the field in error when the user cancels it?
15. When the user Alt+Tab’s to another application does this have any impact on the screen upon return to The application?
16. Do all the fields edit boxes indicate the number of characters they will hold by there length? e.g. a 30 character field should be a lot longer
Data Integrity Conditions:
1. Is the data saved when the window is closed by double clicking on the close box?
2. Check the maximum field lengths to ensure that there are no truncated characters?
3. Where the database requires a value (other than null) then this should be defaulted into fields. The user must either enter an alternative valid value or leave the default value intact.
4. Check maximum and minimum field values for numeric fields?
5. If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?
6. If a set of radio buttons represent a fixed set of values such as A, B and C then what happens if a blank value is retrieved from the database? (In some situations rows can be created on the database by other functions which are not screen based and thus the required initial values can be incorrect.)
7. If a particular set of data is saved to the database check that each value gets saved fully to the database. i.e. Beware of truncation (of strings) and rounding of numeric values.
Modes (Editable Read-only) Conditions:
1. Are the screen and field colors adjusted correctly for read-only mode?
2. Should a read-only mode be provided for this screen?
3. Are all fields and controls disabled in read-only mode?
4. Can the screen be accessed from the previous screen/menu/toolbar in read-only mode?
5. Can all screens available from this screen be accessed in read-only mode?
6. Check that no validation is performed in read-only mode.
General Conditions:
1. Assure the existence of the "Help" menu.
2. Assure that the proper commands and options are in each menu.
3. Assure that all buttons on all tool bars have a corresponding key commands.
4. Assure that each menu command has an alternative(hot-key) key sequence which will invoke it where appropriate.
5. In drop down list boxes, ensure that the names are not abbreviations / cut short
6. In drop down list boxes, assure that the list and each entry in the list can be accessed via appropriate key / hot key combinations.
7. Ensure that duplicate hot keys do not exist on each screen
8. Ensure the proper usage of the escape key (which is to undo any changes that have been made) and generates a caution message "Changes will be lost - Continue yes/no"
9. Assure that the cancel button functions the same as the escape key.
10. Assure that the Cancel button operates as a Close button when changes have be made that cannot be undone.
11. Assure that only command buttons which are used by a particular window, or in a particular dialog box, are present. - i.e make sure they don't work on the screen behind the current screen.
12. When a command button is used sometimes and not at other times, assure that it is grayed out when it should not be used.
13. Assure that OK and Cancel buttons are grouped separately from other command buttons.
14. Assure that command button names are not abbreviations.
15. Assure that all field labels/names are not technical labels, but rather are names meaningful to system users.
16. Assure that command buttons are all of similar size and shape, and same font & font size.
17. Assure that each command button can be accessed via a hot key combination.
18. Assure that command buttons in the same window/dialog box do not have duplicate hot keys.
19. Assure that each window/dialog box has a clearly marked default value (command button, or other object) which is invoked when the Enter key is pressed - and NOT the Cancel or Close button
20. Assure that focus is set to an object/button which makes sense according to the function of the window/dialog box .
21. Assure that all option buttons (and radio buttons) namesare not abbreviations.
22. Assure that option button names are not technical labels, but rather are names meaningful to system users.
23. If hot keys are used to access option buttons, assure that duplicate hot keys do not exist in the same window/dialog box.
24. Assure that option box names are not abbreviations.
25. Assure that option boxes, option buttons, and commandbuttons are logically grouped together in clearly demarcated areas "Group Box"
26. Assure that the Tab key sequence which traverses thescreens does so in a logical way.
27. Assure consistency of mouse actions across windows.
28. Assure that the color red is not used to highlight active objects (many individuals are red-green color blind).
29. Assure that the user will have control of the desktop withrespect to general color and highlighting (the application should notdictate the desktop background characteristics).
30. Assure that the screen/window does not have a cluttered appearance
31. Ctrl + F6 opens next tab within tabbed window
32. Shift + Ctrl + F6 opens previous tab within tabbed window
33. Tabbing will open next tab within tabbed window if on last field of current tab
34. Tabbing will go onto the 'Continue' button if on last field of last tab within tabbed window.
35. Tabbing will go onto the next editable field in the window
36. Banner style & size & display exact same as existing windows
37. If 8 or less options in a list box, display all options on open of list box - should be no need to scroll
38. Errors on continue will cause user to be returned to the tab and the focus should be on the field causing the error. (i.e the tab is opened, highlighting the field with the error on it)
39. Pressing continue while on the first tab of a tabbed window (assuming all fields filled correctly) will not open all the tabs.
40. On open of tab focus will be on first editable field
41. All fonts to be the same
42. Alt+F4 will close the tabbed window and return you to main screen or previous screen (as appropriate), generating"changes will be lost" message if necessary.
43. Microhelp text for every enabled field & button
44. Ensure all fields are disabled in read-only mode
45. Progress messages on load of tabbed screens
46. Return operates continue
47. If retrieve on load of tabbed window fails window should not open
Specific Field Tests
Date Field Checks
Assure that leap years are validated correctly & do not cause errors/miscalculations

Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations

Assure that 00 and 13 are reported as errors
Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations
Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations
Assure that Feb. 30 is reported as an error
Assure that century change is validated correctly & does not cause errors/ miscalculations
Assure that out of cycle dates are validated correctly & do not cause errors/miscalculations
Numeric Fields
Assure that lowest and highest values are handled correctly
Assure that invalid values are logged and reported
Assure that valid values are handles by the correct procedure
Assure that numeric fields with a blank in position 1 are processed or reported as an error
Assure that fields with a blank in the last position are processed or reported as an error an error
Assure that both + and - values are correctly processed
Assure that division by zero does not occur
Include value zero in all calculations
Include at least one in-range value
Include maximum and minimum range values
Include out of range values above the maximum and below the minimum
Assure that upper and lower values in ranges are handled correctly
Alpha Field Checks
Use blank and non-blank data
Include lowest and highest values
Include invalid characters & symbols
Include valid characters
Include data items with first position blank
Include data items with last position blank
Validation Testing - Standard Actions On every Screen
Add
View
Change
Delete
Continue
Add
View
Change
Delete
Cancel
Fill each field - Valid data
Fill each field - Invalid data
Different Check Box combinations
Scroll Lists
Help
Fill Lists and Scroll
Tab
Tab Order
Shift Tab
Shortcut keys - Alt + F