Software Testing

2012-03-17T21:35:00.002-07:00

Software Testing Reference

QTP

Sample BRS Document

Sample SRS Document

Software Test Metrics

SQL for Testers

SQL Queries Examples

SQL and PL / SQL Interview Questions-I

SQL and PL / SQL Interview Questions-II

SQL and PL / SQL Interview Questions-III

Test case writing

Testing Interview questions

Software Test Documents

Configuration Management

Software Testing Guide

Unit Testing

Selenium tool

Test Management

Manual Testing Questions & Answers Part-II

Manual Testing Questions and Answers Part-I

Software Test Methods

Requirement Management Tools

Requirements Management

Rational Robot

An Introduction to Quality Center

Web Testing

An Introduction to LoadRunner

Performance Testing

Usability Testing

CMM Levels Vs ISO Standards

Agile methodology

Test Design Techniques

ISTQB Certification Model questions

Test plan

Performance Test Plan

Use Case template

web dictionary

Static Testing

Web testing guidelines

Database tutorial

Certification Model questions

Software Quality Standards

ISTQB Certification Guidelines

Database Testing

Quality Assurance

Software Testing Documents

Documents on Unit Testing, Web Testing, Software Testing Artifacts, Software Test Process Etc..

Resume Preparation

2012-03-17T21:34:00.000-07:00

Resume Preparation Guidelines

Before even the interviewer meets you he will first meet your resume. Interviewer looking at your resume is almost a 25% interview happening with out you knowing it.

•    Use plain text when you are sending resumes through email. For instance you sent your resume using Microsoft word and what if the interviewer is using Linux he will never be able to read your resume. You can not be sure both wise, you sent your resume in Word 2000 and the guy has Word 97…uuhhh.

•    Attach a covering letter it really impresses and makes you look traditionally formal. Yes, even if you are sending your CV through email send a covering letter.

Check list of content you should have in your resume :-

•    Start with an objective or summary, for instance, “Working as a Senior Database administrator for more than 4 years. Implemented quality web based application. Follow the industry’s best practices and adhered and implemented processes, which enhanced the quality of technical delivery. Pledge to deliver the best technical solutions to the industry.”

•    Specify your Core strengths at the start of the resume by which the interviewer can make a quick decision are you eligible for the position. For example :-

o Looked after data mining and data warehousing department independently. Played a major role in query optimization.

o Worked extensively in database design and ER diagram implementation. o Well versed with CMMI process and followed it extensively in projects. o Looking forward to work on project manager or senior manager position.

This is also a good position to specify your objective or position which makes it clear to the interviewer that should he call you for an interview. For instance, if you are looking for senior positions specify it explicitly ‘looking for this job profile’. Any kind of certification like MCP, MCSD etc you can make it visible in this section.

Once you have specified briefly your goals and what you have done its time to specify what type of technology you have worked with. For instance RDBMS, TOOLS, Languages, Web servers, process (Six sigma, CMMI).

•    After that you can make a run through of your experience company wise that is what company you have worked with, year / month joining and year / month left. This will give an overview to the interviewer what type of companies you have associated your self.

Now its time to mention all your projects you have worked till now. Best is to start in descending order that is from your current project and go backwards. For every project try to put these things:-

•    Project Name / Client name (It’s sometimes unethical to mention clients name; I leave it to the readers).
•    Number of team members.

•    Time span of the project.

•    Tools, language, RDBMS and technology used to complete the project.

•    Brief summary of the project.

Senior people who have huge experience will tend to increase there CV with putting in summary for all project. Best for them is to just put description of the first three projects in descending manner and rest they can say verbally during interview. I have seen CV above 15 pages… I doubt who can read it.

•    Finally comes your education and personal details.

•    Trying for onsite, do not forget to mention your passport number.

•    Some guys tend to make there CV large and huge. I think an optimal size should be not more than 4 to 5 pages.

•    Do not mention your salary in CV. You can talk about it during interview with HR or the interviewer.

•    When you are writing your summary for project make it effective by using verbs like managed a team of 5 members, architected the project from start to finish etc. It brings huge weight,

•    This is essential very essential take 4 to 5 Xerox copies of your resume you will need it now and then.

•    Just in case take at least 2 passport photos with you. You can escape it but many times you will need it.

•    Carry all your current office documents specially your salary slips and joining letter.

Salary Negotiation

Ok that’s what we all do it for MONEY… not everyone but still money means a lot. This is probably the weakest area for techno savvy guys. They are not good negotiators. I have seen so many guys at the first instance they will smile and say “NEGOTIABLE SIR”.

So here are some points:-

•    Do a study of what is the salary trend? For instance have some kind of baseline. For example what is the salary trend on number of year of experience? Discuss this with your friends out.

•    Do not mention your expected salary on the resume?
•    Let the employer first make the salary offer. Try to delay the salary discussion till the end.

•    If they say what you expect? Come with a figure with a little higher end and say negotiable. Remember never say negotiable on something which you have aimed, HR guys will always bring it down. So negotiate on AIMED SALARY + some thing extra.

•    The normal trend is that they look at your current salary and add a little it so that they can pull you in. Do your home work my salary is this much and I expect this much so whatever it is now I will not come below this.

•    Do not be harsh during salary negotiations.

•    It’s good to aim high. For instance I want 1 billion dollars / month but at the same time be realistic.
•    Some companies have those hidden cost attached in salary clarify it rather to be surprised at the first salary package.

•    Many of the companies add extra performance compensation in your basic which can be surprising at times. So have a detail break down. Best is to discuss on hand salary rather than NET or CTC.

•    Talk with the employer in what frequency does the hike happen.
•    Take everything in writing, go back to your house and have a look once with a cool head is the offer worth it of what your current employer is giving.

•    Do not forget once you have job in hand you can come back to your current employer for negotiation.

•    Remember the worst part is cribbing after joining the company that your colleague is getting more. So be careful while interview or be sportive to be a good negotiator in the next interview.

•    One very important thing is that the best negotiation ground is not the new company where you are going but the old company which you are leaving. So once you have offer on hand get back to your old employee and show them the offer and then make your next move. It’s my experience that negotiating with the old employer is easy than the new one….Frankly if approached properly rarely any one will say no as you have spent quiet a amount of time with them. Just do not be aggressive or egoistic that you have an offer on hand.

•    Top of all some time some things are worth above money: - JOB SATISFACTION. So whatever you negotiate if you think you can get JOB SATISFACTION aspect on higher grounds go for it. I think its worth more than money.

Software Testing Reference

2010-05-03T01:18:00.001-07:00

Software Testing Reference

Documents on Unit Testing, Web Testing, Software Testing Artifacts, Software Test Process Etc..

SQL and PL/SQL Interview questions-III

2010-05-03T01:15:00.000-07:00

SQL and PL/SQL Interview questions-III

85. Under which circumstance must you recompile the package body after recompiling the package specification?
1. Altering the argument list of one of the package constructs
2. Any change made to one of the package constructs
3. Any SQL statement change made to one of the package constructs
4. Removing a local variable from the DECLARE section of one of the package constructs

86. Procedure and Functions are explicitly executed. This is different from a database trigger. When is a database trigger executed?
1. When the transaction is committed
2. During the data manipulation statement
3. When an Oracle supplied package references the trigger
4. During a data manipulation statement and when the transaction is committed

87. Which Oracle supplied package can you use to output values and messages from database triggers, stored procedures and functions within SQL*Plus?
1. DBMS_DISPLAY 2. DBMS_OUTPUT 3. DBMS_LIST 4. DBMS_DESCRIBE

88. What occurs if a procedure or function terminates with failure without being handled?
1. Any DML statements issued by the construct are still pending and can be committed or rolled back.
2. Any DML statements issued by the construct are committed
3. Unless a GOTO statement is used to continue processing within the BEGIN section, the construct terminates.
4. The construct rolls back any DML statements issued and returns the unhandled exception to the calling environment.
89. Examine this code
71. BEGIN
72. theater_pck.v_total_seats_sold_overall := theater_pck.get_total_for_year;
73. END;

For this code to be successful, what must be true?
1. Both the V_TOTAL_SEATS_SOLD_OVERALL variable and the GET_TOTAL_FOR_YEAR function must exist only in the body of the THEATER_PCK package.
2. Only the GET_TOTAL_FOR_YEAR variable must exist in the specification of the THEATER_PCK package.
3. Only the V_TOTAL_SEATS_SOLD_OVERALL variable must exist in the specification of the THEATER_PCK package.
4. Both the V_TOTAL_SEATS_SOLD_OVERALL variable and the GET_TOTAL_FOR_YEAR function must exist in the specification of the THEATER_PCK package.

90 A stored function must return a value based on conditions that are determined at runtime. Therefore, the SELECT statement cannot be hard-coded and must be created dynamically when the function is executed. Which Oracle supplied package will enable this feature?
1. DBMS_DDL
2. DBMS_DML
3. DBMS_SYN
4. DBMS_SQL

91 How to implement ISNUMERIC function in SQL *Plus ?
Method 1:

Select length (translate (trim (column_name),' +-.0123456789',' ')) from dual ;

Will give you a zero if it is a number or greater than zero if not numeric (actually gives the count of non numeric characters)

Method 2:

select instr(translate('wwww',
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ',
'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'),'X')
FROM dual;

It returns 0 if it is a number, 1 if it is not.
92 How to Select last N records from a Table?
select * from (select rownum a, CLASS_CODE,CLASS_DESC from clm)
where a > ( select (max(rownum)-10) from clm)

Here N = 10

The following query has a Problem of performance in the execution of the following query where the table ter.ter_master have 22231 records. So the results are obtained after hours.

Cursor rem_master(brepno VARCHAR2) IS
select a.* from ter.ter_master a
where NOT a.repno in (select repno from ermast) and
(brepno = 'ALL' or a.repno > brepno)
Order by a.repno

What are steps required tuning this query to improve its performance?

-Have an index on TER_MASTER.REPNO and one on ERMAST.REPNO

-Be sure to get familiar with EXPLAIN PLAN. This can help you determine the execution path that Oracle takes. If you are using Cost Based Optimizer mode, then be sure that your statistics on TER_MASTER are up-to-date. -Also, you can change your SQL to:

SELECT a.*
FROM ter.ter_master a
WHERE NOT EXISTS (SELECT b.repno FROM ermast b
WHERE a.repno=b.repno) AND
(a.brepno = 'ALL' or a.repno > a.brepno)
ORDER BY a.repno;

93 What is the difference between Truncate and Delete interms of Referential Integrity?
DELETE removes one or more records in a table, checking referential Constraints (to see if there are dependent child records) and firing any DELETE triggers. In the order you are deleting (child first then parent) There will be no problems.
TRUNCATE removes ALL records in a table. It does not execute any triggers. Also, it only checks for the existence (and status) of another foreign key Pointing to the table. If one exists and is enabled, then you will get The following error. This is true even if you do the child tables first.
ORA-02266: unique/primary keys in table referenced by enabled foreign keys
You should disable the foreign key constraints in the child tables before issuing the TRUNCATE command, then re-enable them afterwards.
CLIENT/SERVER

94. What does preemptive in preemptive multitasking mean ?
Preemptive refers to the fact that each task is alloted fixed time slots and at the end of that time slot the next task is started.

95. What does the OLTP stands for ?
OLTP stands for On Line Transaction Processing

96. What is the most important requirement for OLTP ?
OLTP requires real time response.

97. In a client server environment, what would be the major work that the client deals with ?
The client deals with the user interface part of the system.

98. Why is the most of the processing done at the sever ?
To reduce the network traffic and for application sharing and implementing business rules.

99. What does teh term upsizing refer to ?
Applications that have outgrown their environment are re-engineered to run in a larger environment. This is upsizing.

100. What does one do when one is rightsizing ?
With rightsizing, one would move applications to the most appropriate server platforms.

101. What does the term downsizing refer to ?
A host based application is re-engineered to run in smaller or LAN based environment.

102. What is event trigger ?
An event trigger, a segment of code which is associated with each event and is fired when the event occurs.

103. Why do stored procedures reduce network traffic ?
When a stored procedure is called, only the procedure call is sent to the server and not the statements that the procedure contains.
104. What are the types of processes that a server runs ?
Foreground process and Background process.

105. What is a event handler ?
An event handler is a routine that is written to respond to a particular event.

106. What is an integrity constraint ?
An integrity constraint allows the definition of certain restrictions, at the table level, on the data that is entered into a table.

107. What are the various uses of database triggers ?
Database triggers can be used to enforce business rules, to maintain derived values and perform value-based auditing.

108. What is a transaction ?
A transaction is a set of operations that begin when the first DML is issued and end when a commit or rollback is issued. BEGIN COMMIT/ROLLBACK are the boundries of a transaction.

109. Why are the integrity constraints preferred to database triggers ?
Because it is easier to define an integrity constraint than a database trigger.

110. Why is it better to use an integrity constraint to validate data in a table than to use a stored procedure ?
Because an integrity constraint is automatically checked while data is inserted into a table. A stored has to be specifically invoked.

111. What are the three components of a client server model ?
A Client,
A Server and
A Network/Communication software.

112. What are the advantages of client/server model ?
Flexibility of the system, scalability, cost saving, centralised control and implementation of business rules, increase of developers productivity, portability, improved network and resource utilization.

113. What are the disadvantages of the client/server model ?
Heterogeneity of the system results in reduced reliablity. May not be suitable for all applications. Managing and tuning networks becomes difficult.

114. What are the different topologies available for network ?
Star,
Bus,
Ring.

115. What is the first work of Client process ?
A client process at first establishes connection with the Server.
115. What are the responsibilities of a Server ?
1. Manage resources optimally across multiple clients.
2. Controlling database access and security.
3. Protecting the databse and recovering it from crashes.
4. Enforcing integrity rules globally.

116. In a Client/Server context, what does API (Application Programming Interface) refer to ?
An API, in a Client/Server context, is a specification of a set of functions for communication between the client and the server.

117. Give some examples of standard API??s ?
Open Database Connectivity (ODBC),
Integrated Database Application Programming Interface (IDAPI),
XOpen
SQL/CLI

118. What is the main advantage of developing an application using an API ?
The application can be connected to any back end server that is supported by the API.

119. What is the main disadvantage of developing an application using an API ?
The application cannot use any special features of the backend server.

120. Why is an event driven program referred to a passive program ?
Because an event driven program is always waiting for something to happen before processing.

120. What are the four types of events ?
1. System Events.
2. Control Events
3. User Events
4. Other Events.

121. What is the difference between file server and a database server ?
A file server just transfers all the data requested by all its client and the client processes the data while a database server runs the query and sends only the query output.

122. What is inheritance ?
Inheritance is a method by which properties and methods of an existing object are automatically passed to any object derived from it.

123. What are the two components of ODBC ?
1. An ODBC manager/administrator and
2. ODBC driver.
124. What is the function of a ODBC manager ?
The ODBC Manager manages all the data sources that exists in the system.

125. What is the function of a ODBC Driver ?
The ODBC Driver allows the developer to talk to the back end database.

126. What description of a data source is required for ODBC ?
The name of the DBMS, the location of the source and the database dependent information.

127. How is a connection establised by ODBC ?
ODBC uses the description of the datasource available in the ODBC.INI file to load the required drivers to access that particular back end database.

SQL and PL/SQL Interview questions-II

2010-05-03T01:12:00.000-07:00

SQL and PL/SQL Interview questions-II

54. What is difference between CHAR and VARCHAR2? What is the maximum SIZE allowed for each type?
CHAR pads blank spaces to the maximum length.
VARCHAR2 does not pad blank spaces.
For CHAR the maximum length is 255 and 2000 for VARCHAR2.

55. How many LONG columns are allowed in a table? Is it possible to use LONG columns in WHERE clause or ORDER BY?
Only one LONG column is allowed. It is not possible to use LONG column in WHERE or ORDER BY clause.

56. What are the pre-requisites to modify datatype of a column and to add a column with NOT NULL constraint?
- To modify the datatype of a column the column must be empty.
- To add a column with NOT NULL constrain, the table must be empty.

57. Where the integrity constraints are stored in data dictionary?
The integrity constraints are stored in USER_CONSTRAINTS.

58. How will you activate/deactivate integrity constraints?
The integrity constraints can be enabled or disabled by ALTER TABLE ENABLE CONSTRAINT / DISABLE CONSTRAINT.
59. If unique key constraint on DATE column is created, will it validate the rows that are inserted with SYSDATE?
It won't, Because SYSDATE format contains time attached with it.

60. What is a database link?
Database link is a named path through which a remote database can be accessed.

60. How to access the current value and next value from a sequence? Is it possible to access the current value in a session before accessing next value?
Sequence name CURRVAL, sequence name NEXTVAL. It is not possible. Only if you access next value in the session, current value can be accessed.

60.What is CYCLE/NO CYCLE in a Sequence?
CYCLE specifies that the sequence continue to generate values after reaching either maximum or minimum value. After pan-ascending sequence reaches its maximum value, it generates its minimum value. After a descending sequence reaches its minimum, it generates its maximum.
NO CYCLE specifies that the sequence cannot generate more values after reaching its maximum or minimum value.

61. What are the advantages of VIEW?
- To protect some of the columns of a table from other users.
- To hide complexity of a query.
- To hide complexity of calculations.

62. Can a view be updated/inserted/deleted? If Yes - under what conditions?
A View can be updated/deleted/inserted if it has only one base table if the view is based on columns from one or more tables then insert, update and delete is not possible.

63. If a view on a single base table is manipulated will the changes be reflected on the base table?
If changes are made to the tables and these tables are the base tables of a view, then the changes will be reference on the view.
64. Which of the following statements is true about implicit cursors?
1. Implicit cursors are used for SQL statements that are not named.
2. Developers should use implicit cursors with great care.
3. Implicit cursors are used in cursor for loops to handle data processing.
4. Implicit cursors are no longer a feature in Oracle.

65. Which of the following is not a feature of a cursor FOR loop?
1. Record type declaration.
2. Opening and parsing of SQL statements.
3. Fetches records from cursor.
4. Requires exit condition to be defined.

66. A developer would like to use referential datatype declaration on a variable. The variable name is EMPLOYEE_LASTNAME, and the corresponding table and column is EMPLOYEE, and LNAME, respectively. How would the developer define this variable using referential datatypes?
1. Use employee.lname%type.
2. Use employee.lname%rowtype.
3. Look up datatype for EMPLOYEE column on LASTNAME table and use that.
4. Declare it to be type LONG.

67. Which three of the following are implicit cursor attributes?
1. %found
2. %too_many_rows
3. %notfound
4. %rowcount
5. %rowtype

68. If left out, which of the following would cause an infinite loop to occur in a simple loop?
1. LOOP
2. END LOOP
3. IF-THEN
4. EXIT
69. Which line in the following statement will produce an error?
1. cursor action_cursor is
2. select name, rate, action
3. into action_record
4. from action_table;
5. There are no errors in this statement.

70. The command used to open a CURSOR FOR loop is
1. open
2. fetch
3. parse
4. None, cursor for loops handle cursor opening implicitly.

71. What happens when rows are found using a FETCH statement
1. It causes the cursor to close
2. It causes the cursor to open
3. It loads the current row values into variables
4. It creates the variables to hold the current row values

72. Read the following code:
10. CREATE OR REPLACE PROCEDURE find_cpt
11. (v_movie_id {Argument Mode} NUMBER, v_cost_per_ticket {argument mode} NUMBER)
12. IS
13. BEGIN
14. IF v_cost_per_ticket > 8.5 THEN
15. SELECT cost_per_ticket
16. INTO v_cost_per_ticket
17. FROM gross_receipt
18. WHERE movie_id = v_movie_id;
19. END IF;
20. END;
Which mode should be used for V_COST_PER_TICKET?
1. IN
2. OUT
3. RETURN
4. IN OUT
73. Read the following code:
22. CREATE OR REPLACE TRIGGER update_show_gross
23. {trigger information}
24. BEGIN
25. {additional code}
26. END;

The trigger code should only execute when the column, COST_PER_TICKET, is greater than $3. Which trigger information will you add?

1. WHEN (new.cost_per_ticket > 3.75)
2. WHEN (:new.cost_per_ticket > 3.75
3. WHERE (new.cost_per_ticket > 3.75)
4. WHERE (:new.cost_per_ticket > 3.75)

74. What is the maximum number of handlers processed before the PL/SQL block is exited when an exception occurs?
1. Only one
2. All that apply
3. All referenced
4. None

77. For which trigger timing can you reference the NEW and OLD qualifiers?
1. Statement and Row 2. Statement only 3. Row only 4. Oracle Forms trigger

78. Read the following code:
CREATE OR REPLACE FUNCTION get_budget(v_studio_id IN NUMBER)
RETURN number IS

v_yearly_budget NUMBER;

BEGIN
SELECT yearly_budget
INTO v_yearly_budget
FROM studio
WHERE id = v_studio_id;

RETURN v_yearly_budget;
END;
Which set of statements will successfully invoke this function within SQL*Plus?
1. VARIABLE g_yearly_budget NUMBER
EXECUTE g_yearly_budget := GET_BUDGET(11);
2. VARIABLE g_yearly_budget NUMBER
EXECUTE :g_yearly_budget := GET_BUDGET(11);
3. VARIABLE :g_yearly_budget NUMBER
EXECUTE :g_yearly_budget := GET_BUDGET(11);
4. VARIABLE g_yearly_budget NUMBER

31. CREATE OR REPLACE PROCEDURE update_theater
32. (v_name IN VARCHAR v_theater_id IN NUMBER) IS
33. BEGIN
34. UPDATE theater
35. SET name = v_name
36. WHERE id = v_theater_id;
37. END update_theater;
79. When invoking this procedure, you encounter the error:
ORA-000: Unique constraint(SCOTT.THEATER_NAME_UK) violated.
How should you modify the function to handle this error?
1. An user defined exception must be declared and associated with the error code and handled in the EXCEPTION section.
2. Handle the error in EXCEPTION section by referencing the error code directly.
3. Handle the error in the EXCEPTION section by referencing the UNIQUE_ERROR predefined exception.
4. Check for success by checking the value of SQL%FOUND immediately after the UPDATE statement.

80. Read the following code:
40. CREATE OR REPLACE PROCEDURE calculate_budget IS
41. v_budget studio.yearly_budget%TYPE;
42. BEGIN
43. v_budget := get_budget(11);
44. IF v_budget < 30000
45. THEN
46. set_budget(11,30000000);
47. END IF;
48. END;

You are about to add an argument to CALCULATE_BUDGET. What effect will this have?
1. The GET_BUDGET function will be marked invalid and must be recompiled before the next execution.
2. The SET_BUDGET function will be marked invalid and must be recompiled before the next execution.
3. Only the CALCULATE_BUDGET procedure needs to be recompiled.
4. All three procedures are marked invalid and must be recompiled.

81. Which procedure can be used to create a customized error message?
1. RAISE_ERROR
2. SQLERRM
3. RAISE_APPLICATION_ERROR
4. RAISE_SERVER_ERROR

82. The CHECK_THEATER trigger of the THEATER table has been disabled. Which command can you issue to enable this trigger?
1. ALTER TRIGGER check_theater ENABLE;
2. ENABLE TRIGGER check_theater;
3. ALTER TABLE check_theater ENABLE check_theater;
4. ENABLE check_theater;

83. Examine this database trigger
52. CREATE OR REPLACE TRIGGER prevent_gross_modification
53. {additional trigger information}
54. BEGIN
55. IF TO_CHAR(sysdate, DY) = MON
56. THEN
57. RAISE_APPLICATION_ERROR(-20000,Gross receipts cannot be deleted on Monday);
58. END IF;
59. END;

This trigger must fire before each DELETE of the GROSS_RECEIPT table. It should fire only once for the entire DELETE statement. What additional information must you add?
1. BEFORE DELETE ON gross_receipt
2. AFTER DELETE ON gross_receipt
3. BEFORE (gross_receipt DELETE)
4. FOR EACH ROW DELETED FROM gross_receipt

SQL and PL/SQL Interview questions-I

2010-05-03T01:10:00.000-07:00

SQL and PL/SQL Interview questions-I

1. The most important DDL statements in SQL are:

CREATE TABLE - creates a new database table

ALTER TABLE - alters (changes) a database table

DROP TABLE - deletes a database table

CREATE INDEX - creates an index (search key) 

DROP INDEX - deletes an index

2. Operators used in SELECT statements.

= Equal
<> or != Not equal
> Greater than
< Less than
>= Greater than or equal
<= Less than or equal
BETWEEN Between an inclusive range
LIKE Search for a pattern

3. SELECT statements:

SELECT column_name(s) FROM table_name
SELECT DISTINCT column_name(s) FROM table_name
SELECT column FROM table WHERE column operator value
SELECT column FROM table WHERE column LIKE pattern
SELECT column,SUM(column) FROM table GROUP BY column
SELECT column,SUM(column) FROM table GROUP BY column HAVING SUM(column) condition value
Note that single quotes around text values and numeric values should not be enclosed in quotes. Double quotes may be acceptable in some databases.

4. The SELECT INTO Statement is most often used to create backup copies of tables or for archiving records.

SELECT column_name(s) INTO newtable [IN externaldatabase] FROM source
SELECT column_name(s) INTO newtable [IN externaldatabase] FROM source WHERE column_name operator value

5. The INSERT INTO Statements:

INSERT INTO table_name VALUES (value1, value2,....)
INSERT INTO table_name (column1, column2,...) VALUES (value1, value2,....)

6. The Update Statement:

UPDATE table_name SET column_name = new_value WHERE column_name = some_value

7. The Delete Statements:

DELETE FROM table_name WHERE column_name = some_value
Delete All Rows:
DELETE FROM table_name or DELETE * FROM table_name

8. Sort the Rows:

SELECT column1, column2, ... FROM table_name ORDER BY columnX, columnY, ..
SELECT column1, column2, ... FROM table_name ORDER BY columnX DESC
SELECT column1, column2, ... FROM table_name ORDER BY columnX DESC, columnY ASC

9. The IN operator may be used if you know the exact value you want to return for at least one of the columns.

SELECT column_name FROM table_name WHERE column_name IN (value1,value2,..)

10. BETWEEN ... AND

SELECT column_name FROM table_name WHERE column_name BETWEEN value1 AND value2 The values can be numbers, text, or dates.

11. What is the use of CASCADE CONSTRAINTS?

When this clause is used with the DROP command, a parent table can be dropped even when a child table exists.

12. Why does the following command give a compilation error?

DROP TABLE &TABLE_NAME; Variable names should start with an alphabet. Here the table name starts with an '&' symbol.

13. Which system tables contain information on privileges granted and privileges obtained?

USER_TAB_PRIVS_MADE, USER_TAB_PRIVS_RECD

14. Which system table contains information on constraints on all the tables created?obtained?

USER_CONSTRAINTS.

15. What is the difference between TRUNCATE and DELETE commands?

< TRUNCATE. with and DELETE used be can clause WHERE back. rolled cannot operation TRUNCATE but back, Hence command. DML a is whereas command DDL>

16. State true or false. !=, <>, ^= all denote the same operation?

True.

17. State true or false. EXISTS, SOME, ANY are operators in SQL?

True.

18. What will be the output of the following query?

SELECT REPLACE(TRANSLATE(LTRIM(RTRIM('!! ATHEN !!','!'), '!'), 'AN', '**'),'*','TROUBLE') FROM DUAL;?

19. What does the following query do?

SELECT SAL + NVL(COMM,0) FROM EMP;?
This displays the total salary of all employees. The null values in the commission column will be replaced by 0 and added to salary.

20. What is the advantage of specifying WITH GRANT OPTION in the GRANT command?

The privilege receiver can further grant the privileges he/she has obtained from the owner to any other user.

21. Which command executes the contents of a specified file?

START or @.

22. What is the value of comm and sal after executing the following query if the initial value of ‘sal’ is 10000
UPDATE EMP SET SAL = SAL + 1000, COMM = SAL*0.1;?

sal = 11000, comm = 1000.

23. Which command displays the SQL command in the SQL buffer, and then executes it?

RUN.

24. What command is used to get back the privileges offered by the GRANT command?

REVOKE.

25. What will be the output of the following query? SELECT DECODE(TRANSLATE('A','1234567890','1111111111'), '1','YES', 'NO' );? NO.

Explanation : The query checks whether a given string is a numerical digit.

26. Which date function is used to find the difference between two dates?

MONTHS_BETWEEN.

27. What operator performs pattern matching?

LIKE operator.

28. What is the use of the DROP option in the ALTER TABLE command?

It is used to drop constraints specified on the table.

29. What operator tests column for the absence of data?

IS NULL operator.

30. What are the privileges that can be granted on a table by a user to others?

Insert, update, delete, select, references, index, execute, alter, all.

31. Which function is used to find the largest integer less than or equal to a specific value?

FLOOR.

32. Which is the subset of SQL commands used to manipulate Oracle Database structures, including tables?

Data Definition Language (DDL).

33. What is the use of DESC in SQL?

DESC has two purposes. It is used to describe a schema as well as to retrieve rows from table in descending order.
Explanation :
The query SELECT * FROM EMP ORDER BY ENAME DESC will display the output sorted on ENAME in descending order.

34. What command is used to create a table by copying the structure of another table?

CREATE TABLE .. AS SELECT command
Explanation:
To copy only the structure, the WHERE clause of the SELECT command should contain a FALSE statement as in the following.
CREATE TABLE NEWTABLE AS SELECT * FROM EXISTINGTABLE WHERE 1=2;
If the WHERE condition is true, then all the rows or rows satisfying the condition will be copied to the new table.

35. TRUNCATE TABLE EMP;
DELETE FROM EMP;
Will the outputs of the above two commands differ?

Both will result in deleting all the rows in the table EMP..

36. What is the output of the following query SELECT TRUNC(1234.5678,-2) FROM DUAL;?

1200.

37. What are the wildcards used for pattern matching.?

_ for single character substitution and % for multi-character substitution.

38. What is the parameter substitution symbol used with INSERT INTO command?

39. What is the sub-query?

Sub-query is a query whose return values are used in filtering conditions of the main query.

40. What is correlated sub-query?

Correlated sub-query is a sub-query, which has reference to the main query.

41. Explain CONNECT BY PRIOR?

Retrieves rows in hierarchical order eg.
select empno, ename from emp where.

42. Difference between SUBSTR and INSTR?

INSTR (String1, String2 (n, (m)),
INSTR returns the position of the m-th occurrence of the string 2 in string1. The search begins from nth position of string1.
SUBSTR (String1 n, m)
SUBSTR returns a character string of size m in string1, starting from n-th position of string1.

43. Explain UNION, MINUS, UNION ALL and INTERSECT?

INTERSECT - returns all distinct rows selected by both queries. MINUS - returns all distinct rows selected by the first query but not by the second. UNION - returns all distinct rows selected by either query UNION ALL - returns all rows selected by either query, including all duplicates.

44. What is ROWID?

ROWID is a pseudo column attached to each row of a table. It is 18 characters long, blockno, rownumber are the components of ROWID.

45. What is the fastest way of accessing a row in a table?

Using ROWID.
CONSTRAINTS

46. What is an integrity constraint?

Integrity constraint is a rule that restricts values to a column in a table.

47. What is referential integrity constraint?

Maintaining data integrity through a set of rules that restrict the values of one or more columns of the tables based on the values of primary key or unique key of the referenced table.

48. What is the usage of SAVEPOINTS?

SAVEPOINTS are used to subdivide a transaction into smaller parts. It enables rolling back part of a transaction. Maximum of five save points are allowed.

49. What is ON DELETE CASCADE?

When ON DELETE CASCADE is specified Oracle maintains referential integrity by automatically removing dependent foreign key values if a referenced primary or unique key value is removed.

50. What are the data types allowed in a table?

CHAR, VARCHAR2, NUMBER, DATE, RAW, LONG and LONG RAW.

Software Testing Guide

2010-03-16T01:43:00.000-07:00

Software Testing Guide

I) Introduction

a) Software, Types of Software

b) Software Project, Application and Product

c) Software Business Process

II) SDLC (Software Development Life Cycle)

a) Requirements Gathering

b) Analysis & Planning

c) Software Design

d) Coding/Implementation

e) Testing

f) Release & Maintenance

III) SDLC Models

a) Sequential Models

1) Waterfall Model

2) ‘V’ Model

b) Incremental / Iterative Models

1) Prototype Model

2) Spiral Model

3) Agile Model

IV) Test Levels

a) Unit Testing/Component Testing/Module Testing

b) Integration Testing

c) System Testing

d) Acceptance Testing

V) Software Environment

a) I-Tier or Standalone Applications

b) II-Tier or Client/Server Applications

c) III-Tier or Web Applications

d) N-Tier or Distributed Applications

VI) Test Types

a) Functional Testing

b) Non-Functional Testing

c) Structural Testing

d) Re & Regration Testing

VII) Test Design Techniques

a) Black box Techniques

1) Equivalence Partitioning/ Equivalence Classes (EP/EC)

2) Boundary Value Analysis (BVA)

3) Decision Table Testing

4) State Transition Testing

5) Use Case Testing

b) White box Techniques

1) Statement Testing

2) Decision Testing

3) Condition/Multi Condition Testing

4) Mutation Testing

VIII) Testing Process (STLC)

a) Test Strategy

b) Test Planning

c) Configuration Management

d) Risk Analysis

e) Test Design (Test Scenarios, Test Cases and Test Data)

f) Test Execution

g) Defect Reporting & Tracking

h) Status Reporting

i) Test Closure

IX) Informal Testing

a) Exploratory Testing

b) Error Guessing

X) Quality Standards

a) ISO Standards

b) IEEE Standards

c) CMM/CMM (I) Process Guidelines

XI) Software Business Domains

a) BFSI

b) ERP

c) Healthcare

d) Telecom

e) Ecommerce

f) Others

Software Quality:

Software satisfies quality only when it meets to Customer Requirement / Customer Satisfaction / Customer Expectations. Meets Customer Requirement refers to proper output & Customer Expectations refers to extra characteristics, good interface, speed, privacy, security, easy to operate, good functionality.

Non-technical reasons: Cost of product & Time to market

Software Quality Assurance:

SQA are the Concepts to be followed by company to develop the software. An SQA team is responsible for Monitoring & Measuring the strength of developing processes.

Software Project:

A set of problems assigned by the client, who can be solved by the software people through the process of software Engineer called Software project. In short, the problem, the people, the process called project. Software related problem is solved by software engineers through software engineer process is software project.

Software Development Life Cycle / Life Cycle Development:

Stages involved in software project development

1) Information gathering; Customer requirement

2) Analysis; Customer requirement v/s Solutions

3) Design; Dividing the project into modules & coupling them

4) Coding; Physical construction of project

5) Testing

6) Maintenance

Information gathering stage:

In this stage, Business Analyst studies the requirement of the client /customer and they prepare Business Requirement Specification (BRS) documents.

Analysis:

In this stage, Sr. Analyst prepares Software Requirement Specification (S/w RS) document with respect to corresponding BRS document. This document consists of two sub-documents System Requirement Specification (SRS) & Functional Requirement Specification (FRS). SRS contain details about software & hardware requirement. FRS contains details about the functionality to be used in project.

Designing:

In designing phase, Designers creates two documents High Level Document (HLD) & Low Level Document (LLD). HLD consists of main modules of the project from root to leaf and multiple LLD’s. LLD consists of sub-modules of main module along with Data flow diagrams, ER-Diagrams, etc., are prepared by technical support people or designers called Internal designers.

Black box tester should have knowledge of customer requirement
Black box testing tests BRS & SRS
Testing external interfacing is Black box testing
Testing internal interfacing is White box testing
White box testing is done w.r.t design documents

Testing:

Testing

Development

V MODEL TESTING

Port testing

Test Software changes

Test efficiency

Functional system testing

User acceptance testing

Test documentation

Design phase testing

Programme phase testing

Assesment development plan

Prepare Test plan

Requirement phase testing

Maintenance

Install Build

Design & Coding

Information

* Test plan is developed based on Development plan

Formula for test efficiency: DRE = A / A + B

DRE = Defect Removal Efficiency

A -> Bugs found at the testing side

B -> Bugs found at the client side

DRE= 0.8 – 0.9 good

0.7 – 0.8 requires improvement

< 0.7 poor

Refinement Form of V-Model

From the above refinement form of V-Model, small & medium scale organizations are maintaining separate testing team for Functional & System testing stage.

1) Reviews during Analysis

In general, Software development process starts with Information Gathering & Analysis. In this stage Business Analyst category people are preparing BRS & S/w RS documents and after completion documents preparation, they conduct reviews on the documents for completeness & correctness. This review focuses on below factors:

1) Are they complete

2) Are they met with right requirements of client / customer

3) Are they achievable w.r.t technology

4) Are they reasonable w.r.t time & cost

5) Are they testable

2) Reviews during Design

After completion of Analysis phase & their reviews, our Project-level designers will start logical design of application in terms of External & Internal design (HLD’s & LLD’s). In this stage, they conduct reviews for completeness & correctness of designed documents. This review focuses on below factors:

1) Are they understandable

2) Are they met with right requirements of client / customer

3) Are they complete

4) Are they follow able

5) Does they handle errors

3) During Unit Testing

After completeness of Design & their reviews, software programmers will starts coding the logical design to physical construction of software. During these coding stage programmers is conducting Unit Testing through a set of White box testing techniques, Unit Testing also known as Module / Component / Program / Micro testing

White box Testing:

There are three possible White box testing techniques

1) Execution Testing

Basic path coverage – Execution of all possible blocks in a program

Loops coverage – Termination of loop statements

Programmer technique coverage – less no of memory cycles & CPU cycles

2) Operation Testing – Running the application on Customer expected platforms

3) Mutation Testing

Mutation means that a change program. White box testers are performing the change in the program to estimate test coverage on that program. Mutation testing can decide whether the test coverage is correct or wrong

4) Integration Testing

After completion of dependent modules of development & testing, Programmers combine them to form a System. In this Integration, they are conducting Integration testing on the compiled modules w.r.t HLD.

There are three approaches to conduct Integration testing

a) Top-Down Approach

Top-Down Approach

In this approach, testing is conducted on Main module without conducting testing to some of sub-modules. From the above diagram, a Stub is a temporary program instead of under constructive sub-module, it is known as called program.

b) Bottom-Up Approach

Bottom-Up Approach

In this approach, testing is conducted on sub-modules without conducting testing on main modules. From the above diagram, a Driver is a temporary program instead of main module, it is known as calling program.

c) Sandwich or Hybrid Approach

Sandwich / Hybrid Approach

In this approach, testing is conducted taking both Top-Down & Bottom Approaches.

* Build: A finally integrated all modules set *.exe form file is called build.

4) Functional & System testing (* imp)

After completion of final integration of modules as a system, Testing Engineers are planning to conduct Functional & System testing through Black box testing techniques, these techniques classified into four categories.

1) Usability Testing

2) Functional Testing

3) Performance Testing

4) Security Testing

From Above 1 & 2 are Core level and 3 & 4 are Advance level

Ø During Usability testing, Testing team validates User-Friendliness of screens.

Ø During Functional testing, TT validates the correctness of customer requirements

Ø During Performance testing, TT estimates speed of processing

Ø During Security testing, Testing team validates privacy to User operations

1) Usability Testing

In general, TT starts with test execution with Usability testing. During test, Testing team validates User-Friendliness of screens of build. During Usability testing, TT applies two types of sub-test:

a) User Interface Test

Ø Easy of use (Understandable screens)

Ø Look & Feel (Attractiveness & Pleasantness)

Ø Speed in Interface (Less no of event to complete a test, easy short navigation)

b) Manual Support Test

Ø Context sensitiveness of user manuals

Ø Manual support test are conducted at the end of all testing & before release

2) Functional Testing

The major part of Black box testing is Functional testing, during this test, Testing team1 concentrates on “meet customer requirements”. This Functional Testing is classified into below sub-test.

a) Functional / Requirement Testing

During this test, Test Engineers validates correctness of every functionality in terms of below coverage’s.

Ø Behavioral coverage (changes in object properties)

Ø Input domain coverage (size & type of every input & output object)

Ø Error handling coverage (preventing negative navigations)

Ø Calculations coverage (correctness of output)

Ø Back-end coverage (impact of Front-end operation on back-end tables contents)

Ø Service levels coverage (order of functionalities)

b) Input Domain Testing

It is a part of Functionality testing; Test Engineers are maintaining special structures to define size & type of input object

c) Recovery Testing

It is also known as Reliability testing. During this test, Testing team validates whether the application is changing from abnormal state to normal state or not.

d) Compatibility Testing

It is also known as Portability testing. During this test, Testing team validates whether application build run on customer expected platforms or not. During this test, Testing Engineers are finding Backward compatibility at maximum.

Ø Forward compatibility -> application is ready to run but Operating system is not supporting.

Ø Backward compatibility -> Operating system is supporting but the application has some internal coding problems to run on Operating system

e) Configuration Testing

It is also known as Hardware compatibility testing. During this test, Testing team validates whether application build supports different technology Hardware devices or not.

f) Inter-Systems Testing

During this test, Testing team validates whether application build co-existence with other existing software’s or not and also test whether any Dead lock situation occurs or not.

g) Installation Testing

During this test, Testing team validates whether application build along with supported software’s into customers site like configured systems. During this test, Testing team observes below factors.

Ø Setup program execution to start installation

Ø Easy Interface

Ø Amount of disk occupied after installation

h) Parallel / Comparative Testing

During this test, Testing team compares application build with competitive products in market.

i) Sanitation / Garbage Testing

During this test, Testing team tries to find extra features in application build w.r.t customer requirements.

* Defects

During this test, Testing team reports defects to developers in terms of below categories

Mismatches between expected & actual
Missing functionality
Extra functionality w.r.t customer requirement

* Manual v/s Automation

A Tester conducts any test on application build without using any testing tool is called Manual testing, if any testing tool is used then it is called Automation testing

In common testing process, Testing Engineers are using test Automation w.r.t test impact & criticality. Impact -> test repetition & Criticality -> complex to apply test manually. Due to these two reasons testing people are using test Automation.

j) Re-testing

The re-execution of a test with multiple test data to validate a function, e.g. To validate multiplication, Test Engineers use different combinations of input in terms of min, max, -ve, +ve, zero, int, float, etc.

k) Regression Testing

The re-execution of test on modified build to ensure bug fixing work & occurrence of any side effects, Test Engineers conducts this test using Automation

l) Error, Defect & Bug

A mistake in code is Error, due to errors in coding, Test Engineers are getting mismatches in application build are defects, if the defects are accepted by developers to be solves then it is Bug.

Testing Documents

Above Figure, shows the various levels of documents prepared at project testing. Test Policy is documented by Quality Control. Test Strategy & Test Methodology are documented by Quality Analyst or Project Manager. Test Plan, Test Cases, Test Procedure, Test Script & Defect Report are documented by Quality Assurance Engineers or Test Engineers.

Test Policy & Test Strategy are Company Level Documents. Test Methodology, Test Plan, Test Cases, Test Procedure, Test Script, Defect Report & Final Test Summary Report are Project Level Documents.

1) TEST POLICY:

This document developed by Quality Control people (Management). In this document Quality Control defines “Testing Objective”.

Test Policy Document

Address of the Company

Test Definition : Verification & Validation

Testing Process : Proper planning before starts testing

Testing Standards : One defect per 250 lines of code or 10 FP (Functional points)

Testing Measurements : QAM, TTM, PCM

*******

(C.E.O)

QAM: Quality Assurance Measurements, how much quality is expected

TTM: Testing Team Measurements, how much testing is over & is yet to complete

PCM: Process Capability Measurements, depends on old project to the upcoming projects.

2) TEST STRATEGY:

This is a Company level document & developed by Quality Analyst or Project Manager Category people, it defines “Testing Approach”.

Components:

a) Scope & Objective: Definition & purpose of testing in organization

b) Business Issue: Budget control for testing

c) Test Approach: Mapping between development stages & Testing Issue.

d) Test Deliverables: Required testing documents to be prepared

e) Roles & Responsibilities: Names of the job in testing team & their responsibilities

f) Communication & Status reporting: Required negotiation between testing team & developing team during test execution

g) Automation & Testing Tools: Purpose of automation & possibilities to go to test automation

h) Testing Measurements & Metrics: QAM, TTM, PCM

i) Risks & Mitigation: Possible problems will come in testing & solutions to overcome

j) Change & Configuration Management: To handle change request during testing

k) Training Plan: Required training sessions to testing team before start testing process

Testing Issues:

Authorization: Whether user is valid or not to connect to application
Access Control: Whether a valid user have permission to use specific service
Audit Trail: Maintains metadata about user operation in our application
Continuity of Processing: Inter-process communication
Correctness: Meet customer requirement in terms of functionality
Coupling: Co-existence with other existence software to share resources
Ease of Use: User Friendliness of the screens
Ease of Operator: Installation, Un-installations, Dumping, Uploading, Downloading, etc.,
File Integrity: Creation of backup
Reliability: Recover from abnormal state
Performance: Speed of processing
Portable: Run on different platforms
Service levels: Order of functionalities
Maintainable: Whether our application build is long term serviceable to our customer
Methodology: Whether our tester are following standards or not during testing

3) TEST METHODOLOGY:

It is project level document. Methodology provides required testing approach to be followed for current project. In this level Quality Analyst select possible approach for corresponding project testing.

Pet Process:

Process involves experts, tools & techniques. It is a refinement form of V-Model. It defines mapping between development & Testing stages. From this model, Organizations are maintaining separate team for Functional & System testing & remaining stages of testing done by development people. This model is developed in HCL & recognized by QA Forum of INDIA.

TESTING PROCESS

Information Gathering (Business Requirement Specifications)

Unit & Integration

Test Closure

4) TEST PLANNING:

After finalization of possible test for current project, Test Lead category people concentration on test plan document preparation to define work allocation in terms of What, Who, When & How to test. To prepare test plan document, test plan order follows below approach;

1] Team Formation:

In general, Test planning process starts with testing team formation. To define a testing team, test plan author depends on below factors;

1. Availability of testers

2. Test duration

3. Availability of test environment resource

2] Identify Tactical Risk:

After Testing team formation Plan author analysis possible & mitigation (ad hoc testing)

# Risk 1: Lack of knowledge of Test Engineer on that domain

# Solⁿ1: Extra training to Test Engineers

# Risk 2: Lack of Resource

# Risk 3: Lack of budget {less no of time}

# Solⁿ3: Increase Team size

# Risk 4: Lack of Test data

# Solⁿ4: Conduct test on past experience basis i.e., ad hoc testing or contact client for data

# Risk 5: Lack of developer process rigor

# Solⁿ5: Report to Test Lead for further communication between test & development PM

# Risk 6: Delay of modified build delivery

# Solⁿ6: Extra hours of work is needed

# Risk 7: Lack of communication in between Test Engineer - > Test team and

Test team - > Development team

3] PREPARE TEST PLAN:

After completion of testing team formation & Risk analysis, Test plan author concentrate on Test Plan Document in IEEE format.

01) Test Plan ID: Unique No or Name e.g. STP-ATM

02) Introduction: About Project description

03) Test Items: Modules / Functions / Services / Features / etc.

04) Features to be tested: Responsible Modules for Test design (preparing test cases for

added modules)

05) Features not to be tested: Which feature is not to be tested and Why? (Due to test

cases available for the old modules, so for these modules no

need to be tested / no test case

Above (3), (4) & (5) decides which module to be tested – > What to test?

06) Approach: List of selected testing techniques to be applied on above specified

modules in reference to the TRM(Test Responsible Matrix).

07) Feature pass or fail criteria: When a feature is pass or fail description

(Environment is good) (After testing conclusion)

08) Suspension criteria: Possible abnormal situations rose during above features testing

(Environment is not good) (During testing conclusion)

09) Test Environment: Required software & Hardware to be tested on above features

10) Test Deliverables: Required testing document to be prepared (during testing, the type

of documents are prepared by tester)

11) Testing Task: Necessary tasks to do before start every feature testing

Above (6) to (11) specifies -> How to test?

12) Staff & Training: Names of selected Test Engineers & training requirements to them

13) Responsibilities: Work allocation to every member in the team (dependable modules

are given to single Test Engineer)

14) Schedule: Dates & Times of testing modules

Above (4) specifies -> When to test?

15) List & Mitigation: Possible testing level risks & solution to overcome them

16) Approvals: Signatures of Test plan authors & Project Manager / Quality Analyst

4) Review Test Plan:

After completion of plan document preparation, Test plan author conducts a review of completion & correctness. In this review, Plan author follows below coverage analysis

Ø BRS based coverage (What to test? Review)

Ø Risks based coverage (When & Who to test? Review)

Ø TRM based coverage (How to test? Review)

5) TEST DESIGNING:

After completion of Test Planning & required training to testing team, corresponding testing team members will start preparing the list of test cases for their responsible modules. There are three types of test cases design methods to cover core level testing (Usability & Functionality testing).

a) Business Logic based test case design (S/w RS)

b) Input Domain based test case design (E-R diagrams / Data Models)

c) User Interface based test case design (MS-Windows rules)

a) Business Logic based Test Case design (S/w RS)

In general, Test Engineers are preparing a set of Test Cases depends on Use Cases in (S/w RS). Every Use Case describes a functionality in terms of inputs, process & output, depends on this Use Cases Test Engineers are preparing Test Cases to validate the functionality

From the above model, Test Engineers are preparing Test Cases depends on corresponding Use Cases & every test case defines a test condition to be applied.

To prepare test cases, Test Engineers studies Use Cases in below approach:

Steps:

1) Collect Use Cases of our responsible module

2) Select a Use Case & their dependencies from the list

2.1) Identify entry condition (Base state)

2.2) Identify input required (Test data)

2.3) Identify exit condition (End state)

2.4) Identify output & outcome (Expected)

2.5) Identify normal flow (Navigation)

2.6) Identify alternative flows & exceptions

3) Write Test Cases depends on above information

4) Review Test Cases for the completeness & correctness

5) Goto step (2) until completion of all Use Cases completion

Use Case I:

A login process allows user id & password to validate users. During these validations, login process allows user id in alpha-numeric from 4 to 16 characters long & password in alphabets in lowercase from 4 to 8 characters long.

Case study:

Test Case 1) Successful entry of user id

BVA (Size)

min -> 4 chars => pass

min-1 -> 3 chars => fail

min+1 -> 5 chars => pass

max-1 -> 15 chars => pass

max+1 -> 17 chars => fail

max -> 16 chars => pass

ECP

Valid Invalid

a-z special chars

A-Z blank

0-9

Test Case Format:

During Test design Test Engineers are writing list of Test Cases in IEEE format.

01) Test Case ID: Unique no or name

02) Test Case Name: Name of test condition to be tested

03) Feature to be tested: Module / Function / Feature

04) Test suit ID: Batch ID, in which this case is member

05) Priority: Importance of Test Case {Low, Med, High}

P₀-> Basic functionality

P₁ -> General functionality (I/P domain, Error handling, Compatibility etc,)

P₂ -> Cosmetic testing (UIT)

06) Test Environment: Required Software & Hardware to execute

07) Test afford (person / hr): Time to execute this Test Case e.g. 20 minutes

08) Test duration: Date & Time

09) Test Setup: Required testing task to do before starts case execution (pre-requisites)

10) Test Procedure: Step by step procedure to execute Test Case

Test Procedure Format:

1) Step No:

2) Action: -> Test Design

3) Input required:

4) Expected:

5) Actual:

6) Result: -> Test Execution

7) Comments:

11) Test Case passes or fails criteria: When this case is pass or fail

Note: Test Engineers follows list of Test Cases along with step by step procedures only

Example 1:

Prepare Test Procedure for below test cases “Successful file save operation in Notepad “.

Step No	Action	Input Required	Expected
1	Open Notepad		Empty Editor
2	Fill with text		Save Icon enabled
3	Click Save Icon or click File menu Option & select save option		Save Dialog box appears with Default file name
4	Enter File name & Click Save	Unique File name	Focus to Notepad & File name Appears in title bar of Notepad

Note: For more examples refer to notes

b) Input Domain based Test Case design (E-R diagrams / Data Models)

In general, Test Engineers are preparing maximum Test Cases depends on Use Cases or functional requirements in S/wRS. These functional specifications provide functional descriptions with input, output & process, but they are not responsible to provide information about size & type of input objects. To correct this type of information, Test Engineers study Data model of responsible modules E-R diagram. During Data model study, Test Engineer follows below approach: Steps:

1) Collect Data model of responsible modules

2) Study every input attribute in terms of size, type & constraint

3) Identify critical attributes in the test, which is participated in manipulation & retrivals

4) Identify non-critical attributes such as input & output type

A/C No:

Critical

A/C Name:

Balance:

Non-Critical

Address:

5) Prepare BVA & ECP for every input object

ECP BVA(Size / Range)

Input Attribute	Valid	Invalid	Minimum	Maximum
Xxxx	xxxx	xxxx	xxxx	xxxx
“	“	“	“	“
“	“	“	“	“
“	“	“	“	“

DATA MATRIX

Note: In general, Test Engineers are preparing step by step procedure based Test Cases for functionality testing. Test Engineers prepare valid / invalid table based Test Cases for input domain of object testing {Data Matrix }

Note: For examples refer to notes

c) User Interface based test case design (MS-Windows rules)

To conduct Usability Testing, Test Engineers are preparing list of Test Cases depends on our organization User Interface standards or conventions, Global User Interface rules & interest of customer site people.

Example: Test Cases

1) Spelling check

2) Graphics check (Screen level Align, Font style, Color, Size & Microsoft six rules)

3) Meaning of error messages

4) Accuracy of data displayed

5) Accuracy of data in the database are result of user inputs, if developer restrict the data in

database level by rounding / truncating then the developer must also restrict the data in

front-end as well

6) Accuracy of data in the database as the result of external factors. Ex. File attachments

7) Meaningful help messages (Manual support testing)

Review Test Cases:

After completion of all possible Test Cases preparation for responsible modules, Testing team concentrates on review of Test Cases for completeness & correctness. In this review, Testing team applies coverage analysis.

Test Case Review

1) BR based coverage

2) Use Cases based coverage

3) Data model based coverage

4) User Interface based coverage

5) TRM based coverage

At the end of this review, Test Lead prepare Requirement Traceability Matrix or Requirement Validation Matrix (RTM / RVM)

Business Requirement

Source (Use Cases, Data model)

Test Cases

xxxx xxxx xxxx

xxxx

xxxx xxxx

xxxx

xxxx xxxx

xxxx

xxxx xxxx xxxx

xxxx

xxxx xxxx

xxxx

From RTM / RVM model, it defines mapping between customer requirement & prepared Test Cases to validate the requirement.

6) TEST EXECUTION:

After completion of Test Cases selections & their review, Testing team concentrate on Build release from development side & Test execution on that build.

a) Test Execution Levels or Phases:

See figure in next page for clear understandability of this levels

b) Test Execution Levels v/s Test Cases:

Level – 0 -> P₀Test Cases

Level – 1 -> All P₀, P₁ & P₂ Test Cases as batches

Level – 2 -> Selected P₀, P₁, & P₂ w.r.t modification

Level – 3 -> Selected P₀, P₁, & P₂ w.r.t critical areas in the master build

A) Test Execution Levels or Phases:

Defect Report

Level – 1

Comprehensive

Level – 3

Final Regression

Level – 2

Regression

Defect

Fixing

c) Build Version Control:

In general, Testing Engineers are receiving build from development in below model

Testers

Build

Testing Environment

FTP (file transport Protocol)

Server

During Test execution Test Engineer are receiving modified build from software. To distinguish old & new builds, development team maintains unique version in system, which is understandable to Tester / Testing team. For this version controlling developers are using version control tools (Visual Source Safe)

d) Level – 0 (Sanity / Test Acceptance / Build verification test):

After receiving initial build, Testing Engineers concentrate on basic functionality of that build to estimate stability for complete testing. In this Sanity testing, Testing Engineers tries to execute all P₀Test Cases to cover basis functionality. If functionality is not working / functionality missing, Testing team rejects that build. If Tester decided stability then they concentrate on Test execution of all Test Cases to detect defects.

During this Sanity testing, Testing Engineer observes below factors on that build

1) Understandable

2) Operatable

3) Observable

4) Consistency

5) Controllable

6) Simplicity

7) Maintainable

8) Automation

From the above “8” testable issues, Sanity test is also known as Testability testing / OCT angle testing.

e) Test Automation:

If test automation is possible than Testing team concentrate on Test script creation using corresponding testing tools. Every Test script consists of navigation statement along with required check points.

Stable Build

Test Automation

(Select Automation)

(All P₀ & Carefully selected P₁ Test Cases)

f) Level – 1 (Comprehensive testing)

After completion of Sanity testing & possible test automation, Testing team concentrates on test batches formation with depended Test Cases. Test batches are also known as Test suits / sets. During these Test batches execution, Test Engineers prepare test log document, this document consist of three types of entries.

1) Passed (Expected = Actual)

2) Failed (Any one Expected != Actual, Any one Expected variants from Actual)

3) Blocked (Corresponding parent functionality failed)

g) Level – 2 (Regression testing)

During Comprehensive test execution, Test Engineers are reporting mismatches as defects to developers. After receiving modified build from developers, Test Engineers concentrate on Regression testing to ensure bug-fixing work & occurrences of side effects.

Case I:

If development team resolve bugs severity which is high, Test Engineers re-execute all P₀, P₁ & carefully selected P₂ Test Cases on modified build

Case II:

Bugs severity is medium, then all P₀, carefully selected P₁ & some of P₂ Test Cases

Case III:

Bugs severity is low, then some P₀, P₁ & P₂

Case IV:

If development team released modified build due to sudden changes in project requirement then Test Engineers re-execute all P₀, P₁ & carefully selected P₂ Test Cases w.r.t that requirement modification.

h) Level – 3 (Final Regression / Pre-Acceptance testing)

7) TEST REPORTING:

During comprehensive testing, Test Engineer are reporting mismatches as defects to developers through IEEE format.

1) Defect ID: Unique No or Name

2) Description: Summary of the defect

3) Feature: Module / Function / Service , in these module TE found the defect

4) Test Case Name: Corresponding failing test condition

5) Reproducible (Yes / No): Yes -> Every time defect appears during test execution

No -> Rarely defect appears

6) If Yes, attach test procedure:

7) If No, attach snapshot & strong reasons:

8) Status: New / Reopen

9) Severity: Seriousness of defect w.r.t functionality (high / medium / low)

10) Priority: Importance of the defect w.r.t customers (high / medium / low)

11) Reported bug: Name of Test Engineer

12) Reported on: Date of submission

13) Assign to: Name of the responsible person in development team -> PM

14) Build Version ID: In which build, Test Engineer fount the defect

15) Suggested fix (Optional): Tester tries to produce suggestion to solve this defect

16) Fixed by: PM or Team Lead

17) Resolved by: Developer name

18) Resolved on: Date of solving By Developers

19) Resolution type: check out in next page

20) Approved by: Signature of Project Manager (PM)

Defect Age: The time gap between “reported on” & “resolved on”

Defect submission process:

Defect Status Cycle:

New Open / rejected / deferred close reopen

Deferred => Accepted but not interested to resolve in this version

Defect Resolution:

After receiving defect report from Testers, developers review the defect & they send resolution type to Tester as a reply

01) Duplicate, rejected due to the defect is same as previously reported defect

02) Enhancement, rejected due to the defect is related future requirement of customer

03) H/w limitation, rejected due to the defect raised w.r.t limitation of H/w devices

04) S/w limitations, rejected due to the defect raised w.r.t limitation of S/w Techno

05) Not applicable, rejected due to the defect has no proper meaning

06) Functions as designed, rejected due to coding is correct w.r.t to designed doc’s

07) Need more information, not (accepted / rejected) but developers requires extra information to understand the defect

08) Not reproducible, not (accepted / rejected) but developers require correct procedure to reproduce the defect

09) No plan to fix it, not (accepted / rejected) but developers want extra time to fix

10) Fixed, developers accepted to resolve

11) Fixed indirectly, accepted but not interested to resolve in this version (default)

12) User misunderstanding, need extra negotiation between testing & development team.

Types of defects:

01) User Interface bugs (low severity):

1) Spelling mistakes (high priority)

2) Improper alignment (low priority)

02) Boundary related bugs (medium severity)

1) Doesn’t allows valid type (high priority)

2) Allows invalid type also (low priority)

03) Error handling bugs (medium severity)

1) Doesn’t providing error message window (high priority)

2) Improper meaning of error message (low priority)

04) Calculations bugs (high severity)

1) Final output is wrong (low priority)

2) Dependent results are wrong (high priority)

05) Race condition bugs (high severity)

1) Dead lock (high priority)

2) Improper order of services (low priority)

06) Load conditions bugs (high severity)

1) Doesn’t allow multiple users to access / operate (high priority)

2) Doesn’t allow customers accepted load (low priority)

07) Hardware bugs (high severity)

1) Doesn’t handle device (high priority)

2) Wrong output from device (low priority)

08) ID control bugs (medium severity)

1) Logo missing, wrong logo, Version No mistake, Copyright window missing,

Developers Name missing, Tester Name missing

09) Version control bugs (medium severity)

1) Differences between two consecutive build versions

10) Source bugs (medium severity)

1) Mistake in help documents – Manual support

8) TEST CLOSURE:

After completion of all possible test cycle execution, Test Lead conducts a review to estimate the completeness & correctness of testing. In this review, Test Lead follows below factors with Test Engineers

1) Coverage Analysis

a) BR based coverage

b) Use Cases based coverage

c) Data model based coverage

d) User Interface based coverage

e) TRM based coverage

2) Bug density

a) Module A has 20% percentile bugs found

b) Module B has 20% percentile bugs found

c) Module C has 40% percentile bugs found

d) Module D has 20% percentile bugs found

3) Analysis of deferred bugs

Whether deferred bugs are deferrable or not

At the end of this review, Testing team concentrate on high bug density modules or all modules if time is available.

9) User Acceptance Testing (UAT)

Organization management concentrate on UAT to collect feedback, there are two approaches to conduct testing.

1. Alpha (α) test

2. Beta (β) test

10) Sign Off

After completion of User Acceptance testing & their modifications, Test Lead concentrates on final test summary report creation. It is a part of Software Release Node (S/w RN). This final test summary report consist of below documents

1) Test Strategy / Methodology (TRM)

2) System Test Plan

3) Requirement Traceability Matrix (RTM)

4) Automated Test Scripts

5) Bugs Summary Reports

The below, has to be in horizontal direction

· Bug Description

· Feature

· Found By

· Status (closed / deferred)

· Comments

CASE STUDY ON A PROJECT TESTING PROCESS

The “ X ” is a client/server product. It is running in single computer with windows 2000 as OS this product provides a facility to search matched records in existing database. w.r.t has given search keys.

Local host

This product maintains a default administrator to create new users and every valid user search data in database.

Activity flow diagram: -

Admin Admin Invalid

(Or) user

Valid user

Search keys

Existing DB

FUNCTIONAL POINTS: -

Ø Login is taking user id and password

Ø User id and password allows alphabets in lower case from 4 to 8 characters long.

Ø New user id’s created by administrators only

Ø New user creation windows allows unique user id and password with create and cancel buttons

Ø “Search records” opened for valid users only

Ø “Search records window” maintains below search keys

Customer id: 6 digits number (collected from design document

First name: one character in upper or lower

Last name: one to eight characters in lower case characters

Date of birth: dd\mm\yy in numeric

Age: “from” and “to” in numeric

Ø Search records windows allows below combination of fields to search records.

® Last name

® Last with first name

® Last name with first name and d-o-b

® Last name with first name and age

® Customer id only

Ø “Search records” window consists of “start search” and “stop search” buttons.

Ø Allows last name as full or partial

Ø Allows customer id as full or partial with * or wild card

Customer id

286*-----

2 8 6 * ------

Ø Refresh search records window using Alt+ctrl

Ø Display matched records in a pop-up window with ok button after search completion.

Ø Returns message like “too many matches to display when matched records >1000

Test methodology:- (by PM)

Testing stage	System testing
Testing Factors	System testing
Authorization	√
Access Control	√
Audit trail	×
Continuity to	√
Correctness	√
Coupling	×
Data integrity	√
Ease of use	√
Ease of operate	√
Reliability	√
Fortable	×
Performance	×
Service levels	√
Maintainable	√
Methodology	√

Note: Test responsibility matrix for IIXI (11 by 1)

Ø “X” product is maintaining metadata so

Ø it is not sharing resources of other application

Ø This application went to run on windows 2000

Ø It is a stand alone application (at time one user can operate)

So need net to test load and stress testing)

System test plan by test lead:-

Test plan ID: STP_X
Introduction: “X” is a product and it provides a facility to connect to existing data base and search matching records to retrieve.
Test items ® user creation

® Login by user

® Search records

Features to be tested: ® user creation

® Login by user

® Search records

Features not to be tested:-
Approach: To apply PM selected 1 factors from TRM, below black box testing techniques are suitable to follow depends on test lead.

® User interface testing

® Manual support testing

® Functionality testing

® i/p domain testing

® Recovery testing

® Sanitation testing

® Installation testing

® Security testing

® Complaints testing

Entry criteria: -

® Are the necessary documents available?

® Is the “X” product is ready for release from developers?

® Is the supporting database available to search required records?

® Is the test environment ready?

Suspension criteria:

® Data base disconnect may require suspension of testing

® Suspension of testing is mandatory when searching records process went to infinite.

® Admin is failed to new user creation, a decision can be mad to continue testing on “searching records” module using admin or other existing valid users.

Exit Criteria: -

® Ensure that the “X” product provides the required services

® Ensure that all test documents has been completed up to date.

®All high severity bugs resolved.

Test deliverables:-

Test cases

Test procedures Test Engg..

Automated Test scripts

Test log

Defect Report

Test environment:-

® Client pc or local host

® OS: Win2000

® DB server: ORACLE/ SQL SERVER/ MS-ACCESS

® Connectivity: DSN/ Thin Drivers

Testing Tasks:-

® Availability of admin with password

® Database consists of records

® Valid users are able to database to search records

Staff and Training needs:-

Test Engg.. / QA Engg: Kurugonda Srinaiah

Responsibilities:

Document / Report ½ Responsibility ½ Effort

1. Tst cases with procedures K.Srinaiah 12 hours

Defect Report K Srinaiah every day during Testing

Test completion reports Test Lead with At the end of the Testing

K Srinaiah

Schedule:

Task ½ Effort ½ Start date ½ End date

Test design 12 hours 28-12-2005 29-12-2005

Implement test and 4 hours 29-12-2005 29-12-2005

Review

Execute test 24 hours 30-12-2005 01-01-2006

Evaluate test 8 hours 02-01-2006 02-01-2006

Risks and mitigations:-

Lack of documentation:

® Contact business analyst

® Ad-hoc testing

® Contact customer site people if possible

Lack of time

® Over-time

Delays and delivery:

® Over time

Lack of development process reggur:

® Contact test lead to motivate developers

® Over time to complete task is right time

APPROVALS: -

Test case 1:

Signature of PM and signature of test lead.

Test case 2: Successful entry of user id

BVA (size)

Min = 4 chars ® pass

Max = 8 chars® pass

Min-1 =3 chars ® fail

Min +1 = 5 chars ® pass

Max –1 = 7 chars ® pass

Max +1 = 9 chars ® fail

Test case 3: successful entry of password

BVA (size)

Min = 4 chars ® pass

Max = 8 chars ® pass

Min –1 = 3 chars ® fail

Min +1 = 5 chars ® pass

Max + = 7 chars ® pass

Max = 9 chars ® fail

Test case 4: successful login operation

User id ½ Password ½ Criteria

Admin valid pass

Admin invalid fail

Other valid valid pass

Other valid invalid fail

Other invalid invalid fail

Blank value fail

Valid blank fail

Test case 5: Successful selection of new user creation option

Test case 6: Un successful selection of this option due to current user is not admin.

Test case 7 successful entry of user id in create user window

Note: (like as Test case2)

Test case 8: Successful entry of userid in create user window

Note: (-----------test case 3)

Test case9: Successful creation of new user by admin

Test case10: unsuccessful new user creation due to given user id is not unique.

Test case 11: successful closing of new user creation window using cancel

(After enter user id and offer enter passes)

Test case 12: Successful selection of search records option

Test case 13: successful entry of customer id

BVA (size) ECP (TYPE)

Min = max = 6 valid invalid

--------------------------

0 – 9 ½a-z, A-Z, special characters

½Expect * , blank space

½Start with *

½ Exp: 123 √, *23Х, 1*23X

Test case 14: successful entry of first name

Min = max = 1 ® pass Ecp

---------------------------

o √ fail valid ½ invalid

----------------------------

a- z o-9,

A-Z special characters

Test case 15: successful entry of last name:

Min = 1 and max = 8 ® pass ----------------

valid ½ invalid

-----------------

a- z A-Z, o-9,

Special characters

Test case 16: successful entry of DOB

BVA (range)

Ecp (type)

Day: min ® 01 -----------------

min ® 31 valid invalid

-----------------

0- 9 a-z, A-Z

Month: min ® 01 special characters

max® 12

Year: min ® 00

max® 99

Case 17: success entry of age from

Ecp(type)

min ® 01 -----------------

max® 22 valid ½ invalid

-----------------

0- 9 a-z, A-Z

Special characters

Test case 18: successful entry of age to

Note: like as above

Test case 19: successful display of matched records with full last name and all other fields are

Blank

Test case 20: successful display of matched records with full last name and first name

Test case21: successful display of matched records with full last name first name and dob

Test case22: successful display of matched records with full last name first name age

Test case 23: on successful search operation due to invalid combination of filled fields.

Test case 24: unsuccessful search operation due to invalid Dob

Test case 25: unsuccessful search operation due to age from greater than age ‘To’

Test case26: successful display of records with search key as partial last name and other fields

as blank

Test case 27:successful display of records with search key a partial last name and first name

Test case 28: successful display of records with search key as partial last name, first name and

Dob

Test case 29: successful display of records with search key as partial last name, first name

Test case 30: successful display of records with search key as customer id

Test case 31: successful display of records with search key as partial customer id with * as

wild card

Test case 32: Unsuccessful display of records due to no matching records in database w.r.to

given search keys

Test case 33: unsuccessful display of records due to “too many” records to display when no

of matched records greater than 1000

Test case 34 : successful refresh search window with Alt +Ctrl

Test case 35: Successful termination of search operation when click “stop search” button.

Test case 36: successful closing of records window through click o.k after searching.

Test case 37: spelling check in every screen

Test case 38: Graphics check in every screen

Ex: (alignment, font, size, label, graphical, colour, etc)

Usability

Testing

Test case39: Accuracy of data displayed

Ex:Dob€€€ dd\mm\yy

Test case 40: Meaninful help messages and error messages

Unit Testing

2010-03-16T01:37:00.000-07:00

Unit Testing

unit testing -

Selenium tool

2010-03-16T01:35:00.000-07:00

Selenium tool for web applications testing
selenium tool is an open source test tool for functional and regression testing
Selenium is available as plug-in of Mozilla Firefox Browser

selenium tool -

Test Management

2010-03-16T01:32:00.000-07:00

Test management

Important terms:

Test organization

Tester, test leader, test manager

Test planning and estimation

Test approach

Test progress monitoring and control

Defect density, failure rate, test control, test monitoring, test report.

Configuration management

Configuration management, version control

Risk and testing

Risk, product risk, project risk, risk-based testing

Incident Management

Incident logging, incident management

1) Test organization

a) Test organization and independence

The effectiveness of finding defects by testing and reviews can be improved by using independent testers. Options for independence are:

Ø No independent testers. Developers test their own code.

Ø Independent testers within the development teams.

Ø Independent test team or group within the organization, reporting to project management or executive management

Ø Independent testers from the business organization or user community.

Ø Independent test specialists for specific test targets such as usability testers, security testers or certification testers (who certify a software product against standards and regulations).

Ø Independent testers outsourced or external to the organization.

The benefits of independence include:

Ø Independent testers see other and different defects, and are unbiased.

Ø An independent tester can verify assumptions people made during specification and implementation of the system.

Drawbacks include:

Ø Isolation from the development team (if treated as totally independent).

Ø Independent testers may be the bottleneck as the last checkpoint.

Ø Developers may lose a sense of responsibility for quality.

b) Tasks of the test leader and tester

Test leader tasks may include:

Ø Coordinate the test strategy and plan with project managers and others.

Ø Write or review a test strategy for the project, and test policy for the organization.

Ø Contribute the testing perspective to other project activities, such as integration planning.

Ø Plan the tests – considering the context and understanding the test objectives and risks –including selecting test approaches, estimating the time, effort and cost of testing, acquiring resources, defining test levels, cycles, and planning incident management.

Ø Initiate the specification, preparation, implementation and execution of tests, monitor the test results and check the exit criteria.

Ø Adapt planning based on test results and progress (sometimes documented in status reports) and take any action necessary to compensate for problems.

Ø Set up adequate configuration management of testware for traceability.

Ø Introduce suitable metrics for measuring test progress and evaluating the quality of the testing and the product.

Ø Decide what should be automated, to what degree, and how.

Ø Select tools to support testing and organize any training in tool use for testers.

Ø Decide about the implementation of the test environment.

Ø Write test summary reports based on the information gathered during testing.

Tester tasks may include:

Ø Review and contribute to test plans.

Ø Analyze, review and assess user requirements, specifications and models for testability.

Ø Create test specifications.

Ø Set up the test environment (often coordinating with system administration and network management).

Ø Prepare and acquire test data.

Ø Implement tests on all test levels, execute and log the tests, evaluate the results and document the deviations from expected results.

Ø Use test administration or management tools and test monitoring tools as required.

Ø Automate tests (may be supported by a developer or a test automation expert).

Ø Measure performance of components and systems (if applicable).

Ø Review tests developed by others.

Note: People who work on test analysis, test design, specific test types or test automation may be specialists in these roles. Depending on the test level and the risks related to the product and the project, different people may take over the role of tester, keeping some degree of independence. Typically testers at the component and integration level would be developers; testers at the acceptance test level would be business experts and users, and testers for operational acceptance testing would be operators.

c) Defining skills test staff need

Now days a testing professional must have ‘application’ or ‘business domain’ knowledge and ‘Technology’ expertise apart from ‘Testing’ Skills

2) Test planning and estimation

a) Test planning activities

Ø Determining the scope and risks, and identifying the objectives of testing.

Ø Defining the overall approach of testing (the test strategy), including the definition of the test levels and entry and exit criteria.

Ø Integrating and coordinating the testing activities into the software life cycle activities: acquisition, supply, development, operation and maintenance.

Ø Making decisions about what to test, what roles will perform the test activities, how the test activities should be done, and how the test results will be evaluated.

Ø Scheduling test analysis and design activities.

Ø Scheduling test implementation, execution and evaluation.

Ø Assigning resources for the different activities defined.

Ø Defining the amount, level of detail, structure and templates for the test documentation.

Ø Selecting metrics for monitoring and controlling test preparation and execution, defect resolution and risk issues.

Ø Setting the level of detail for test procedures in order to provide enough information to support reproducible test preparation and execution.

b) Exit criteria

The purpose of exit criteria is to define when to stop testing, such as at the end of a test level or when a set of tests has a specific goal.

Typically exit criteria may consist of:

Ø Thoroughness measures, such as coverage of code, functionality or risk.

Ø Estimates of defect density or reliability measures.

Ø Cost.

Ø Residual risks, such as defects not fixed or lack of test coverage in certain areas.

Ø Schedules such as those based on time to market.

c) Test estimation

Two approaches for the estimation of test effort are covered in this syllabus:

The metrics-based approach: estimating the testing effort based on metrics of former or similar projects or based on typical values.

The expert-based approach: estimating the tasks by the owner of these tasks or by experts.

Once the test effort is estimated, resources can be identified and a schedule can be drawn up.

The testing effort may depend on a number of factors, including:

Characteristics of the product: the quality of the specification and other information used for test models (i.e. the test basis), the size of the product, the complexity of the problem domain, the requirements for reliability and security, and the requirements for documentation.

Characteristics of the development process: the stability of the organization, tools used, test process, skills of the people involved, and time pressure.

The outcome of testing: the number of defects and the amount of rework required.

d) Test approaches (test strategies)

One way to classify test approaches or strategies is based on the point in time at which the bulk of the test design work is begun:

v Preventative approaches, where tests are designed as early as possible.

v Reactive approaches, where test design comes after the software or system has been produced.

Typical approaches or strategies include:

Analytical approaches, such as risk-based testing where testing is directed to areas of greatest risk

Model-based approaches, such as stochastic testing using statistical information about failure rates (such as reliability growth models) or usage (such as operational profiles).

Methodical approaches, such as failure-based (including error guessing and fault-attacks), experienced-based, check-list based, and quality characteristic based.

Process- or standard-compliant approaches, such as those specified by industry-specific standards or the various agile methodologies.

Dynamic and heuristic approaches, such as exploratory testing where testing is more reactive to events than pre-planned, and where execution and evaluation are concurrent tasks.

Consultative approaches, such as those where test coverage is driven primarily by the advice and guidance of technology and/or business domain experts outside the test team.

Regression-averse approaches, such as those that include reuse of existing test material, extensive automation of functional regression tests, and standard test suites.

Different approaches may be combined, for example, a risk-based dynamic approach.

The selection of a test approach should consider the context, including:

Risk of failure of the project, hazards to the product and risks of product failure to humans, the environment and the company.
Skills and experience of the people in the proposed techniques, tools and methods.
The objective of the testing endeavour and the mission of the testing team.
Regulatory aspects, such as external and internal regulations for the development process.
The nature of the product and the business.

3) Test progress monitoring and control

a) Test progress monitoring

Percentage of work done in test case preparation (or percentage of planned test cases prepared).
Percentage of work done in test environment preparation.
Test case execution (e.g. number of test cases run/not run, and test cases passed/failed).
Defect information (e.g. defect density, defects found and fixed, failure rate, and retest results).
Test coverage of requirements, risks or code.
Subjective confidence of testers in the product.
Dates of test milestones.
Testing costs, including the cost compared to the benefit of finding the next defect or to run the next test.

b) Test Reporting

What happened during a period of testing, such as dates when exit criteria were met.

Analyzed information and metrics to support recommendations and decisions about future actions, such as an assessment of defects remaining, the economic benefit of continued testing, outstanding risks, and the level of confidence in tested software.

Metrics should be collected during and at the end of a test level in order to assess:

The adequacy of the test objectives for that test level.
The adequacy of the test approaches taken.

The effectiveness of the testing with respect to its objectives.

c) Test control

Test control describes any guiding or corrective actions taken as a result of information and metrics gathered and reported. Actions may cover any test activity and may affect any other software life cycle activity or task.

Examples of test control actions are:

Making decisions based on information from test monitoring.
Re-prioritize tests when an identified risk occurs (e.g. software delivered late).
Change the test schedule due to availability of a test environment.
Set an entry criterion requiring fixes to have been retested (confirmation tested) by a developer before accepting them into a build.

4) Configuration management

The purpose of configuration management is to establish and maintain the integrity of the products (components, data and documentation) of the software or system through the project and product life cycle.

For testing, configuration management may involve ensuring that:

All items of testware are identified, version controlled, tracked for changes, related to each other and related to development items (test objects) so that traceability can be maintained throughout the test process.
All identified documents and software items are referenced unambiguously in test documentation

For the tester, configuration management helps to uniquely identify (and to reproduce) the tested item, test documents, the tests and the test harness.

During test planning, the configuration management procedures and infrastructure (tools) should be chosen, documented and implemented.

5) Risk and testing

a) Project risks

Project risks are the risks that surround the project’s capability to deliver its objectives, such as:

Organizational factors:

skill and staff shortages;
personal and training issues;
political issues, such as

problems with testers communicating their needs and test results;
failure to follow up on information found in testing and reviews (e.g. not

improving development and testing practices).

improper attitude toward or expectations of testing (e.g. not appreciating the value of finding defects during testing).

Technical issues:

problems in defining the right requirements;
the extent that requirements can be met given existing constraints;
the quality of the design, code and tests.

Supplier issues:

failure of a third party;
contractual issues.

b) Product risks

Potential failure areas (adverse future events or hazards) in the software or system are known as product risks, as they are a risk to the quality of the product, such as:

Failure-prone software delivered.
The potential that the software/hardware could cause harm to an individual or company.
Poor software characteristics (e.g. functionality, reliability, usability and performance).
Software that does not perform its intended functions.

Risks are used to decide where to start testing and where to test more; testing is used to reduce the risk of an adverse effect occurring, or to reduce the impact of an adverse effect.

Product risks are a special type of risk to the success of a project. Testing as a risk-control activity provides feedback about the residual risk by measuring the effectiveness of critical defect removal and of contingency plans.

A risk-based approach to testing provides proactive opportunities to reduce the levels of product risk, starting in the initial stages of a project. It involves the identification of product risks and their use in guiding test planning and control, specification, preparation and execution of tests. In a risk-based approach the risks identified may be used to:

Determine the test techniques to be employed.
Determine the extent of testing to be carried out.
Prioritize testing in an attempt to find the critical defects as early as possible.
Determine whether any non-testing activities could be employed to reduce risk (e.g. providing training to inexperienced designers).

Risk-based testing draws on the collective knowledge and insight of the project stakeholders to determine the risks and the levels of testing required to address those risks.

To ensure that the chance of a product failure is minimized, risk management activities provide a disciplined approach to:

Assess (and reassess on a regular basis) what can go wrong (risks).
Determine what risks are important to deal with.
Implement actions to deal with those risks.

In addition, testing may support the identification of new risks, may help to determine what risks should be reduced, and may lower uncertainty about risks.

6) Incident management

Since one of the objectives of testing is to find defects, the discrepancies between actual and expected outcomes need to be logged as incidents. Incidents should be tracked from discovery and classification to correction and confirmation of the solution. In order to manage all incidents to completion, an organization should establish a process and rules for classification.

Incidents may be raised during development, review, testing or use of a software product. They may be raised for issues in code or the working system, or in any type of documentation including requirements, development documents, test documents, and user information such as “Help” or installation guides.

Incident reports have the following objectives:

Provide developers and other parties with feedback about the problem to enable identification, isolation and correction as necessary.
Provide test leaders a means of tracking the quality of the system under test and the progress of the testing.
Provide ideas for test process improvement.

Details of the incident report may include:

Date of issue, issuing organization, and author.
Expected and actual results.
Identification of the test item (configuration item) and environment.
Software or system life cycle process in which the incident was observed.
Description of the incident to enable reproduction and resolution, including logs, database dumps or screenshots.
Scope or degree of impact on stakeholder(s) interests.
Severity of the impact on the system.
Urgency/priority to fix.
Status of the incident (e.g. open, deferred, duplicate, waiting to be fixed, fixed awaiting retest, closed).
Conclusions, recommendations and approvals.
Global issues, such as other areas that may be affected by a change resulting from the incident.
Change history, such as the sequence of actions taken by project team members with respect to the incident to isolate, repair, and confirm it as fixed.
References, including the identity of the test case specification that revealed the problem.

Test Management -

Manual Testing Questions & Answers Part-II

2010-03-15T04:19:00.000-07:00

Manual Testing Questions and Answers

1. What is Acceptance Testing?
Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.
2. What is Accessibility Testing?
Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.).
3. What is Ad Hoc Testing?
A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. See also Monkey Testing.
4. What is Agile Testing?
Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.
5. What is Application Binary Interface (ABI)?
A specification defining requirements for portability of applications in binary forms across defferent system platforms and environments.
6. What is Application Programming Interface (API)?
A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.
7. What is Automated Software Quality (ASQ)?
The use of software tools, such as automated testing tools, to improve software quality.
8. What is Automated Testing?
Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing. The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.
9. What is Backus-Naur Form?
A metalanguage used to formally describe the syntax of a language.
10. What is Basic Block?
A sequence of one or more consecutive, executable statements containing no branches.
11. What is Basis Path Testing?
A white box test case design technique that uses the algorithmic flow of the program to design tests.
12. What is Basis Set?
The set of tests derived using basis path testing.
13. What is Baseline?
The point at which some deliverable produced during the software engineering process is put under formal change control.
14. What you will do during the first day of job?
What would you like to do five years from now?
15. What is Beta Testing?
Testing of a rerelease of a software product conducted by customers.
16. What is Binary Portability Testing?
Testing an executable application for portability across system platforms and environments, usually for conformation to an ABI specification.
17. What is Black Box Testing?
Testing based on an analysis of the specification of a piece of software without reference to its internal workings. The goal is to test how well the component conforms to the published requirements for the component.
18. What is Bottom Up Testing?
An approach to integration testing where the lowest level components are tested first, then used to facilitate the testing of higher level components. The process is repeated until the component at the top of the hierarchy is tested.

19. What is Boundary Testing?
Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).
20. What is Bug?
A fault in a program, which causes the program to perform in an unintended or unanticipated manner.
20. What is Defect?
If software misses some feature or function from what is there in requirement it is called as defect.
21. What is Boundary Value Analysis?
BVA is similar to Equivalence Partitioning but focuses on "corner cases" or values that are usually out of range as defined by the specification. his means that if a function expects all values in range of negative 100 to positive 1000, test inputs would include negative 101 and positive 1001.
22. What is Branch Testing?
Testing in which all branches in the program source code are tested at least once.
23. What is Breadth Testing?
A test suite that exercises the full functionality of a product but does not test features in detail.
24. What is CAST?
Computer Aided Software Testing.
25. What is Capture/Replay Tool?
A test tool that records test input as it is sent to the software under test. The input cases stored can then be used to reproduce the test at a later time. Most commonly applied to GUI test tools.
26. What is CMM?
The Capability Maturity Model for Software (CMM or SW-CMM) is a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.

27. What is Cause Effect Graph?
A graphical representation of inputs and the associated outputs effects which can be used to design test cases.
28. What is Code Complete?
Phase of development where functionality is implemented in entirety; bug fixes are all that are left. All functions found in the Functional Specifications have been implemented.
29. What is Code Coverage?
An analysis method that determines which parts of the software have been executed (covered) by the test case suite and which parts have not been executed and therefore may require additional attention.
30. What is Code Inspection?
A formal testing technique where the programmer reviews source code with a group who ask questions analyzing the program logic, analyzing the code with respect to a checklist of historically common programming errors, and analyzing its compliance with coding standards.
31. What is Code Walkthrough?
A formal testing technique where source code is traced by a group with a small set of test cases, while the state of program variables is manually monitored, to analyze the programmer's logic and assumptions.
32. What is Coding?
The generation of source code.
33. What is Compatibility Testing?
Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware.
34. What is Component?
A minimal software item for which a separate specification is available.
35. What is Component Testing?
Testing of individual software components (Unit Testing).

36. What is Concurrency Testing?
Multi-user testing geared towards determining the effects of accessing the same application code, module or database records. Identifies and measures the level of locking, deadlocking and use of single-threaded code and locking semaphores.
37. What is Conformance Testing?
The process of testing that an implementation conforms to the specification on which it is based. Usually applied to testing conformance to a formal standard.
38. What is Context Driven Testing?
The context-driven school of software testing is flavor of Agile Testing that advocates continuous and creative evaluation of testing opportunities in light of the potential information revealed and the value of that information to the organization right now.
39. What is Conversion Testing?
Testing of programs or procedures used to convert data from existing systems for use in replacement systems.
40. What is Cyclomatic Complexity?
A measure of the logical complexity of an algorithm, used in white-box testing.
41. What is Data Dictionary?
A database that contains definitions of all data items defined during analysis.
42. What is Data Flow Diagram?
A modeling notation that represents a functional decomposition of a system.
43. What is Data Driven Testing?
Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet. A common technique in Automated Testing.
44. What is Debugging?
The process of finding and removing the causes of software failures.
45. What is Defect?
Nonconformance to requirements or functional / program specification

46. What is Dependency Testing?
Examines an application's requirements for pre-existing software, initial states and configuration in order to maintain proper functionality.
47. What is Depth Testing?
A test that exercises a feature of a product in full detail.
48. What is Dynamic Testing?
Testing software through executing it. See also Static Testing.
49. What is Emulator?
A device, computer program, or system that accepts the same inputs and produces the same outputs as a given system.
50. What is Endurance Testing?
Checks for memory leaks or other problems that may occur with prolonged execution
51. What is End-to-End testing?
Testing a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
52. What is Equivalence Class?
A portion of a component's input or output domains for which the component's behaviour is assumed to be the same from the component's specification.
53. What is Equivalence Partitioning?
A test case design technique for a component in which test cases are designed to execute representatives from equivalence classes.
54. What is Exhaustive Testing?
Testing which covers all combinations of input values and preconditions for an element of the software under test.
55. What is Functional Decomposition?
A technique used during planning, analysis and design; creates a functional hierarchy for the software.

54. What is Functional Specification?
A document that describes in detail the characteristics of the product with regard to its intended features.
55. What is Functional Testing?
Testing the features and operational behavior of a product to ensure they correspond to its specifications. Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions. or Black Box Testing.
56. What is Glass Box Testing?
A synonym for White Box Testing.
57. What is Gorilla Testing?
Testing one particular module, functionality heavily.
58. What is Gray Box Testing?
A combination of Black Box and White Box testing methodologies? testing a piece of software against its specification but using some knowledge of its internal workings.
59. What is High Order Tests?
Black-box tests conducted once the software has been integrated.
60. What is Independent Test Group (ITG)?
A group of people whose primary responsibility is software testing,
61. What is Inspection?
A group review quality improvement process for written material. It consists of two aspects; product (document itself) improvement and process improvement (of both document production and inspection).
62. What is Integration Testing?
Testing of combined parts of an application to determine if they function together correctly. Usually performed after unit and functional testing. This type of testing is especially relevant to client/server and distributed systems.
63. What is Installation Testing?
Confirms that the application under test recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions.
64. What is Load Testing?
See Performance Testing.
65. What is Localization Testing?
This term refers to making software specifically designed for a specific locality.
66. What is Loop Testing?
A white box testing technique that exercises program loops.
67. What is Metric?
A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.
68. What is Monkey Testing?
Testing a system or an Application on the fly, i.e just few tests here and there to ensure the system or an application does not crash out.
69. What is Negative Testing?
Testing aimed at showing software does not work. Also known as "test to fail". See also Positive Testing.
70. What is Path Testing?
Testing in which all paths in the program source code are tested at least once.
71. What is Performance Testing?
Testing conducted to evaluate the compliance of a system or component with specified performance requirements. Often this is performed using an automated test tool to simulate large number of users. Also know as "Load Testing".
72. What is Positive Testing?
Testing aimed at showing software works. Also known as "test to pass". See also Negative Testing.
73. What is Quality Assurance?
All those planned or systematic actions necessary to provide adequate confidence that a product or service is of the type and quality needed and expected by the customer.

74. What is Quality Audit?
A systematic and independent examination to determine whether quality activities and related results comply with planned arrangements and whether these arrangements are implemented effectively and are suitable to achieve objectives.
75. What is Quality Circle?
A group of individuals with related interests that meet at regular intervals to consider problems or other matters related to the quality of outputs of a process and to the correction of problems or to the improvement of quality.
76. What is Quality Control?
The operational techniques and the activities used to fulfill and verify requirements of quality.
77. What is Quality Management?
That aspect of the overall management function that determines and implements the quality policy.
78. What is Quality Policy?
The overall intentions and direction of an organization as regards quality as formally expressed by top management.
79. What is Quality System?
The organizational structure, responsibilities, procedures, processes, and resources for implementing quality management.
80. What is Race Condition?
A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a write, with no mechanism used by either to moderate simultaneous access.
81. What is Ramp Testing?
Continuously raising an input signal until the system breaks down.
82. What is Recovery Testing?
Confirms that the program recovers from expected or unexpected events without loss of data or functionality. Events can include shortage of disk space, unexpected loss of communication, or power out conditions

83. What is Regression Testing?
Retesting a previously tested program following modification to ensure that faults have not been introduced or uncovered as a result of the changes made.
84. What is Release Candidate?
A pre-release version, which contains the desired functionality of the final version, but which needs to be tested for bugs (which ideally should be removed before the final version is released).
85. What is Sanity Testing?
Brief test of major functional elements of a piece of software to determine if its basically operational. See also Smoke Testing.
86. What is Scalability Testing?
Performance testing focused on ensuring the application under test gracefully handles increases in work load.
87. What is Security Testing?
Testing which confirms that the program can restrict access to authorized personnel and that the authorized personnel can access the functions available to their security level.
88. What is Smoke Testing?
A quick-and-dirty test that the major functions of a piece of software work. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.
89. What is Soak Testing?
Running a system at high load for a prolonged period of time. For example, running several times more transactions in an entire day (or night) than would be expected in a busy day, to identify and performance problems that appear after a large number of transactions have been executed.
90. What is Software Requirements Specification?
A deliverable that describes all data, functional and behavioral requirements, all constraints, and all validation requirements for software/
91. What is Software Testing?
A set of activities conducted with the intent of finding errors in software.

92. What is Static Analysis?
Analysis of a program carried out without executing the program.
93. What is Static Analyzer?
A tool that carries out static analysis.
94. What is Static Testing?
Analysis of a program carried out without executing the program.
95. What is Storage Testing?
Testing that verifies the program under test stores data files in the correct directories and that it reserves sufficient space to prevent unexpected termination resulting from lack of space. This is external storage as opposed to internal storage.
96. What is Stress Testing?
Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.
97. What is Structural Testing?
Testing based on an analysis of internal workings and structure of a piece of software. See also White Box Testing.
98. What is System Testing?
Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.
99. What is Testability?
The degree to which a system or component facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.
100. What is Testing?
The process of exercising software to verify that it satisfies specified requirements and to detect errors. The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs), and to evaluate the features of the software item (Ref. IEEE Std 829). The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. What is Test Automation? It is the same as Automated Testing.
101. 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.
102. 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.
103. What is Test Driver?
A program or test tool used to execute tests. Also known as a Test Harness.
104. 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.
105. 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.
106. What is Test Harness?
A program or test tool used to execute a tests. Also known as a Test Driver.
107. 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.
108. What is Test Procedure?
A document providing detailed instructions for the execution of one or more test cases.
109. 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.
110. 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.
111. 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.
112. What is Test Tools?
Computer programs used in the testing of a system, a component of the system, or its documentation.
113. 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.
114. 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.
115. What is Total Quality Management?
A company commitment to develop a process that achieves high quality product and customer satisfaction.
116. What is Traceability Matrix?
A document showing the relationship between Test Requirements and Test Cases.
117. What is Usability Testing?
Testing the ease with which users can learn and use a product.
118. 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.
119. What is Unit Testing?
Testing of individual software components.
120. how do the companies expect the defect reporting to be communicated by the tester to the development team. Can the excel sheet template be used for defect reporting. If so what are the common fields that are to be included ? who assigns the priority and severity of the defect
To report bugs in excel:
Sno. Module Screen/ Section Issue detail Severity
Prioriety Issuestatus
this is how to report bugs in excel sheet and also set filters on the Columns attributes.
But most of the companies use the share point process of reporting bugs In this when the project came for testing a module wise detail of project is inserted to the defect managment system they are using. It contains following field
1. Date
2. Issue brief
3. Issue discription(used for developer to regenrate the issue)
4. Issue satus( active, resolved, onhold, suspend and not able to regenrate)
5. Assign to (Names of members allocated to project)
6. Prioriety(High, medium and low)
7. Severity (Major, medium and low)

121. How do you plan test automation?
1. Prepare the automation Test plan
2. Identify the scenario
3. Record the scenario
4. Enhance the scripts by inserting check points and Conditional Loops
5. Incorporated Error Hnadler
6. Debug the script
7. Fix the issue
8. Rerun the script and report the result
122. Does automation replace manual testing?
There can be some functionality which cannot be tested in an automated tool so we may have to do it manually. therefore manual testing can never be repleaced. (We can write the scripts for negative testing also but it is hectic task).When we talk about real environment we do negative testing manually.
123. How will you choose a tool for test automation?
choosing of a tool deends on many things ...
1. Application to be tested
2. Test environment
3. Scope and limitation of the tool.
4. Feature of the tool.
5. Cost of the tool.
6. Whether the tool is compatible with your application which means tool should be able to interact with your appliaction
7. Ease of use
124. How you will evaluate the tool for test automation?
We need to concentrate on the features of the tools and how this could be benficial for our project. The additional new features and the enhancements of the features will also help.
125. How you will describe testing activities?
Testing activities start from the elaboration phase. The various testing activities are preparing the test plan, Preparing test cases, Execute the test case, Log teh bug, validate the bug & take appropriate action for the bug, Automate the test cases.
126. What testing activities you may want to automate?
Automate all the high priority test cases which needs to be exceuted as a part of regression testing for each build cycle.
127. Describe common problems of test automation.
The commom problems are:
1. Maintenance of the old script when there is a feature change or enhancement
2. The change in technology of the application will affect the old scripts
128. What types of scripting techniques for test automation do you know?
5 types of scripting techniques:
Linear
Structured
Shared
Data Driven
Key Driven
129. What is memory leaks and buffer overflows ?
Memory leaks means incomplete deallocation - are bugs that happen very often. Buffer overflow means data sent as input to the server that overflows the boundaries of the input area, thus causing the server to misbehave. Buffer overflows can be used.

130. What are the major differences between stress testing,load testing,Volume testing?
Stress testing means increasing the load ,and cheking the performance at each level. Load testing means at a time giving more load by the expectation and cheking the performance at that leval. Volume testing means first we have to apply initial.

software testing interview questions -

Manual Testing Questions and Answers Part-I

2010-03-15T04:17:00.000-07:00

Manual Testing FAQS Part-I

Q: How do you introduce a new software QA process?

A: It depends on the size of the organization and the risks involved. For large organizations with high-risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required. Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and
testable.

Q: What is the role of documentation in QA?

A: Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining of documents and determining what document will have a particular piece of information. Use documentation change management, if possible.

Q: What makes a good test engineer?

A: Good test engineers have a "test to break" attitude. We, good test engineers, take the point of view of the customer; have 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 and non-technical people. Previous software development experience is also helpful as it provides a deeper understanding of the software development process, gives the test engineer an appreciation for the developers' point of view and reduces the learning curve in automated test tool programming.

Rob Davis is a good test engineer because he has a "test to break" attitude, takes the point of view of the customer, has a strong desire for quality, has an attention to detail, He's also tactful and diplomatic and has good a communication skill, both oral and written. And he has previous software development experience, too.

Q: What is a test plan?

A: A software project test plan is a document that describes the objectives, scope, approach and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it.

Q: What is a test case?

A: A test case is a document that describes an input, action, or event and its expected result, in order to determine if a feature of an application is working correctly. A test case should contain particulars such as a...

Test case identifier;
Test case name;
Objective;
Test conditions/setup;
Input data requirements/steps, and
Expected results.

Please note, the process of developing test cases can help find problems in the requirements or design of an application, since it requires you to completely think through the operation of the application. For this reason, it is useful to prepare test cases early in the development cycle, if possible.

Q: What should be done after a bug is found?

A: When a bug is found, it needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere. If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea of its severity, reproduce it and fix it.

Q: What is configuration management?

A: Configuration management (CM) covers the tools and 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. Rob Davis has had experience with a full range of CM tools and concepts, and can easily adapt to your software tool and process needs.

Q: What if the software is so buggy it can't be tested at all?

A: In this situation the best bet is to have test engineers go through the process of reporting whatever bugs or 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, insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.

Q: What if there isn't enough time for thorough testing?

A: 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.

Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions:

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?

Q: What if the project isn't big enough to justify extensive testing?

A: 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 considerations listed under "What if there isn't enough time for thorough testing?" do apply. The test engineer then should do "ad hoc" testing, or write up a limited test plan based on the risk analysis.

Q: What can be done if requirements are changing continuously?

A: Work with management early on to understand how requirements might change, so that alternate test plans and strategies can be worked out in advance. It is helpful if the application's initial design allows for some adaptability, so that later changes do not require redoing the application from scratch. Additionally, try to...

Ensure the code is well commented and well documented; this makes changes easier for the developers.
Use rapid prototyping whenever possible; this will help customers feel sure of their requirements and minimize changes.
In the project's initial schedule, allow for some extra time to commensurate with probable changes.

Move new requirements to a 'Phase 2' version of an application and use the original requirements for the 'Phase 1' version.

Negotiate to allow only easily implemented new requirements into the project.

Ensure customers and management understand scheduling impacts, inherent risks and costs of significant requirements changes. Then let management or the customers 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 redo them to deal with changes.
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, in order to minimize regression-testing needs;
Design some flexibility into test cases; this is not easily done; the best bet is 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 this entails.

Q: How do you know when to stop testing?

A: 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, e.g. release deadlines, testing deadlines;
Test cases completed with certain percentage passed;
Test budget has been depleted;
Coverage of code, functionality, or requirements reaches a specified point;
Bug rate falls below a certain level; or
Beta or alpha testing period ends.

Q: What if the application has functionality that wasn't in the requirements?

A: It may take serious effort to determine if an application has significant unexpected or hidden functionality, which 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 affects areas, such as minor improvements in the user interface, it may not be a significant risk.

Q: How can software QA processes be implemented without stifling productivity?

A: Implement QA processes slowly over time. Use consensus to reach agreement on processes and adjust and experiment as an organization grows and matures. Productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection. Panics and burnout 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, like 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.

Q: What if the organization is growing so fast that fixed QA processes are impossible?

A: 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 (i.e. hire Rob Davis)
Ruthlessly prioritize quality issues and maintain focus on the customer;
Everyone in the organization should be clear on what quality means to the customer.

Q: Why do you recommend that we test during the design phase?

A: Because testing during the design phase can prevent defects later on. We recommend verifying three things...

Verify the design is good, efficient, compact, testable and maintainable.
Verify the design meets the requirements and is complete (specifies all relationships between modules, how to pass data, what happens in exceptional circumstances, starting state of each module and how to guarantee the state of each module).
Verify the design incorporates enough memory, I/O devices and quick enough runtime for the final product.

Q: What is software quality assurance?

A: Software Quality Assurance, when Rob Davis does it, is oriented to *prevention*. It involves the entire software development process. Prevention is monitoring and improving the process, making sure any agreed-upon standards and procedures are followed and ensuring problems are found and dealt with.

Software Testing, when performed by Rob Davis, is also oriented to *detection*. Testing involves the operation of a system or application under controlled conditions and evaluating the results.

Rob Davis can provide QA/testing service. This document details some aspects of how he can provide software testing/QA service. For more information, e-mail rob@robdavispe.com.

Organizations vary considerably in how they assign responsibility for QA and testing. Sometimes they're the combined responsibility of one group or individual.

Also common are project teams, which include a mix of test engineers, testers and developers, who work closely together, with overall QA processes monitored by project managers.

Software quality assurance depends on what best fits your organization's size and business structure.

Q: How is testing affected by object-oriented designs?

A: A 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.

Q: What is quality assurance?

A: Quality Assurance ensures all parties concerned with the project adhere to the process and procedures, standards and templates and test readiness reviews.

Rob Davis' QA service depends on the customers and projects. A lot will depend on team leads or managers, feedback to developers and communications among customers, managers, developers' test engineers and testers.

Q: What is black box testing?

A: Black box testing is functional testing, not based on any knowledge of internal software design or code. Black box testing are based on requirements and functionality.

Q: What is white box testing?

A: White box testing is based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths and conditions.

Q: What is unit testing?

A: Unit testing is the first level of dynamic testing and is first the responsibility of developers and then that of the test engineers.

Unit testing is performed after the expected test results are met or differences are explainable/acceptable.

Q: What is functional testing?

A: Functional testing is black-box type of testing geared to functional requirements of an application. Test engineers *should* perform functional testing.

Q: What is usability testing?

A: Usability testing is testing for 'user-friendliness'. Clearly this is subjective and depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions and other techniques can be used. Programmers and developers are usually not appropriate as usability testers.

Q: What is incremental integration testing?

A: Incremental integration testing is continuous testing of an application as new functionality is recommended. This may require that various aspects of an application's functionality are independent enough to work separately, before all parts of the program are completed, or that test drivers are developed as needed.

Incremental testing may be performed by programmers, software engineers, or test engineers.

Q: What is parallel/audit testing?

A: Parallel/audit testing is testing where the user reconciles the output of the new system to the output of the current system to verify the new system performs the operations correctly.

Q: What is integration testing?

A: Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements.

Test cases are developed with the express purpose of exercising the interfaces between the components. This activity is carried out by the test team.

Integration testing is considered complete, when actual results and expected results are either in line or differences are explainable/acceptable based on client input.

Q: What is system testing?

A: System testing is black box testing, performed by the Test Team, and at the start of the system testing the complete system is configured in a controlled environment.

The purpose of system testing is to validate an application's accuracy and completeness in performing the functions as designed.

System testing simulates real life scenarios that occur in a "simulated real life" test environment and test all functions of the system that are required in real life.

System testing is deemed complete when actual results and expected results are either in line or differences are explainable or acceptable, based on client input.

Upon completion of integration testing, system testing is started. Before system testing, all unit and integration test results are reviewed by Software QA to ensure all problems have been resolved. For a higher level of testing it is important to understand unresolved problems that originate at unit and integration test levels.

You CAN learn system testing, with little or no outside help. Get CAN get free information. Click on a link!

Q: What is end-to-end testing?

A: Similar to system testing, the *macro* end of the test scale is testing a complete application in a situation that mimics real world use, such as interacting with a database, using network communication, or interacting with other hardware, application, or system.

Q: What is regression testing?

A: The objective of regression testing is to ensure the software remains intact. A baseline set of data and scripts is maintained and executed to verify changes introduced during the release have not "undone" any previous code. Expected results from the baseline are compared to results of the software under test. All discrepancies are highlighted and accounted for, before testing proceeds to the next level.

Q: What is sanity testing?

A: Sanity testing is performed whenever cursory testing is sufficient to prove the application is functioning according to specifications. This level of testing is a subset of regression testing.

It normally includes a set of core tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.

Q: What is performance testing?

A: Although performance testing is described as a part of system testing, it can be regarded as a distinct level of testing. Performance testing verifies loads, volumes and response times, as defined by requirements.

Q: What is load testing?

A: Load testing is testing an application under heavy loads, such as the testing of a web site under a range of loads to determine at what point the system response time will degrade or fail.

Q: What is installation testing?

A: Installation testing is testing full, partial, upgrade, or install/uninstall processes. The installation test for a release is conducted with the objective of demonstrating production readiness.

Q: What is security/penetration testing?

A: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage.

This type of testing usually requires sophisticated testing techniques.

Q: What is recovery/error testing?

A: Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Q: What is compatibility testing?

A: Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network

This test includes the inventory of configuration items, performed by the application's System Administration, the evaluation of data readiness, and dynamic tests focused on basic system functionality. When necessary, a sanity test is performed, following installation testing.

Q: What is security/penetration testing?

A: Security/penetration testing is testing how well the system is protected against unauthorized internal or external access, or willful damage.

This type of testing usually requires sophisticated testing techniques.

Q: What is recovery/error testing?

A: Recovery/error testing is testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Q: What is compatibility testing?

A: Compatibility testing is testing how well software performs in a particular hardware, software, operating system, or network

Q: What is comparison testing?

A: Comparison testing is testing that compares software weaknesses and strengths to those of competitors' products.

Q: What is acceptance testing?

A: Acceptance testing is black box testing that gives the client/customer/project manager the opportunity to verify the system functionality and usability prior to the system being released to production.

The acceptance test is the responsibility of the client/customer or project manager, however, it is conducted with the full support of the project team. The test team also works with the client/customer/project manager to develop the acceptance criteria.

Q: What is alpha testing?

A: Alpha testing is testing of an application when development is nearing completion. Minor design changes can still be made as a result of alpha testing. Alpha testing is typically performed by a group that is independent of the design team, but still within the company, e.g. in-house software test engineers, or software QA engineers.

Q: What is beta testing?

A: Beta testing is testing an application when development and testing are essentially completed and final bugs and problems need to be found before the final release. Beta testing is typically performed by end-users or others, not programmers, software engineers, or test engineers.

Q: What is a Test/QA Team Lead?

A: The Test/QA Team Lead coordinates the testing activity, communicates testing status to management and manages the test team.

Q: What testing roles are standard on most testing projects?

A: Depending on the organization, the following roles are more or less standard on most testing projects: Testers, Test Engineers, Test/QA Team Lead, Test/QA Manager, System Administrator, Database Administrator, Technical Analyst, Test Build Manager and Test Configuration Manager.

Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of Technical Analyst, Test Build Manager and Test Configuration Manager.

You CAN get a job in testing. Click on a link!

Q: What is a Test Engineer?

A: We, test engineers, are engineers who specialize in testing. We, test engineers, create test cases, procedures, scripts and generate data. We execute test procedures and scripts, analyze standards of measurements, evaluate results of system/integration/regression testing. We also...

Speed up the work of the development staff;
Reduce your organization's risk of legal liability;
Give you the evidence that your software is correct and operates properly;
Improve problem tracking and reporting;
Maximize the value of your software;
Maximize the value of the devices that use it;
Assure the successful launch of your product by discovering bugs and design flaws, before users get discouraged, before shareholders loose their cool and before employees get bogged down;
Help the work of your development staff, so the development team can devote its time to build up your product;
Promote continual improvement;
Provide documentation required by FDA, FAA, other regulatory agencies and your customers;
Save money by discovering defects 'early' in the design process, before failures occur in production, or in the field;
Save the reputation of your company by discovering bugs and design flaws; before bugs and design flaws damage the reputation of your company.

: What is a Test Build Manager?

A: Test Build Managers deliver current software versions to the test environment, install the application's software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware.

Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Test Build Manager.

Q: What is a System Administrator?

A: Test Build Managers, System Administrators, Database Administrators deliver current software versions to the test environment, install the application's software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware.

Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a System Administrator.

Q: What is a Database Administrator?

A: Test Build Managers, System Administrators and Database Administrators deliver current software versions to the test environment, install the application's software and apply software patches, to both the application and the operating system, set-up, maintain and back up test environment hardware. Depending on the project, one person may wear more than one hat. For instance, a Test Engineer may also wear the hat of a Database Administrator.

Q: What is a Technical Analyst?

A: Technical Analysts perform test assessments and validate system/functional test requirements. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Technical Analyst.

Q: What is a Test Configuration Manager?

A: Test Configuration Managers maintain test environments, scripts, software and test data. Depending on the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat of a Test Configuration Manager.

Q: What is a test schedule?

A: The test schedule is a schedule that identifies all tasks required for a successful testing effort, a schedule of all test activities and resource requirements.

Q: What is software testing methodology?

A: One software testing methodology is the use a three step process of...

Creating a test strategy;
Creating a test plan/design; and
Executing tests.

This methodology can be used and molded to your organization's needs. Rob Davis believes that using this methodology is important in the development and ongoing maintenance of his clients' applications.

Q: What is the general testing process?

A: The general testing process is the creation of a test strategy (which sometimes includes the creation of test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the execution of tests.

Q: How do you create a test plan/design?

A: Test scenarios and/or cases are prepared by reviewing functional requirements of the release and preparing logical groups of functions that can be further broken into test procedures. Test procedures define test conditions, data to be used for testing and expected results, including database updates, file outputs, report results. Generally speaking...

Test cases and scenarios are designed to represent both typical and unusual situations that may occur in the application.
Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test cases.
It is the test team that, with assistance of developers and clients, develops test cases and scenarios for integration and system testing.
Test scenarios are executed through the use of test procedures or scripts.
Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.
Test procedures or scripts include the specific data that will be used for testing the process or transaction.
Test procedures or scripts may cover multiple test scenarios.
Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test is within scope.

Test data is captured and base lined, prior to testing. This data serves as the foundation for unit and system testing and used to exercise system functionality in a controlled environment.
Some output data is also base-lined for future comparison. Base-lined data is used to support future application maintenance via regression testing.
A pretest meeting is held to assess the readiness of the application and the environment and data to be tested. A test readiness document is created to indicate the status of the entrance criteria of the release.

Inputs for this process:

Approved Test Strategy Document.
Test tools, or automated test tools, if applicable.
Previously developed scripts, if applicable.
Test documentation problems uncovered as a result of testing.
A good understanding of software complexity and module path coverage, derived from general and detailed design documents, e.g. software design document, source code, and software complexity data.

Outputs for this process:

Approved documents of test scenarios, test cases, test conditions, and test data.
Reports of software design issues, given to software developers for correction.

Q: How do you execute tests?

A: Execution of tests is completed by following the test documents in a methodical manner. As each test procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure and whether or not the test procedure uncovered any defects. Checkpoint meetings are held throughout the execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing issues, status and activities.

The output from the execution of test procedures is known as test results. Test results are evaluated by test engineers to determine whether the expected results have been obtained. All discrepancies/anomalies are logged and discussed with the software team lead, hardware test lead, programmers, software engineers and documented for further investigation and resolution. Every company has a different process for logging and reporting bugs/defects uncovered during testing.
A pass/fail criteria is used to determine the severity of a problem, and results are recorded in a test summary report. The severity of a problem, found during system testing, is defined in accordance to the customer's risk assessment and recorded in their selected tracking tool.
Proposed fixes are delivered to the testing environment, based on the severity of the problem. Fixes are regression tested and flawless fixes are migrated to a new baseline. Following completion of the test, members of the test team prepare a summary report. The summary report is reviewed by the Project Manager, Software QA Manager and/or Test Team Lead.

After a particular level of testing has been certified, it is the responsibility of the Configuration Manager to coordinate the migration of the release software components to the next test level, as documented in the Configuration Management Plan. The software is only migrated to the production environment after the Project Manager's formal acceptance.
The test team reviews test document problems identified during testing, and update documents where appropriate.

Inputs for this process:

Approved test documents, e.g. Test Plan, Test Cases, Test Procedures.
Test tools, including automated test tools, if applicable.
Developed scripts.
Changes to the design, i.e. Change Request Documents.
Test data.
Availability of the test team and project team.
General and Detailed Design Documents, i.e. Requirements Document, Software Design Document.
A software that has been migrated to the test environment, i.e. unit tested code, via the Configuration/Build Manager.
Test Readiness Document.
Document Updates.

Outputs for this process:

Log and summary of the test results. Usually this is part of the Test Report. This needs to be approved and signed-off with revised testing deliverables.
Changes to the code, also known as test fixes.
Test document problems uncovered as a result of testing. Examples are Requirements document and Design Document problems.
Reports on software design issues, given to software developers for correction. Examples are bug reports on code issues.
Formal record of test incidents, usually part of problem tracking.
Base-lined package, also known as tested source and object code, ready for migration to the next level.

Q: How do you create a test strategy?

A: The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.

Inputs for this process:

A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.
A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.
Testing methodology. This is based on known standards.
Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.
Requirements that the system can not provide, e.g. system limitations.

Outputs for this process:

An approved and signed off test strategy document, test plan, including test cases.
Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.

Q: What is security clearance?

A: Security clearance is a process of determining your trustworthiness and reliability before granting you access to national security information.

Q: What are the levels of classified access?

A: The levels of classified access are confidential, secret, top secret, and sensitive compartmented information, of which top secret is the highest.

What's a 'test plan'?

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:

* Title

* Identification of software including version/release numbers.

* Revision history of document including authors, dates, approvals.

* Table of Contents.

* Purpose of document, intended audience

* Objective of testing effort

* Software product overview

* Relevant related document list, such as requirements, design documents, other test plans, etc.

* Relevant standards or legal requirements

* Traceability requirements

* Relevant naming conventions and identifier conventions

* Overall software project organization and personnel/contact-info/responsibilties

* Test organization and personnel/contact-info/responsibilities

* Assumptions and dependencies

* Project risk analysis

* Testing priorities and focus

* Scope and limitations of testing

* Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable

* Outline of data input equivalence classes, boundary value analysis, error classes

* Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems

* Test environment validity analysis - differences between the test and production systems and their impact on test validity.

* Test environment setup and configuration issues

* Software migration processes

* Software CM processes

* Test data setup requirements

* Database setup requirements

* Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs

* Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs

* Test automation - justification and overview

* Test tools to be used, including versions, patches, etc.

* Test script/test code maintenance processes and version control

* Problem tracking and resolution - tools and processes

* Project test metrics to be used

* Reporting requirements and testing deliverables

* Software entrance and exit criteria

* Initial sanity testing period and criteria

* Test suspension and restart criteria

* Personnel allocation

* Personnel pre-training needs

* Test site/location

* Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues.

* Relevant proprietary, classified, security, and licensing issues.

* Open issues

* Appendix - glossary, acronyms, etc.

What's a 'test case'?

* A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.

* Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it's useful to prepare test cases early in the development cycle if possible.

What should be done after a bug is found?

* The bug needs to be communicated and assigned to developers that can fix it. After the problem is resolved, fixes should be re-tested, and determinations made regarding requirements for regression testing to check that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it should encapsulate these processes. A variety of commercial problem-tracking/management software tools are available (see the 'Tools' section for web resources with listings of such tools). The following are items to consider in the tracking process:

* Complete information such that developers can understand the bug, get an idea of it's severity, and reproduce it if necessary.
* Bug identifier (number, ID, etc.)

* Current bug status (e.g., 'Released for Retest', 'New', etc.)

* The application name or identifier and version

* The function, module, feature, object, screen, etc. where the bug occurred

* Environment specifics, system, platform, relevant hardware specifics

* Test case name/number/identifier

* One-line bug description

* Full bug description

* Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn't have easy access to the test case/test script/test tool

* Names and/or descriptions of file/data/messages/etc. used in test

* File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem

* Severity estimate (a 5-level range such as 1-5 or 'critical'-to-'low' is common)

* Was the bug reproducible?

* Tester name

* Test date

* Bug reporting date

* Name of developer/group/organization the problem is assigned to

* Description of problem cause

* Description of fix

* Code section/file/module/class/method that was fixed

* Date of fix

* Application version that contains the fix

* Tester responsible for retest

* Retest date

* Retest results

* Regression testing requirements

* Tester responsible for regression tests

* Regression testing results

* A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers.

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.

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

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?

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.

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).
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.

How can 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 bureacracy, 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. (See the Books section's 'Software QA', 'Software Engineering', and 'Project Management' categories for useful books with more information.)

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

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. (See the 'Tools' section for web resources with listings that include these kinds of test tools.)

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:

How is testing affected by object-oriented designs?

* 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?

* Will down time for server and content maintenance/upgrades be allowed? how much?

* 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.
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' (See the Softwareqatest.com Books page.). 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 develope 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.

manual testing interview questions -

Configuration Management

2010-03-15T02:29:00.001-07:00

Configuration Management

What are Software Configuration Management Best Practices?

The best practices of Software Configuration Management are as follows

Identify and store artifacts in a secure repository
Control and audit changes to artifacts
Organize artifacts into versioned components

Components reduce complexity
It is easier to identify the quality level of a particular component baseline than that of numerous individual files
Instantiating a physical component object in a tool helps institutionalize component sharing and reuse
Mapping logical design components to physical SCM components helps preserve the integrity of software architectures

Create baselines at project milestones
Record and track requests for change
Organize and integrate consistent sets of versions using activities
Maintain stable and consistent workspaces
Support concurrent changes to artifacts and components
Integrate early and often
Ensure reproducibility of software builds

What are the problems of not using Software Configuration Management (SCM)?

Multiple people have to work on software that is changing More than one version of the software has to be supported ie: Released systems, Custom configured systems, System(s) under development

What is a Software Configuration Management tool?

Software tools that automate and facilitate the application of the Software Configuration Management best practices.

What are Software Configuration Management processes?

The way SCM is performed on your project, specifically how an SCM tool is applied to accomplish a set of tasks

How can Software Configuration Management followed without tools?

Using File Copies to Support Early SCM - Storing backup versions of the software system - Storing intermediate working versions, of certain files or of all the files that make up the system, during the development process

How can we use Shared Copy Approach for Software Configuration Management?
An additional copy of the entire system directory structure can be created to store the latest versions of the software.

What are the Problems of not using Software Configuration Management tools?

The copy-over problem, which causes versions of files to be lost Recovery from inappropriate changes made to the common code is difficult or impossible The number of uncontrolled copies of files makes it difficult to determine where the

latest version really exists

What is a Version?

A specific instance of a baseline or configuration item is known as Version.

What is Configuration?

Configuration is a collection of all the elements of a baseline and a description of how they fit together.

What is Baseline?

One or more software configuration items that have been formally reviewed and agreed upon and serve as a basis for further development

What baselines are required to be defined and managed?

Typically aligned with major milestones. Applies to documents as well as code.

How is the current software configuration defined?

A snapshot of everything the product has produced at some point in time.

Who must approve changes to baselines?

Usually the Change Control Board (CCB) must approve changes to baselines.

What is the responsibility of Configuration Control Board?

Group with the responsibility for reviewing and approving changes to baselines

How are baselines verified?

By reviews, inspections, and the testing of code

How and when are baselines created and physically controlled?

Through the use of document control systems, code control tools, and procedures to prevent the making of unapproved changes

Are baselines tied to project milestones?

Many are, but during coding many may not be tied to project milestones

What is Software Configuration Item?

A collection of software elements treated as a unit for the purposes of Software Configuration Management

What are the components of clear case?

Version Control Workspace Management Build Management Process Control

What is Version Control?

Version Control allows different projects to use the same source files at the same time It isolates work that is not ready to be shared by the rest of the project. It isolates work that should never be shared. It allows software engineers to continue development along a branch even when a line of development is frozen.

What is the use of Version Control?

Allows different projects to use the same source files at the same time Isolates

work that is not ready to be shared by the rest of the project Isolates work that should never be shared Allows software engineers to continue development along a branch even when a line of development is frozen

What is the use of workspace?

Software engineers need a consistent and reproducible workspace area (a sandbox) in which they can develop and debug their code. They need to be able to share project files while shielding the project from the instability of their evolving code

What is Change Control?

Proposed changes to baselines must have some level of review. The impact of proposed changes must be identified and understood. When appropriate the approval of the CCB, key managers and project members must be obtained Approved changes must be properly implemented After changes are made all affected parties must be notified

What is UCM (Unified Change Management)?

It unifies the activities used to plan and track project progress with the artifacts being changed.

What is a view?

A way of seeing the objects in one or more VOBs (Versioned Object Base) Version selection is based on user-defined rules

What are the types of Views?

There are two types of views. They are Dynamic View: VOB objects are displayed from the VOB cache Snapshot View: VOB objects are copied to the client.

What is a view?

Selects versions of VOB directories and Files. It enables developers to work in parallel.

What are the different types of checkouts used in modern Software Configuration Management tools?

Modern Software Configuration Management tools support both reserved and unreserved checkouts.

What is the tool which supports Component-based Development?

ClearCase UCM is the tool which support component -based development.

What is Activity-based Configuration Management?

Configuration Management based on task, defect and enhancement is known as Activity-based Configuration Management.

What is the basic concept of ClearCase UCM?

The ClearCase UCM is working on the following two basic concepts activity-based SCM and component management

What are the SCM activities?

The SCM activities are: management and planning of the SCM process, software configuration identification, software configuration control, software configuration status accounting, software configuration auditing, and software release management and delivery.

What is a Build?

A build is an operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product. A build comprises one or more implementation elements (often executable), each constructed from other elements, usually by a process of compilation and linking of source code.

What is build report?

Build Reports list all the files, their location, and incorporated changes that make up a build for a specific version of the software

What are the configuration audit findings?

The Configuration Audit Findings identify a baseline, any missing required artifacts, and incompletely tested or failed requirements

configuration management -

Software Test Methods

2010-03-15T01:35:00.003-07:00

Software Test Methods

software test methods -

Requirement Management Tools

2010-03-15T01:29:00.001-07:00

Requirement Management Tools
Vendor tools
Open source tools
In-house tools

requirement management tools -

Requirements Management

2010-03-15T01:26:00.000-07:00

Requirements management
Requirements traceability
Requirements analysis
Requirements prioritizing

requirements management -

Rational Robot

2010-03-15T01:23:00.000-07:00

Rational Robot
functional and regression testing

rational robot -

An Introduction to Quality Center

2010-03-15T01:19:00.000-07:00

An Introduction to Quality Center

Quality Center is a test management tool from HP (takeover from Mercury Interactive in 2007)

QC derived from TestDirector tool and developed in J2EE technology and backend database is MS SQL server

TestDirector developed in C++ technology default database is MS Access.

TestDirector has single cluster support where as QualityCenter has multi cluster support.

Quality Center is a web based test management solution; it supports standalone, Intranet and Internet environments.

Quality Center is available for both Windows and UNIX environments (QualityCenter for Windows and QualityCenter for UNIX)

Quality Center supports various activities like:

a) Requirement management

b) Test Design ( manual test cases as well as automated tests)

c) Test execution

d) Defect Management

e) Traceability among requirements, test cases and defects

f) Integrating with other tools like WinRunner, QTP and LoadRunner

Quality Center doesn’t have API as like QTP and LoadRunner

Quality Center has 2 Interfaces

I) Site Administration

II) Quality Center

Site Administration

It is administration area; here we can do below tasks:

a) Creating Domains

b) Deleting Domains

c) Creating a Project under a Domain

d) Deleting Projects

e) Creating Users

f) Editing User profiles

g) Deleting Users

h) Assigning users to a Project

i) Tracking a project’s status

Quality Center

It has four important modules

a) Requirements

In this module we can create, edit and delete Requirements.

And we can map Requirements with Test cases

b) Test Plan

It is an area, used for creating Manual as well as automated tests using WinRunner or QTP or LoadRunner

c) Test Lab

In this module Tests (manual as well as automated) can be executed.

During automated tests execution QualityCenter launches corresponding tool (WinRunner/QTP/LoadRunner) and that tool executes tests.

d) Defects

In this module testers can post defects and get status of their defects.

Note: QualityCenter can be used by Testers, Test Leads, Test Manager and Developers.

Quality Center Version history:

1st version QC 8.0

8.2

8.2 SP1

9.0 (in 2006)

9.2 (in 2007)

9.5 (in 2008)

10.0 (in 2009)

I) Exporting QTP Tests (From File System) to Quality Center Project

Steps:

    1) Create a folder in 'Test Plan' (QC) for Importing Tests

    2) Connect to Quality Center Project from QTP
        File menu-->Quality Center Connection-->Enter QC Server Url
        -->Enter User name & Password--> connect to Project

    3) Open a Test in QTP Test pane and Select Save As Option in File menu
    4) Select QC Test Plan and Save

--------------------------------------------------------

II) Exporting Tests from Quality Center Project to QTP (File System)

    1) Launch QC and Connect to the Project by Providing User Id & Password

    2) Select 'Test Plan' and selects an Automated test & Launch QTP

    3) Save As, Select 'File System' and Save

-------------------------------------------------------------------

III) Exporing Manual Requirements/Tests/Defects from File System (Using Excel/Word) to QC Project:

Pre-Requasites:

Download & Install Excel/Word Add in, then 'Export to Quality Center' Option will be available in Excel sheet 'Tools Menu.

Steps:

    1) Open Test case file (Excel)
    2) Tools menu ->Select 'Export to Quality Center' option
    3) Enter QC server Url and Click Next
    4) Enter User Name & Password and Click Next
    5) Select Domain & Project and Click Next
    6) select type of Data (Requirements/Tests/defects) and Click Next
    7) Enter map name and Click Next
    8) Map QC Fields to corresponding Excel Columns and Click Next
    9) Click Finish
-----------------------------------------------------------------------

Quality Center -

An Introduction to LoadRunner

2010-03-15T01:15:00.000-07:00

An Introduction to LoadRunner

LoadRunner is a Performance test tool, it can be used for Load testing, Stress testing and Endurance testing.

LoadRunner is available for Windows and UNIX versions (LoadRunner for Windows and LoadRunner for UNIX)

We can install LoadRunner in 2 ways 1) LoadRunner full installation 2) Load Generator Installation

LoadRunner is a protocol based test tool, where as QTP is a object based test tool. We can select single or multiple protocols.

LoadRunner was developed by Mercury Interactive in 1990s, later takeover by HP in 2007.

LoadRunner is a leading tool in performance testing sector, there it has more than 60% market share.

Other competitor tools for Performance testing are IBM-RPT (Rational Performance Tester), Borland-Silk Performer, QAWebload, Jmeter etc…

LoadRunner has 3 external components and one internal component

External Components:

1) VUser Generator (Virtual user generator)

2) Controller

3) Analysis

Internal Components:

1) Remote Agent Process

1) Vuser Generator: It is used for Scripts generation, editing and deletion.

LoadRunner Script divided into 3 parts

a) VUser-init (for recording application launching operation)

b) Action (for recording main action to be tested)

c) VUser-end (for recording application closing operation)

For generating tests Recording is the only method in LoadRunner, LoadRunner uses C like Vuser script, which we can edit.

We can insert Transaction points (Start and end) and Rendovez point in LoadRunner.

2) Controller: It is a hub of LoadRunner, here we can generate scenarios and run scenarios.

In Controller we can create VUsers, add Load generators and schedule our tests. In LoardRunner several schedules available, we can choose our desired schedule.

Schedules are:

General schedule:

Starting all vusers at a time and closing all at a time.

Ramp-up:

In this schedule we start some number of vusers for a specified time (Example 100 users for every 10 seconds) and we stop all vusers at a time.

Ramp-down:

In this schedule we start all vusers at a time and we stop vusers step by step (Example 100 users for every 10 seconds)

Ramp-up and Ramp-down:

In this schedule, we start and stop vusers step by step, means:

Start some number of vusers for a specified time (Example 100 users for every 10 seconds)

Stop some number of vusers for a specified time (Example 100 users for every 10 seconds)

Endurance Testing:

Applying continues load for a specific period of time

Example: 10000 vusers load continuously for 6 hours, in this approach; we can test reliability of our Software Application

3) Analysis:

This component is used for Result viewing for analyzing results and for Result reporting.

LoadRunner is providing Result reporting in several formats like Document, HTML and Crystal Reports.

After analyzing the Results we can send Defects.

LoadRunner -

Performance Testing

2010-03-15T01:11:00.000-07:00

Performance Testing
Load Testing
Stress Testing
Endurance Testing
Data volume Testing

Performance testing -

Usability Testing

2010-03-15T01:08:00.000-07:00

usability testing
Look and feel
user friendliness of the system

usability testing -

CMM Levels Vs ISO Standards

2010-03-15T01:05:00.000-07:00

CMM Levels Vs ISO Standards
Capability maturity Models Integration
International Organization for Standards

CMM(I) Vs ISO -

Agile methodology

2010-03-15T01:01:00.000-07:00

Agile software development

Refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.

Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.

There are many specific agile development methods. Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.
Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning. Iterations are short time frames ("timeboxes") that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.[1] Multiple iterations may be required to release a product or new features.
Team composition in an agile project is usually cross-functional and self-organizing without consideration for any existing corporate hierarchy or the corporate roles of team members. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration's requirements.
Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc.

Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of an effort. This may also require a coordination of priorities across teams.
No matter what development disciplines are required, each agile team will contain a customer representative. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration problem-domain questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment and ensuring alignment with customer needs and company goals.
Most agile implementations use a routine and formal daily face-to-face communication among team members. This specifically includes the customer representative and any interested stakeholders as observers. In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are. This standing face-to-face communication prevents problems being hidden.
Agile emphasizes working software as the primary measure of progress. This, combined with the preference for face-to-face communication, produces less written documentation than other methods—though, in an agile project, documentation and other artifacts rank equally with a working product. The agile method encourages stakeholders to prioritize wants with other iteration outcomes based exclusively on business value perceived at the beginning of the iteration.
Specific tools and techniques such as continuous integration, automated or xUnit test, pair programming, test driven development, design patterns, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance project agility.
History
The modern definition of agile software development evolved in the mid-1990s as part of a reaction against "heavyweight" methods, perceived to be typified by a heavily regulated, regimented, micro-managed use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software developers actually perform effective work. A case can be made that agile and iterative development methods mark a return to development practice from early in the history of software development.[2] Initially, agile methods were called "lightweight methods."
An adaptive software development process was introduced in a paper by Edmonds (1974).[3] Notable early Agile methods include Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995). These are now typically referred to as Agile Methodologies, after the Agile Manifesto published in 2001.
In 2001, 17 prominent figures[4] in the field of agile development (then called "light-weight methods") came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They coined the terms "Agile Software Development" and "agile methods", and they created the Agile Manifesto, widely regarded as the canonical definition of agile development and accompanying agile principles. Later, some of these people formed The Agile Alliance, a non-profit organization that promotes agile development.
Principles
Agile methods are a family of development processes, not a single approach to software development. The Agile Manifesto states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
•   Individuals and interactions over processes and tools
•   Working software over comprehensive documentation
•   Customer collaboration over contract negotiation
•   Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Some of the principles behind the Agile Manifesto are:
•   Customer satisfaction by rapid, continuous delivery of useful software
•   Working software is delivered frequently (weeks rather than months)
•   Working software is the principal measure of progress
•   Even late changes in requirements are welcomed
•   Close, daily cooperation between business people and developers
•   Face-to-face conversation is the best form of communication (co-location)
•   Projects are built around motivated individuals, who should be trusted
•   Continuous attention to technical excellence and good design
•   Simplicity
•   Self-organizing teams
•   Regular adaptation to changing circumstances
The manifesto spawned a movement in the software industry known as agile software development.
In 2005, Alistair Cockburn and Jim Highsmith gathered another group of people—management experts, this time—and wrote an addendum, known as the PM Declaration of Interdependence.
The functioning principles of Agile can be found in lean manufacturing and six sigma. These concepts include error proofing, eliminating waste, creating flow, adding customer value, and empowering workers. The concepts were first formally espoused in the 14 principles of the Toyota Way, the two pillars of the Toyota Production System (Just-in-time and smart automation), the 5S methodology, and Deming’s 14 points. These have been summarized in the seven points of lean software development.
Comparison with other methods
Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methods. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". A more accurate distinction is that methods exist on a continuum from "adaptive" to "predictive". Agile methods lie on the "adaptive" side of this continuum.
Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered.
Agile methods have much in common with the "Rapid Application Development" techniques from the 1980/90s as espoused by James Martin and others.
Contrasted with other iterative development methods
Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other development models: in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. Most agile methods also differ by treating their time period as a timebox.
Contrasted with the waterfall model
Agile development has little in common with the waterfall model. As of 2009, the waterfall model is still in common use. The waterfall model is the most structured of the methods, stepping through requirements-capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.
A common criticism of the waterfall model is its inflexible division of a project into separate stages, where commitments are made early on, making it difficult to react to changes in requirements as the project executes. Iterations are expensive. This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change in the course of the project.
Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it and adding further functionality throughout the life of the project. If a project being delivered under the waterfall method is cancelled at any point up to the end, there is nothing to show for it beyond a huge resources bill. With the agile method, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation.
Adaptations of Scrum show how agile methods are augmented to produce and continuously improve a strategic plan.
Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration. Other teams, most notably Extreme Programming teams, work on activities simultaneously.
Contrasted with "cowboy coding"
Cowboy coding is the absence of a defined method; i.e., team members do whatever they feel is right. The Agile approach is often confused with cowboy coding, due to Agile's frequent re-evaluation of plans, emphasis on face-to-face communication, and relatively sparse use of documentation. However, Agile teams follow defined—and often very disciplined and rigorous—processes.
As with all development methods, the skill and experience of users determine the degree of success and/or abuse of such activity. Rigid controls, which are systematically embedded within an Agile process, offer stronger levels of accountability. The degradation of well-intended procedures can lead to activities that are often categorized as cowboy coding.
Suitability of agile methods
There is little if any consensus on what types of software projects are best suited for the agile approach. Many large organizations have difficulty bridging the gap between the traditional waterfall method and an agile one.
Large scale agile software development remains an active research area.
Agile development has been widely documented as working well for small (<10 developers) co-located teams.
Some things that can negatively impact the success of an agile project are:
•   Large scale development efforts (>20 developers), though scaling strategies and evidence to the contrary[17] have been described.
•   Distributed development efforts (non-co-located teams). Strategies have been described in Bridging the Distance and Using an Agile Software Process with Offshore Development[19]
•   Command-and-control company cultures
•   Forcing an agile process on a development team
•   Mission critical systems where failure is not an option at any cost (Software for surgical procedures).
Several successful large scale agile projects have been documented. BT has had several hundred developers situated in the UK, Ireland and India working collaboratively on projects and using Agile methods. While questions undoubtedly still arise about the suitability of some Agile methods to certain project types, it would appear that scale or geography, by themselves, are not necessarily barriers to success.
Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods.[15] The authors suggest that each side of the continuum has its own home ground as follows:
Agile home ground:
•   Low criticality
•   Senior developers
•   Requirements change often
•   Small number of developers
•   Culture that thrives on chaos
Plan-driven home ground:[15]
•   High criticality
•   Junior developers
•   Requirements do not change often
•   Large number of developers
•   Culture that demands order

Agile methods and method tailoring
In the literature, different terms refer to the notion of method adaptation, including ‘method tailoring’, ‘method fragment adaptation’ and ‘situational method engineering’. Method tailoring is defined as:
A process or capability in which human agents through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments determine a system development approach for a specific project situation.
Potentially, almost all agile methods are suitable for method tailoring. Even the DSDM method is being used for this purpose and has been successfully tailored in a CMM context. Situation-appropriateness can be considered as a distinguishing characteristic between agile methods and traditional software development methods, with the latter being relatively much more rigid and prescriptive. The practical implication is that agile methods allow project teams to adapt working practices according to the needs of individual projects. Practices are concrete activities and products that are part of a method framework. At a more extreme level, the philosophy behind the method, consisting of a number of principles, could be adapted (Aydin, 2004).
Extreme Programming (XP) makes the need for method adaptation explicit. One of the fundamental ideas of XP is that no one process fits every project, but rather that practices should be tailored to the needs of individual projects. Partial adoption of XP practices, as suggested by Beck, has been reported on several occasions.[22] A tailoring practice is proposed by Mehdi Mirakhorli which provides sufficient roadmap and guideline for adapting all the practices. RDP Practice is designed for customizing XP. This practice first time proposed as a long research paper in APSO workshop at ICSE 2008 conference and yet it is the only proposed and applicable method for customizing XP. Although it is specifically a solution for XP, this practice has the capability of extending to other methodologies. At first glance, this practice seems to be in the category of static method adaptation but experiences with RDP Practice says that it can be treated like dynamic method adaptation. The distinction between static method adaptation and dynamic method adaptation is subtle.[23] The key assumption behind static method adaptation is that the project context is given at the start of a project and remains fixed during project execution. The result is a static definition of the project context. Given such a definition, route maps can be used in order to determine which structured method fragments should be used for that particular project, based on predefined sets of criteria. Dynamic method adaptation, in contrast, assumes that projects are situated in an emergent context. An emergent context implies that a project has to deal with emergent factors that affect relevant conditions but are not predictable. This also means that a project context is not fixed, but changing during project execution. In such a case prescriptive route maps are not appropriate. The practical implication of dynamic method adaptation is that project managers often have to modify structured fragments or even innovate new fragments, during the execution of a project (Aydin et al., 2005).
Agile methods and project management
Agile methods differ to a large degree in the way they cover project management. Some methods are supplemented with guidelines on project management, but there is generally no comprehensive support.
Both PMP and PRINCE2 have been suggested as suitable, complementary project management systems.

agile methodology -

Test Design Techniques

2010-03-15T00:59:00.000-07:00

Test Design Techniques

Important Terms:

The test development process

Test case specification, test design, test execution schedule, test procedure specification, test script, traceability.

Categories of test design techniques

Black-box test design technique, specification-based test design technique, white-box test design technique, structure-based test design technique, experience-based test design technique.

Specification-based or black box techniques

Boundary value analysis, decision table testing, equivalence partitioning, state transition testing, use case testing.

Structure-based or white box techniques
Code coverage, decision coverage, statement coverage, structure-based testing.

Experience-based techniques

Exploratory testing, fault attack.

Test Design Techniques
o Specification-based/Black-box techniques
o Structure-based/White-box techniques
o Experience-based techniques

I) Specification-based/Black-box techniques
a) Equivalence partitioning
b) Boundary value analysis
c) Decision table testing
d) State transition testing
e) Use case testing

Equivalence partitioning

o Inputs to the software or system are divided in to groups that are expected to exhibit similar behavior
o Equivalence partitions or classes can be found for both valid data and invalid data
o Partitions can also be identified for outputs, internal values, time related values and for interface values.
o Equivalence partitioning is applicable all levels of testing

Boundary value analysis

o Behavior at the edge of each equivalence partition is more likely to be incorrect. The maximum and minimum values of a partition are its boundary values.
o A boundary value for a valid partition is a valid boundary value; the boundary of an invalid partition is an invalid boundary value.
o Boundary value analysis can be applied at all test levels
o It is relatively easy to apply and its defect-finding capability is high
o This technique is often considered as an extension of equivalence partitioning.

Decision table testing

o In Decision table testing test cases are designed to execute the combination of inputs
o Decision tables are good way to capture system requirements that contain logical conditions.
o The decision table contains triggering conditions, often combinations of true and false for all input conditions
o It maybe applied to all situations when the action of the software depends on several logical decisions

State transition testing

o In state transition testing test cases are designed to execute valid and invalid state transitions
o A system may exhibit a deferent response on current conditions or previous history. In this case, that aspect of the system can be shown as a state transition diagram.
o State transition testing is much used in embedded software and technical automation.

Use case testing

o In use case testing test cases are designed to execute user scenarios
o A use case describes interactions between actors, including users and the system
o Each use case has preconditions, which need to be met for a use case to work successfully.
o A use case usually has a mainstream scenario and some times alternative branches.
o Use cases, often referred to as scenarios, are very useful for designing acceptance tests with customer/user participation

II) Structure-based/White-box techniques
o Statement testing and coverage
o Decision testing and coverage
o Other structure-based techniques
condition coverage
multi condition coverage

Statement testing and coverage:

Statement
An entity in a programming language, which is typically the smallest indivisible unit of execution

Statement coverage
The percentage of executable statements that have been exercised by a test suite

Statement testing
A white box test design technique in which test cases are designed to execute statements

Decision testing and coverage

Decision
A program point at which the control flow has two or more alternative routes

A node with two or more links to separate branches

Decision Coverage
The percentage of decision outcomes that have been exercised by a test suite

100% decision coverage implies both 100% branches coverage and 100% statement coverage

Decision testing
A white box test design technique in which test cases are designed to execute decision outcomes.

Other structure-based techniques
Condition
A logical expression that can be evaluated as true or false

Condition coverage
The percentage of condition outcomes that have been exercised by a test suite

Condition testing
A white box test design technique in which test cases are designed to execute condition outcomes

Multiple condition testing
A white box test design technique in which test cases are designed to execute combinations of single condition outcomes

III) Experience-based techniques

o Error guessing
o Exploratory testing

Error guessing
o Error guessing is a commonly used experience-based technique

o Generally testers anticipate defects based on experience, these defects list can be built based on experience, available defect data, and from common knowledge about why software fails.

Exploratory testing
o Exploratory testing is concurrent test design, test execution, test logging and learning , based on test charter containing test objectives and carried out within time boxes

It is approach that is most useful where there are few or inadequate specifications and serve time pressure.

test design techniques -

Software Test Metrics

2010-03-12T21:22:00.001-08:00

This Document Explains:
1) Base Metrics (Direct Measure),
2) Calculated Metrics (Indirect Measure),
3) Base Metrics & Test Phases,
4) Calculated Metrics & Phases,
5) Crucial Web Based Testing Metrics,
6) Test Case defect density,
7) Defect Slippage Ratio,
8) Requirement Volatility
9) Review Efficiency
10) Efficiency and Effectiveness of Processes
11) Metrics for Software Testing

Metrics for Software Testing

Test Coverage = Number of units (KLOC/FP) tested / total size of the system
Number of tests per unit size = Number of test cases per KLOC/FP
Acceptance criteria tested = Acceptance criteria tested / total acceptance criteria
Defects per size = Defects detected / system size
Test cost (in %) = Cost of testing / total cost *100
Cost to locate defect = Cost of testing / the number of defects located
Achieving Budget = Actual cost of testing / Budgeted cost of testing
Defects detected in testing = Defects detected in testing / total system defects
Defects detected in production = Defects detected in production/system size
Quality of Testing = No of defects found during Testing/(No of defects found during testing + No of acceptance defects found after delivery) *100
Effectiveness of testing to business = Loss due to problems / total resources processed by the system.
System complaints = Number of third party complaints / number of transactions processed
Scale of Ten = Assessment of testing by giving rating in scale of 1 to 10
Source Code Analysis = Number of source code statements changed / total number of tests.
Effort Productivity = Test Planning Productivity = No of Test cases designed / Actual Effort for Design and Documentation
Test Execution Productivity = No of Test cycles executed / Actual
Effort for testing

B) The product quality measures

1. Customer satisfaction index

(Quality ultimately is measured in terms of customer satisfaction.)
Surveyed before product delivery and after product delivery
(and on-going on a periodic basis, using standard questionnaires)
Number of system enhancement requests per year
Number of maintenance fix requests per year
User friendliness: call volume to customer service hotline
User friendliness: training time per new user
Number of product recalls or fix releases (software vendors)
Number of production re-runs (in-house information systems groups)

2. Delivered defect quantities

Normalized per function point (or per LOC)
At product delivery (first 3 months or first year of operation)
Ongoing (per year of operation)
By level of severity
By category or cause, e.g.: requirements defect, design defect, code defect,
documentation/on-line help defect, defect introduced by fixes, etc.

3. Responsiveness (turnaround time) to users

Turnaround time for defect fixes, by level of severity
Time for minor vs. major enhancements; actual vs. planned elapsed time

4. Product volatility

Ratio of maintenance fixes (to repair the system & bring it into
compliance with specifications), vs. enhancement requests
(requests by users to enhance or change functionality)

5. Defect ratios

Defects found after product delivery per function point
Defects found after product delivery per LOC
Pre-delivery defects: annual post-delivery defects
Defects per function point of the system modifications

6. Defect removal efficiency

Number of post-release defects (found by clients in field operation),
categorized by level of severity
Ratio of defects found internally prior to release (via inspections and testing),
as a percentage of all defects
All defects include defects found internally plus externally (by
customers) in the first year after product delivery

7. Complexity of delivered product

McCabe's cyclomatic complexity counts across the system
Halstead’s measure
Card's design complexity measures
Predicted defects and maintenance costs, based on complexity measures

8. Test coverage

Breadth of functional coverage
Percentage of paths, branches or conditions that were actually tested
Percentage by criticality level: perceived level of risk of paths
The ratio of the number of detected faults to the number of predicted faults.

9. Cost of defects

Business losses per defect that occurs during operation
Business interruption costs; costs of work-arounds
Lost sales and lost goodwill
Litigation costs resulting from defects
Annual maintenance cost (per function point)
Annual operating cost (per function point)
Measurable damage to your boss's career

10. Costs of quality activities

Costs of reviews, inspections and preventive measures
Costs of test planning and preparation
Costs of test execution, defect tracking, version and change control
Costs of diagnostics, debugging and fixing
Costs of tools and tool support
Costs of test case library maintenance
Costs of testing & QA education associated with the product
Costs of monitoring and oversight by the QA organization
(if separate from the development and test organizations)

11. Re-work

Re-work effort (hours, as a percentage of the original coding hours)
Re-worked LOC (source lines of code, as a percentage of the total delivered LOC)
Re-worked software components (as a percentage of the total delivered components)

12. Reliability

Availability (percentage of time a system is available, versus the time
the system is needed to be available)
Mean time between failure (MTBF)
Mean time to repair (MTTR)
Reliability ratio (MTBF / MTTR)
Number of product recalls or fix releases
Number of production re-runs as a ratio of production runs

software test metrics -

Software Testing

Software Testing

Resume Preparation

Software Testing Reference

SQL and PL/SQL Interview questions-III

SQL and PL/SQL Interview questions-II

SQL and PL/SQL Interview questions-I

Software Testing Guide

II) SDLC (Software Development Life Cycle)

III) SDLC Models

IV) Test Levels

V) Software Environment

VI) Test Types

VII) Test Design Techniques

a) Test Strategy

b) Test Planning

IX) Informal Testing

X) Quality Standards

Testing Development V MODEL TESTING

Development

Maintenance

Information

Testing Environment

Unit Testing

Selenium tool

Test Management

Manual Testing Questions & Answers Part-II

Manual Testing Questions and Answers Part-I

Configuration Management

Software Test Methods

Requirement Management Tools

Requirements Management

Rational Robot

An Introduction to Quality Center

An Introduction to LoadRunner

Performance Testing

Usability Testing

CMM Levels Vs ISO Standards

Agile methodology

Test Design Techniques

Software Test Metrics

Testing

Development

V MODEL TESTING