Software testing - Questions and Answers - SQL Interview Questions 1. Q. What does SQL stand for? A. Structured Query Language 2. Q. How do you select all records from the table? A. Select * from table_name; 3. Q. What is a join? A. Join is a process of retrieve pieces of data from different sets (tables) and returns them to the user or program as one “joined†collection of data. 4. Q. What kinds of joins do you know? Give examples. A. We have self join, outer joint (LEFT, RIGHT), , cross-join ( Cartesian product n*m rows returned)Exp:outer jointSELECT Employee.Name, Department. DeptName FROM Employee, DepartmentWHERE Employee.Employee_ID = Department.Employee_ID; cross-joinSELECT * FROM table1, table2; self joinSELECT e1.name ’ ‘ e2.ename FROM emp e1, emp e2 WHERE e1. emp_no = e2.emp_no; The following summarizes the result of the join operations: · The result of T1 INNER JOIN T2 consists of their paired rows where thejoin-condition is true.· The result of T1 LEFT OUTER JOIN T2 consists of their paired rows wherethe join-condition is true and, for each unpaired row of T1, theconcatenation of that row with the null row of T2. All columns derivedfrom T2 allow null values.· The result of T1 RIGHT OUTER JOIN T2 consists of their paired rowswhere the join-condition is true and, for each unpaired row of T2, theconcatenation of that row with the null row of T1. All columns derivedfrom T1 allow null values.· The result of T1 FULL OUTER JOIN T2 consists of their paired rows and,for each unpaired row of T2, the concatenation of that row with the nullrow of T1 and, for each unpaired row of T1, the concatenation of that rowwith the null row of T2. All columns derived from T1 and T2 allow nullvalues. 5. Q. How do you add record to a table? A. INSERT into table_name VALUES (‘ALEX’ , 33 , ‘M’); 6. Q. How do you add a column to a table? A. ALTER TABLE Department ADD (AGE, NUMBER); 7. Q. How do you change value of the field? A. UPDATE EMP_table set number = 200 where item_munber = ‘CD’; update name_table set status = 'enable' where phone = '4161112222'; update SERVICE_table set REQUEST_DATE = to_date ('2006-03-04 09:29', 'yyyy-mm-dd hh24:MI') where phone = '4161112222'; 8. Q. What does COMMIT do? A. Saving all changes made by DML statements 9. Q. What is a primary key? A. The column (columns) that has completely unique data throughout the table is known as the primary key field. 10. Q. What are foreign keys? A. Foreign key field – is a field that links one table to another tables primary or foreign key. 11. Q. What is the main role of a primary key in a table? A. The main role of a primary key in a data table is to maintain the internal integrity of a data table. 12. Q. Can a table have more than one foreign key defined? A. A table can have any number of foreign keys defined. It can have only one primary key defined. 13. Q. List all the possible values that can be stored in a BOOLEAN data field. A. There are only two values that can be stored in a BOOLEAN data field: -1(true) and 0(false). 14 Q. What is the highest value that can be stored in a BYTE data field? A. The highest value that can be stored in a BYTE field is 255. or from -128 to 127. Byte is a set of Bits that represent a single character. Usually there are 8 Bits in a Byte, sometimes more, depending on how the measurement is being made. Each Char requires one byte of memory and can have a value from 0 to 255 (or 0 to 11111111 in binary). 15. Q. How many places to the right of the decimal can be stored in a CURRENCY data field? A. The CURRENCY data type can store up to four places to the right of the decimal. Any data beyond the fourth place will be truncated by Visual Basic without reporting an error. 16. Q. What is a stored procedure? A. A procedure is a group of PL/SQL statements that can be called by a name. Procedures do not return values they perform tasks. 17. Q. Describe how NULLs work in SQL? A. The NULL is how SQL handles missing values. Arifthmetic operation with NULL in SQL will return a NULL. 18. Q. What is Normalization? A. The process of table design is called normalization. 19. Q. What is referential integrity constraints? A. Referential integrity constraints are rules that are partnof the table in a database schema. 20. Q. What is Trigger? A. Trigger will execute a block of procedural code against the database when a table event occurs. A2. A trigger defines a set of actions that are performed in response to an insert, update, or delete operation on a specified table. When such an SQL operation is executed, in this case the trigger has been activated. 21. Q. Which of the following WHERE clauses will return only rows that have a NULL in the PerDiemExpenses column?A. WHERE PerDiemExpenses <> B. WHERE PerDiemExpenses IS NULLC. WHERE PerDiemExpenses = NULLD. WHERE PerDiemExpenses NOT IN (*) A. B is correct � When searching for a NULL value in a column, you must use the keyword IS. No quotes are required around the keyword NULL. 22. Q. You issue the following query:SELECT FirstName FROMStaffListWHERE FirstName LIKE'_A%'Which names would be returned by this query? Choose all that apply.A. AllenB. CLARKC. JACKSOND. David A. C is correct � Two wildcards are used with the LIKE operator. The underscore (_) stands for any one character of any case, and the percent sign (%) stands for any number of characters of any case including none. Because this string starts with an underscore rather than a percent sign, it won't return Allen or Clark because they represent zero and two characters before the "A". If the LIKE string had been "%A%", both of these values would have been returned. David was not returned because all non-wild card characters are case sensitive. Therefore, only strings with an uppercase "A" as their second letter are returned 23. Q. Write a SQL SELECT query that only returns each city only once from Students table?Do you need to order this list with an ORDER BY clause? A. SELECT DISTINCT CityFROM Students; The Distinct keyword automatically sorts all data in ascending order. However, if you want the data sorted in descending order, you have to use an ORDER BY clause 24. Q. Write a SQL SELECT sample of the concatenation operator. A. SELECT LastName ',' FirstName, City FROM Students; 25. Q. How to rename column in the SQL SELECT query? A. SELECT LastName ',' FirstName AS "Student Name", City AS "Home City" "FROM StudentsORDER BY "Student Name"
26. Q. Write SQL SELECT example how you limiting the rows returned with a WHERE clause. A. SELECT InstructorID, Salary FROM Instructors WHERE Salary > 5400 AND Salary < 6600; 27. Q. Write SQL SELECT query that returns the first and last name of each instructor, the Salary, and gives each of them a number. A. SELECT FirstName, LastName, Salary, ROWNUM FROM Instructors; 28. Q. Which of the following functions can be used only with numeric values? (Choose all that apply.)A. AVGB. MINC. LENGTHD. SUME. ROUND A. A and D � Only A and D are correct. The MIN function works with any character, numeric, or date datatype. The LENGTH function is a character function that returns the number of letters in a character value. The ROUND function works with both numeric and date values. 29. Q. Which function do you use to remove all padded characters to the right of a character value in a column with a char datatype?A. RTRIMB. RPADC. TRIM A. C � The TRIM function is used to remove padded spaces. LTRIM and RTRIM functions were included in earlier versions of Oracle, but Oracle 8i has replaced them with a single TRIM function 30. Q. Which statement do you use to eliminate padded spaces between the month and day values in a function TO_CHAR(SYSDATE,'Month, DD, YYYY') ? A. To remove padded spaces, you use the "fm" prefix before the date element that contains the spaces. TO_CHAR(SYSDATE,'fmMonth DD, YYYY') 31. Q. Is the WHERE clause must appear always before the GROUP BY clause in SQL SELECT ? A. Yes.The proper order for SQL SELECT clauses is: SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY. Only the SELECT and FROM clause are mandatory. 32. Q. How Oracle executes a statement with nested subqueries? A. When Oracle executes a statement with nested subqueries,it always executes the innermost query first. This query passes its results to the next query and so on until it reaches the outermost query. It is the outermost query that returns a result set. 33. Q. Which operator do you use to return all of the rows from one query except rows are returned in a second query? A. You use the MINUS operator to return all rows from one query except where duplicate rows are found in a second query. The UNION operator returns all rows from both queries minus duplicates. The UNION ALL operator returns all rows from both queries including duplicates. The INTERSECT operator returns only those rows that exist in both queries. 34. Q. How you will create a column alias? (Oracle 8i) A. The AS keyword is optional when specifying a column alias. You must enclose the column alias in double quotes when the alias contains a space or lowercase letters. If you specify an alias in lowercase letters without double quotes, the alias will appear in uppercase. 35 Q. Which of the following statements are Data Manipulation Language commands?A. INSERTB. UPDATEC. GRANTD. TRUNCATEE. CREATE A. A and B � The INSERT and UPDATE statements are Data Manipulation Language (DML) commands. GRANT is a Data Control Language (DCL) command. TRUNCATE and CREATE are Data Definition Language (DDL) commands 36. Question. What is Oracle locking? A. Oracle uses locking mechanisms to protect data from being destroyed by concurrent transactions. 37. Question. What Oracle lock modes do you know? A. Oracle has two lock modes: shared or exclusive. Shared locks are set on database resources so that many transactions can access the resource. Exclusive locks are set on resources that ensure one transaction has exclusive access to the database resource 38. Question. What is query optimization? A. Query optimization is the part of the query process in which the database system compares different query strategies and chooses the one with the least expected cost 39. Question. What are the main components of Database management systems software. A. The database management system software includes components for storage management, concurrency control, transaction processing, database manipulation interface, database definition interface,and database control interface. 40. Question. What are the main attributes of database management system? A. A database management system is composed of five elements: computer hardware, software, data, people (users), and operations procedures. 41. Question. What is transaction? A. A transaction is a collection of applications code and database manipulation code bound into an indivisible unit of execution.it consists from:BEGIN-TRANSACTION NameCodeEND TRANSACTION Name 42. Question. What databases do you know?Informix DB2 SQL Oracle 43. Question. Explain SQL SELECT example: select j.FILE_NUM from DB_name.job j, DB_name.address awhere j.JOB_TYPE ='C' AND j.COMPANY_NAME = 'TEST6' AND j.OFFICE_ID = '101' AND j.ACTIVE_IND = 'Y' AND a.ADDRESS_STATUS_ID = 'H' AND a.OFFICE_ID = '101' AND a.FILE_NUM = j.FILE_NUM order by j.FILE_NUM; Answer: j and a aliases for table names. this is outer joint select statament from two tables. 44. Q. Describe some Conversion Functions that you know A. TO_CHAR converts a number / date to a string. TO_DATE converts a string (representing a date) to a date. TO_NUMBER converts a character string containing digits to a numeric data type, it accepts one parameter which is a column value or a string literal 45. Q. Describe some Group Functions that you know A. 1) The COUNT function tells you how many rows were in the result set. SELECT COUNT(*) FROM TESTING.QA 2) The AVG function tells you the average value of a numeric column. SELECT MAX(SALARY) FROM TESTING.QA 3) The MAX and MIN functions tell you the maximum and minimum value of a numeric column. SELECT MIN(SALARY) FROM TESTING.QA 4) The SUM function tells you the sum value of a numeric column. SELECT SUM(SALARY) FROM TESTING.QA 46. Question. What does DML stand for? A. DML is Data Manipulation Language statements. (SELECT) 47. Question. What does DDL stand for? A. DDL is Data Definition Language statements. (CREATE) 48. Question. What does DCL stand for? A. DCL is Data Control Language statements. (COMMIT) 49. Question: Describe SQL comments. A. SQL comments are introduced by two consecutive hyphens (--) and ended by the end of the line. 50. Q. In what sequence SQL statement are processed? A. The clauses of the subselect are processed in the following sequence (DB2):1. FROM clause2. WHERE clause3. GROUP BY clause4. HAVING clause5. SELECT clause6. ORDER BY clause7. FETCH FIRST clause 51. Q. Describe TO_DATE function. A. The TO_DATE function returns a timestamp from a character string that has been interpreted using a character template.TO_DATE is a synonym for TIMESTAMP_FORMAT. 52. Question: In the domain table we have status as a numeric value from 01 to 04 and we have text definition of these values in the design document. Write SQL query to see the result as a text definitions that is corresponded to these values. (DB2) A. select TB1.member_id, TB1.bu_id, TB1.program, TB2.num, case TB1.status when '01' then 'Auto renew' when '02' then 'Expired' when '03' then 'Sold' when '04' then ‘Terminated’ else TB_name.status end from DB_name.TB_name1 TB1, DB_name.TB_name2 TB2 where TB1.program in ('com', 'org') and TB1.member_role = '100' order by TB1.member_id fetch first 30 rows only
Tuesday, February 24, 2009
software testing interview questions with answers 3
What makes a good test engineer?A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers' point of view, and reduce the learning curve in automated test tool programming. Judgement skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.
What makes a good Software QA engineer? The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see 'what's missing' is important for inspections and reviews.
What makes a good QA or Test manager? A good QA, test, or QA/Test(combined) manager should:
be familiar with the software development process
be able to maintain enthusiasm of their team and promote a positive atmosphere, despite what is a somewhat 'negative' process (e.g., looking for or preventing problems)
be able to promote teamwork to increase productivity
be able to promote cooperation between software, test, and QA engineers
have the diplomatic skills needed to promote improvements in QA processes
have the ability to withstand pressures and say 'no' to other managers when quality is insufficient or QA processes are not being adhered to
have people judgement skills for hiring and keeping skilled personnel
be able to communicate with technical and non-technical people, engineers, managers, and customers.
be able to run meetings and keep them focused
What's the role of documentation in QA? Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented. There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible.
What's the big deal about 'requirements'? One of the most reliable methods of insuring problems, or failure, in a complex software project is to have poorly documented requirements specifications. Requirements are the details describing an application's externally-perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A testable requirement would be something like 'the user must enter their previously-assigned password to access the application'. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project. Many books are available that describe various approaches to this task. (See the Bookstore section's 'Software Requirements Engineering' category for books on Software Requirements.)
Care should be taken to involve ALL of a project's significant 'customers' in the requirements process. 'Customers' could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren't met should be included if possible.
Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as 'The product shall.....'. 'Design' specifications should not be confused with 'requirements'; design specifications should be traceable back to the requirements.
In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.
'Agile' methods such as XP use methods requiring close interaction and cooperation between programmers and customers/end-users to iteratively develop requirements. The programmer uses 'Test first' development to first create automated unit testing code, which essentially embodies the requirements.
What steps are needed to develop and run software tests? The following are some of the steps to consider:
Obtain requirements, functional design, and internal design specifications and other necessary documents
Obtain budget and schedule requirements
Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)
Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests
Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc.
Determine test environment requirements (hardware, software, communications, etc.)
Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)
Determine test input data requirements
Identify tasks, those responsible for tasks, and labor requirements
Set schedule estimates, timelines, milestones
Determine input equivalence classes, boundary value analyses, error classes
Prepare test plan document and have needed reviews/approvals
Write test cases
Have needed reviews/inspections/approvals of test cases
Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data
Obtain and install software releases
Perform tests
Evaluate and report results
Track problems/bugs and fixes
Retest as needed
Maintain and update test plans, test cases, test environment, and testware through life cycle
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.
(See the Bookstore section's 'Software Testing' and 'Software QA' categories for useful books with more information.)
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 is 'configuration management'? Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes. (See the 'Tools' section for web resources with listings of configuration management tools. Also see the Bookstore section's 'Configuration Management' category for useful books with more information.)
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).
Also see What is Extreme Programming and what's it got to do with testing? elsewhere in the Softwareqatest.com FAQ.
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 Software QA processes be implemented without stifling productivity? By implementing QA processes slowly over time, using consensus to reach agreement on processes, and adjusting and experimenting as an organization grows and matures, productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection, panics and burn-out will decrease, and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings, and promote training as part of the QA process. However, no one - especially talented technical types - likes rules or 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 Bookstore 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:
What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?
Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?
Will down time for server and content maintenance/upgrades be allowed? how much?
What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?
How reliable are the site's Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing?
What processes will be required to manage updates to the web site's content, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?
Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??
How will internal and external links be validated and updated? how often?
Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet 'traffic congestion' problems to be accounted for in testing?
How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?
How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
Some sources of site security information include the Usenet newsgroup 'comp.security.announce' and links concerning web site security in the 'Other Resources' section.
Some usability guidelines to consider - these are subjective and may or may not apply to a given situation (Note: more information on usability testing issues can be found in articles about web site usability in the 'Other Resources' section):
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.
Many new web site test tools have appeared in the recent years and more than 280 of them are listed in the 'Web Test Tools' section.
How is testing affected by object-oriented designs? Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well-designed this can simplify test design.
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. For more info see the XP-related listings in the Softwareqatest.com 'Other Resources' section.
What makes a good Software QA engineer? The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see 'what's missing' is important for inspections and reviews.
What makes a good QA or Test manager? A good QA, test, or QA/Test(combined) manager should:
be familiar with the software development process
be able to maintain enthusiasm of their team and promote a positive atmosphere, despite what is a somewhat 'negative' process (e.g., looking for or preventing problems)
be able to promote teamwork to increase productivity
be able to promote cooperation between software, test, and QA engineers
have the diplomatic skills needed to promote improvements in QA processes
have the ability to withstand pressures and say 'no' to other managers when quality is insufficient or QA processes are not being adhered to
have people judgement skills for hiring and keeping skilled personnel
be able to communicate with technical and non-technical people, engineers, managers, and customers.
be able to run meetings and keep them focused
What's the role of documentation in QA? Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented. There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible.
What's the big deal about 'requirements'? One of the most reliable methods of insuring problems, or failure, in a complex software project is to have poorly documented requirements specifications. Requirements are the details describing an application's externally-perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A testable requirement would be something like 'the user must enter their previously-assigned password to access the application'. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project. Many books are available that describe various approaches to this task. (See the Bookstore section's 'Software Requirements Engineering' category for books on Software Requirements.)
Care should be taken to involve ALL of a project's significant 'customers' in the requirements process. 'Customers' could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren't met should be included if possible.
Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as 'The product shall.....'. 'Design' specifications should not be confused with 'requirements'; design specifications should be traceable back to the requirements.
In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.
'Agile' methods such as XP use methods requiring close interaction and cooperation between programmers and customers/end-users to iteratively develop requirements. The programmer uses 'Test first' development to first create automated unit testing code, which essentially embodies the requirements.
What steps are needed to develop and run software tests? The following are some of the steps to consider:
Obtain requirements, functional design, and internal design specifications and other necessary documents
Obtain budget and schedule requirements
Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)
Identify application's higher-risk aspects, set priorities, and determine scope and limitations of tests
Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc.
Determine test environment requirements (hardware, software, communications, etc.)
Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)
Determine test input data requirements
Identify tasks, those responsible for tasks, and labor requirements
Set schedule estimates, timelines, milestones
Determine input equivalence classes, boundary value analyses, error classes
Prepare test plan document and have needed reviews/approvals
Write test cases
Have needed reviews/inspections/approvals of test cases
Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data
Obtain and install software releases
Perform tests
Evaluate and report results
Track problems/bugs and fixes
Retest as needed
Maintain and update test plans, test cases, test environment, and testware through life cycle
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.
(See the Bookstore section's 'Software Testing' and 'Software QA' categories for useful books with more information.)
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 is 'configuration management'? Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes. (See the 'Tools' section for web resources with listings of configuration management tools. Also see the Bookstore section's 'Configuration Management' category for useful books with more information.)
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).
Also see What is Extreme Programming and what's it got to do with testing? elsewhere in the Softwareqatest.com FAQ.
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 Software QA processes be implemented without stifling productivity? By implementing QA processes slowly over time, using consensus to reach agreement on processes, and adjusting and experimenting as an organization grows and matures, productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection, panics and burn-out will decrease, and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings, and promote training as part of the QA process. However, no one - especially talented technical types - likes rules or 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 Bookstore 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:
What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?
Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?
Will down time for server and content maintenance/upgrades be allowed? how much?
What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?
How reliable are the site's Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing?
What processes will be required to manage updates to the web site's content, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?
Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??
How will internal and external links be validated and updated? how often?
Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet 'traffic congestion' problems to be accounted for in testing?
How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?
How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
Some sources of site security information include the Usenet newsgroup 'comp.security.announce' and links concerning web site security in the 'Other Resources' section.
Some usability guidelines to consider - these are subjective and may or may not apply to a given situation (Note: more information on usability testing issues can be found in articles about web site usability in the 'Other Resources' section):
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.
Many new web site test tools have appeared in the recent years and more than 280 of them are listed in the 'Web Test Tools' section.
How is testing affected by object-oriented designs? Well-engineered object-oriented design can make it easier to trace from code to internal design to functional design to requirements. While there will be little affect on black box testing (where an understanding of the internal design of the application is unnecessary), white-box testing can be oriented to the application's objects. If the application was well-designed this can simplify test design.
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. For more info see the XP-related listings in the Softwareqatest.com 'Other Resources' section.
Testing Interview questions with answers1
Explain IEEE 829 standard and other standards related to software testing.
IEEE 829 Standard is used for Software Test Documentation, where it specifies format for the set of documents to be used in the different stages software testing.
The documents are,
Test Plan – Test Plan is a planning document which has information about the scope, resources, duration, test coverage and other details.
Test Design – Test Design document has information of test pass criteria with test conditions and expected results.
Test Case – Test case document has information about the test data to be used.
Test Procedure – Test Procedure has information about the test steps to be followed and how to execute it.
Test Log – Test log has details about the run test cases, test pas & fail status, order, and the resource information who tested it.
Test Incident Report – Test Incident Report has information about the failed test comparing the actual result with expected result.
Test Summary Report – Test Summary Report has information about the testing done and quality of the software, it also analyses whether the software has met the requirements given by customer.
The other standards related to software testing are,
IEEE 1008 is for Unit Testing
IEEE 1012 is for Software verification and validation
IEEE 1028 is for Software Inspections
IEEE 1061 is for Software metrics and methodology
IEEE 1233 is for guiding the SRS development
IEEE 12207 is for SLC process
comparing the actual result with expected result.
What is Test Harness?
Test Harness is configuring a set of tools and test data to test an application in various conditions, which involves monitoring the output with expected output for correctness.
The benefits of Test Harness are,
Productivity increase due to process automation. Quality in the application.
st Summary Report – Test Summary Report has information about the testing
What is SEI? CMM? CMMI? ISO? IEEE? ANSI?
SEI refers to Software Engineering Institute of Carnegie Mellon University in Pittsburgh, it helps to improve software development process. SEI offers technical guidance for advanced practice in software engineering.
CMM refers to 'Capability Maturity Model', presently called as CMMI 'Capability Maturity Model Integration’; it was developed by SEI and used to understand the processes followed in as organization. CMMI ratings were given to organizations after review by auditors.
CMMI has five levels of process maturity for quality software delivery, they are,
Level 1 – In this level only few processes were used and to rely on individual efforts for successful completion of projects.
Level 2 – In this level there will be realistic planning like project tracking, requirements analysis, configuration management.
Level 3 – In this level a proper software development and maintenance are incorporated throughout the organization. Training programs are exercised for better understanding of the process.
Level 4 – In this level various metrics are used to follow the process and products. The delivery quality is high.
Level 5 – In this level new process and technology were used and implemented efficiently. The objective will be for consistence process development.
ISO is commonly known as 'International Organization for Standardization', the ISO 9001:2000 standard is used for quality systems audited by outside auditors. This standard is applicable for manufacturing companies not only for software. This standard is given based on the documentation, design, production, testing, servicing and other processes.
IEEE refers to 'Institute of Electrical and Electronics Engineers', which has members from many technical professional organizations around the world. IEEE 829 is the standard followed for software test documentation.
ANSI refers to 'American National Standards Institute', which manages the development of standards for products, services, personnel, processes, and systems in U.S. This organization also works with other international standards to make use of American products worldwide.
What is Scalability Testing?
Scalability Testing is used to check whether the functionality and performance of a system are capable to meet the volume and size change as per the requirements.
Scalability testing can be done using load test with various software and hardware configurations changed, where the testing environment settings unchanged.
Explain Test Plan, Test Strategy, Test Scenario, Test Case, Test Script, Test Environment, Test Procedure and Test Log.
Test Plan is a document with information about Scope of the project, Approach, Schedule of testing activities, Resources or Manpower required, Risk Issues, Features to be tested and not to be tested, Test Tools and Environment Requirements.
Test Strategy is a document prepared by the Quality Assurance Department with the details of testing approach to reach the Quality standards.
Test Scenario is prepared based on the test cases and test scripts with the sequence of execution.
Test case is a document normally prepared by the tester with the sequence of steps to test the behavior of feature/functionality/non-functionality of the application.
Test Case document consists of Test case ID, Test Case Name, Conditions (Pre and Post Conditions) or Actions, Environment, Expected Results, Actual Results, Pass/Fail.
The Test cases can be broadly classified as User Interface Test cases, Positive Test cases and Negative Test cases.
Test Script is a program written to test the functionality of the application. It is a set of system readable instructions to automate the testing with the advantage of doing repeatable and regression testing easily. Test Environment is the Hardware and Software Environment where the testing is going to be done. It also explains whether the software under test interacts with Stubs and Drivers.
Test Procedure is a document with the detailed instruction of step by step execution of one or more test cases. Test procedure is used in Test Scenario and Test Scripts.
Test Log contains the details of which test cases were run with the output of execution.
What are the major activities in Database Testing?
The major activities in Database testing includes,Checking the Data ValidityChecking the Data IntegrityChecking the Performance related to DatabaseChecking the Security AspectsThe aspects to be considered in Database Schema testing are,Checking the Databases and DevicesChecking the Tables, Fields, Constraints, DefaultsChecking the Keys and IndexesChecking the Stored procedures & PackagesChecking the Error messagesChecking the Triggers - Update, Insert, DeleteChecking the Schema comparisons
What is Fuzz Testing ?
Fuzz testing is a Black box testing technique which uses random bad data to attack a program and see what breaks in the application.
Fuzz testing is mostly used to,• Set up a correct file to enter your program.• Restore some part of the file by using random data.• Unlock the file with the program.• Observe what breaks.
Fuzz testing can be automated for maximum effects on large applications. This testing improves the confidence that the application is safe and secure.
. Explain Peer Review in Software Testing
It is an alternative form of Testing, where some colleagues were invited to examine your work products for defects and improvement opportunities.
Some Peer review approaches are,Inspection – It is a more systematic and rigorous type of peer review. Inspections are more effective at finding defects than are informal reviews.Ex : In Motorola’s Iridium project nearly 80% of the defects were detected through inspections where only 60% of the defects were detected through formal reviews.Team Reviews – It is a planned and structured approach but less formal and less rigorous comparing to Inspections.Walkthrough – It is an informal review because the work product’s author describes it to some colleagues and asks for suggestions. Walkthroughs are informal because they typically do not follow a defined procedure, do not specify exit criteria, require no management reporting, and generate no metrics.Pair Programming – In Pair Programming, two developers work together on the same program at a single workstation and continuously reviewing their work.Peer Deskcheck – In Peer Deskcheck only one person besides the author examines the work product. It is an informal review, where the reviewer can use defect checklists and some analysis methods to increase the effectiveness.Passaround – It is a multiple, concurrent peer deskcheck where several people are invited to provide comments on the product.
Explain Compatibility Testing with an example.
Compatibility testing is to evaluate the application compatibility with the computing environment like Operating System, Database, Browser compatibility, Backwards compatibility, Computing capacity of the Hardware Platform and compatibility of the Peripherals.Ex : If Compatibility testing is done on a Game application, before installing a game on a computer, its compatibility is checked with the computer specification that whether it is compatible with the computer having that much of specification or not.
What is Traceability Matrix ?
Traceability Matrix is a document used for tracking the requirement, Test cases and the defect. This document is prepared to make the clients satisfy that the coverage done is complete as end to end, This document consists of Requirement/Base line doc Ref No., Test case/Condition, Defects/Bug id. Using this document the person can track the Requirement based on the Defect id.
Explain Load, Performance, Stress Testing with an example
Load Testing and Performance Testing are commonly said as positive testing where as Stress Testing is said to be as negative testing.
Say for example there is a application which can handle 25 simultaneous user logins at a time. In load testing we will test the application for 25 users and check how application is working in this stage, in performance testing we will concentrate on the time taken to perform the operation. Where as in stress testing we will test with more users than 25 and the test will continue to any number and we will check where the application is cracking the Hardware resources.
Explain Boundary value testing and Equivalence testing with some examples.
Boundary value testing is a technique to find whether the application is accepting the expected range of values and rejecting the values which falls out of range.
Ex. A user ID text box has to accept alphabet characters ( a-z ) with length of 4 to 10 characters.
BVA is done like this, max value:10 pass; max-1: 9 pass;
max+1=11 fail ;min=4 pass;min+1=5 pass;min-1=3 fail;
Like wise we check the corner values and come out with a conclusion whether the application is accepting correct range of values.
Equivalence testing is normally used to check the type of the object.
Ex. A user ID text box has to accept alphabet characters ( a - z ) with length of 4 to 10 characters.
In +ve condition we have test the object by giving alphabets. i.e a-z char only, after that we need to check whether the object accepts the value, it will pass.
In -ve condition we have to test by giving other than alphabets (a-z) i.e A-Z,0-9,blank etc, it will fail.
What is Security testing?
It is a process used to look out whether the security features of a system are implemented as designed and also whether they are adequate for a proposed application environment. This process involves functional testing, penetration testing and verification.
What is Installation testing?
Installation testing is done to verify whether the hardware and software are installed and configured properly. This will ensure that all the system components were used during the testing process. This Installation testing will look out the testing for a high volume data, error messages as well as security testing.
What is AUT ?
AUT is nothing but "Application Under Test". After the designing and coding phase in Software development life cycle, the application comes for testing then at that time the application is stated as Application Under Test.
What is Defect Leakage ?
Defect leakage occurs at the Customer or the End user side after the application delivery. After the release of the application to the client, if the end user gets any type of defects by using that application then it is called as Defect leakage. This Defect Leakage is also called as Bug Leak.
What are the contents in an effective Bug report?
Project, Subject, Description, Summary, Detected By (Name of the Tester), Assigned To (Name of the Developer who is supposed to the Bug), Test Lead ( Name ), Detected in Version, Closed in Version, Date Detected, Expected Date of Closure, Actual Date of Closure, Priority (Medium, Low, High, Urgent), Severity (Ranges from 1 to 5), Status, Bug ID, Attachment, Test Case Failed (Test case that is failed for the Bug)
What is Bug Life Cycle?
Bug Life Cycle is nothing but the various phases a Bug undergoes after it is raised or reported.
New or Opened
Assigned
Fixed
Tested
Closed
What is Error guessing and Error seeding ?
Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them.
Error Seeding is the process of adding known faults intentionally in a program for the reason of monitoring the rate of detection & removal and also to estimate the number of faults remaining in the program.
What is the difference between Bug, Error and Defect?
Error : It is the Deviation from actual and the expected value.
Bug : It is found in the development environment before the product is shipped to the respective customer. Defect : It is found in the product itself after it is shipped to the respective customer.
What is Test bed and Test data ?
Test Bed is an execution environment configured for software testing. It consists of specific hardware, network topology, Operating System, configuration of the product to be under test, system software and other applications. The Test Plan for a project should be developed from the test beds to be used.
Test Data is that run through a computer program to test the software. Test data can be used to test the compliance with effective controls in the software.
What is Negative testing?
Negative testing - Testing the system using negative data is called negative testing, e.g. testing the password where it should be minimum of 8 characters so testing it using 6 characters is negative testing.
hat are SDLC and STLC ? Explain its different phases.
SDLC
Requirement phase
Designing phase (HLD, DLD (Program spec))
Coding
Testing
Release
Maintenance
STLC
System Study
Test planning
Writing Test case or scripts
Review the test case
Executing test case
Bug tracking
Report the defect
What is Ad-hoc testing?
Ad hoc testing is concern with the Application Testing without following any rules or test cases.
For Ad hoc testing one should have strong knowledge about the Application.
Describe bottom-up and top-down approaches in Regression Testing.
Bottom-up approach : In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module.
Top-down approach : In this approach testing is conducted from main module to sub module. if the sub module is not developed a temporary program called STUB is used for simulate the submodule.
What is the difference between structural and functional testing?
Structural testing is a "white box" testing and it is based on the algorithm or code.
Functional testing is a "black box" (behavioral) testing where the tester verifies the functional specification.
What is the difference between Re-test and Regression Testing?
Re- test - Retesting means we testing only the certain part of an application again and not considering how it will effect in the other part or in the whole application.
Regression Testing - Testing the application after a change in a module or part of the application for testing that is the code change will affect rest of the application.
What is UAT testing? When it is to be done?
UAT testing - UAT stands for 'User acceptance Testing. This testing is carried out with the user perspective and it is usually done before the release.
What are the basic solutions for the software development problems?
Basic requirements - clear, detailed, complete, achievable, testable requirements has to be developed. Use some prototypes to help pin down requirements. In nimble environments, continuous and close coordination with customers/end-users is needed.
Schedules should be realistic - enough time to plan, design, test, bug fix, re-test, change, and document in the given schedule.
Adequate testing – testing should be started early, it should be re-tested after the bug fixed or changed, enough time should be spend for testing and bug-fixing.
Proper study on initial requirements – be ready to look after more changes after the development has begun and be ready to explain the changes done to others. Work closely with the customers and end-users to manage expectations. This avoids excessive changes in the later stages.
Communication – conduct frequent inspections and walkthroughs in appropriate time period; ensure that the information and the documentation is available on up-to-date if possible electronic. More emphasize on promoting teamwork and cooperation inside the team; use prototypes and proper communication with the end-users to clarify their doubts and expectations.
What are the common problems in the software development process?
Inadequate requirements from the Client - if the requirements given by the client is not clear, unfinished and not testable, then problems may come.
Unrealistic schedules – Sometimes too much of work is being given to the developer and ask him to complete in a Short duration, then the problems are unavoidable.
Insufficient testing – The problems can arise when the developed software is not tested properly.
Given another work under the existing process – request from the higher management to work on another project or task will bring some problems when the project is being tested as a team.
Miscommunication – in some cases, the developer was not informed about the Clients requirement and expectations, so there can be deviations.
Why does software have bugs?
Miscommunication or no communication – about the details of what an application should or shouldn't do
Programming errors – in some cases the programmers can make mistakes.
Changing requirements – there are chances of the end-user not understanding the effects of changes, or may understand and request them anyway to redesign, rescheduling of engineers, effects of other projects, work already completed may have to be redone or thrown out.
Time force - preparation of software projects is difficult at best, often requiring a lot of guesswork. When deadlines are given and the crisis comes, mistakes will be made.
What software testing types can be considered?
Black box testing – This type of testing doesn’t require any knowledge of the internal design or coding. These Tests are based on the requirements and functionality.
White box testing – This kind of testing is based on the knowledge of internal logic of a particular application code. The Testing is done based on the coverage of code statements, paths, conditions.
Unit testing – the 'micro' scale of testing; this is mostly used to test the particular functions or code modules. This is typically done by the programmer and not by testers; it requires detailed knowledge of the internal program design and code. It cannot be done easily unless the application has a well-designed architecture with tight code; this type may require developing test driver modules or test harnesses.
Sanity testing or Smoke testing – This type of testing is done initially to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing the systems in every 5 minutes or corrupting databases, the software may not be in a 'sound’ condition to proceed for further testing in its current state.
Functional testing – This a commonly used black-box testing geared to check the functional requirements of an application; this type of testing should be done by testers.
Integration testing – This testing is combining the ‘parts’ of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to the client/server and distributed systems.
Incremental Integration testing – This is continuous testing of an application when a new functionality is added the existing ones; it checks the application functionality by verifying whether it works separately before all parts of the program are completed, in this type it will be checked whether to introduce test drivers or not; this is done by programmers or by testers.
Regression testing – This is testing the whole application again after the fixes or the modifications are done on the software. This is mostly done at the end of the Software development life cycle. Mostly Automated testing tools are used for these type of testing.
System testing – This is a type of black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
End-to-end testing – This is similar to system testing; this involves testing of a complete application environment such as interacting with a database, using network communications, or interacting with other hardware, applications and so on.
UAT ( User Acceptance Testing ) – This type of testing comes on the final stage and mostly done on the specifications of the end-user or client.
Usability testing – This testing is done to check the 'user-friendliness' of the application. This depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Compatibility testing – Testing how well the software performs in a particular hardware, software, operating system, network etc.
Comparison testing – This is nothing comparing the software strengths and weakness with another competing product.
Mutation testing – This is another method for determining if a set of test data or test cases is useful, by purposely introducing various code changes or bugs and retesting with the original test data or cases to determine whether the 'bugs' are detected.
How do you decide when you have 'tested enough’?
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
Describe the Software Development Life Cycle
It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.
Describe the difference between validation and verification
Verification is done by frequent evaluation and meetings to appraise the documents, policy, code, requirements, and specifications. This is done with the checklists, walkthroughs, and inspection meetings.
Validation is done during actual testing and it takes place after all the verifications are being done.
What is the difference between QA and testing?
Testing involves operation of a system or application under controlled conditions and evaluating the results. It is oriented to 'detection'.
Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.
What is quality assurance?
Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.
What is the purpose of the testing?
Software testing is the process used to help identify the Correctness, Completeness, Security and Quality of the developed Computer Software.
Software Testing is the process of executing a program or system with the intent of finding errors.
IEEE 829 Standard is used for Software Test Documentation, where it specifies format for the set of documents to be used in the different stages software testing.
The documents are,
Test Plan – Test Plan is a planning document which has information about the scope, resources, duration, test coverage and other details.
Test Design – Test Design document has information of test pass criteria with test conditions and expected results.
Test Case – Test case document has information about the test data to be used.
Test Procedure – Test Procedure has information about the test steps to be followed and how to execute it.
Test Log – Test log has details about the run test cases, test pas & fail status, order, and the resource information who tested it.
Test Incident Report – Test Incident Report has information about the failed test comparing the actual result with expected result.
Test Summary Report – Test Summary Report has information about the testing done and quality of the software, it also analyses whether the software has met the requirements given by customer.
The other standards related to software testing are,
IEEE 1008 is for Unit Testing
IEEE 1012 is for Software verification and validation
IEEE 1028 is for Software Inspections
IEEE 1061 is for Software metrics and methodology
IEEE 1233 is for guiding the SRS development
IEEE 12207 is for SLC process
comparing the actual result with expected result.
What is Test Harness?
Test Harness is configuring a set of tools and test data to test an application in various conditions, which involves monitoring the output with expected output for correctness.
The benefits of Test Harness are,
Productivity increase due to process automation. Quality in the application.
st Summary Report – Test Summary Report has information about the testing
What is SEI? CMM? CMMI? ISO? IEEE? ANSI?
SEI refers to Software Engineering Institute of Carnegie Mellon University in Pittsburgh, it helps to improve software development process. SEI offers technical guidance for advanced practice in software engineering.
CMM refers to 'Capability Maturity Model', presently called as CMMI 'Capability Maturity Model Integration’; it was developed by SEI and used to understand the processes followed in as organization. CMMI ratings were given to organizations after review by auditors.
CMMI has five levels of process maturity for quality software delivery, they are,
Level 1 – In this level only few processes were used and to rely on individual efforts for successful completion of projects.
Level 2 – In this level there will be realistic planning like project tracking, requirements analysis, configuration management.
Level 3 – In this level a proper software development and maintenance are incorporated throughout the organization. Training programs are exercised for better understanding of the process.
Level 4 – In this level various metrics are used to follow the process and products. The delivery quality is high.
Level 5 – In this level new process and technology were used and implemented efficiently. The objective will be for consistence process development.
ISO is commonly known as 'International Organization for Standardization', the ISO 9001:2000 standard is used for quality systems audited by outside auditors. This standard is applicable for manufacturing companies not only for software. This standard is given based on the documentation, design, production, testing, servicing and other processes.
IEEE refers to 'Institute of Electrical and Electronics Engineers', which has members from many technical professional organizations around the world. IEEE 829 is the standard followed for software test documentation.
ANSI refers to 'American National Standards Institute', which manages the development of standards for products, services, personnel, processes, and systems in U.S. This organization also works with other international standards to make use of American products worldwide.
What is Scalability Testing?
Scalability Testing is used to check whether the functionality and performance of a system are capable to meet the volume and size change as per the requirements.
Scalability testing can be done using load test with various software and hardware configurations changed, where the testing environment settings unchanged.
Explain Test Plan, Test Strategy, Test Scenario, Test Case, Test Script, Test Environment, Test Procedure and Test Log.
Test Plan is a document with information about Scope of the project, Approach, Schedule of testing activities, Resources or Manpower required, Risk Issues, Features to be tested and not to be tested, Test Tools and Environment Requirements.
Test Strategy is a document prepared by the Quality Assurance Department with the details of testing approach to reach the Quality standards.
Test Scenario is prepared based on the test cases and test scripts with the sequence of execution.
Test case is a document normally prepared by the tester with the sequence of steps to test the behavior of feature/functionality/non-functionality of the application.
Test Case document consists of Test case ID, Test Case Name, Conditions (Pre and Post Conditions) or Actions, Environment, Expected Results, Actual Results, Pass/Fail.
The Test cases can be broadly classified as User Interface Test cases, Positive Test cases and Negative Test cases.
Test Script is a program written to test the functionality of the application. It is a set of system readable instructions to automate the testing with the advantage of doing repeatable and regression testing easily. Test Environment is the Hardware and Software Environment where the testing is going to be done. It also explains whether the software under test interacts with Stubs and Drivers.
Test Procedure is a document with the detailed instruction of step by step execution of one or more test cases. Test procedure is used in Test Scenario and Test Scripts.
Test Log contains the details of which test cases were run with the output of execution.
What are the major activities in Database Testing?
The major activities in Database testing includes,Checking the Data ValidityChecking the Data IntegrityChecking the Performance related to DatabaseChecking the Security AspectsThe aspects to be considered in Database Schema testing are,Checking the Databases and DevicesChecking the Tables, Fields, Constraints, DefaultsChecking the Keys and IndexesChecking the Stored procedures & PackagesChecking the Error messagesChecking the Triggers - Update, Insert, DeleteChecking the Schema comparisons
What is Fuzz Testing ?
Fuzz testing is a Black box testing technique which uses random bad data to attack a program and see what breaks in the application.
Fuzz testing is mostly used to,• Set up a correct file to enter your program.• Restore some part of the file by using random data.• Unlock the file with the program.• Observe what breaks.
Fuzz testing can be automated for maximum effects on large applications. This testing improves the confidence that the application is safe and secure.
. Explain Peer Review in Software Testing
It is an alternative form of Testing, where some colleagues were invited to examine your work products for defects and improvement opportunities.
Some Peer review approaches are,Inspection – It is a more systematic and rigorous type of peer review. Inspections are more effective at finding defects than are informal reviews.Ex : In Motorola’s Iridium project nearly 80% of the defects were detected through inspections where only 60% of the defects were detected through formal reviews.Team Reviews – It is a planned and structured approach but less formal and less rigorous comparing to Inspections.Walkthrough – It is an informal review because the work product’s author describes it to some colleagues and asks for suggestions. Walkthroughs are informal because they typically do not follow a defined procedure, do not specify exit criteria, require no management reporting, and generate no metrics.Pair Programming – In Pair Programming, two developers work together on the same program at a single workstation and continuously reviewing their work.Peer Deskcheck – In Peer Deskcheck only one person besides the author examines the work product. It is an informal review, where the reviewer can use defect checklists and some analysis methods to increase the effectiveness.Passaround – It is a multiple, concurrent peer deskcheck where several people are invited to provide comments on the product.
Explain Compatibility Testing with an example.
Compatibility testing is to evaluate the application compatibility with the computing environment like Operating System, Database, Browser compatibility, Backwards compatibility, Computing capacity of the Hardware Platform and compatibility of the Peripherals.Ex : If Compatibility testing is done on a Game application, before installing a game on a computer, its compatibility is checked with the computer specification that whether it is compatible with the computer having that much of specification or not.
What is Traceability Matrix ?
Traceability Matrix is a document used for tracking the requirement, Test cases and the defect. This document is prepared to make the clients satisfy that the coverage done is complete as end to end, This document consists of Requirement/Base line doc Ref No., Test case/Condition, Defects/Bug id. Using this document the person can track the Requirement based on the Defect id.
Explain Load, Performance, Stress Testing with an example
Load Testing and Performance Testing are commonly said as positive testing where as Stress Testing is said to be as negative testing.
Say for example there is a application which can handle 25 simultaneous user logins at a time. In load testing we will test the application for 25 users and check how application is working in this stage, in performance testing we will concentrate on the time taken to perform the operation. Where as in stress testing we will test with more users than 25 and the test will continue to any number and we will check where the application is cracking the Hardware resources.
Explain Boundary value testing and Equivalence testing with some examples.
Boundary value testing is a technique to find whether the application is accepting the expected range of values and rejecting the values which falls out of range.
Ex. A user ID text box has to accept alphabet characters ( a-z ) with length of 4 to 10 characters.
BVA is done like this, max value:10 pass; max-1: 9 pass;
max+1=11 fail ;min=4 pass;min+1=5 pass;min-1=3 fail;
Like wise we check the corner values and come out with a conclusion whether the application is accepting correct range of values.
Equivalence testing is normally used to check the type of the object.
Ex. A user ID text box has to accept alphabet characters ( a - z ) with length of 4 to 10 characters.
In +ve condition we have test the object by giving alphabets. i.e a-z char only, after that we need to check whether the object accepts the value, it will pass.
In -ve condition we have to test by giving other than alphabets (a-z) i.e A-Z,0-9,blank etc, it will fail.
What is Security testing?
It is a process used to look out whether the security features of a system are implemented as designed and also whether they are adequate for a proposed application environment. This process involves functional testing, penetration testing and verification.
What is Installation testing?
Installation testing is done to verify whether the hardware and software are installed and configured properly. This will ensure that all the system components were used during the testing process. This Installation testing will look out the testing for a high volume data, error messages as well as security testing.
What is AUT ?
AUT is nothing but "Application Under Test". After the designing and coding phase in Software development life cycle, the application comes for testing then at that time the application is stated as Application Under Test.
What is Defect Leakage ?
Defect leakage occurs at the Customer or the End user side after the application delivery. After the release of the application to the client, if the end user gets any type of defects by using that application then it is called as Defect leakage. This Defect Leakage is also called as Bug Leak.
What are the contents in an effective Bug report?
Project, Subject, Description, Summary, Detected By (Name of the Tester), Assigned To (Name of the Developer who is supposed to the Bug), Test Lead ( Name ), Detected in Version, Closed in Version, Date Detected, Expected Date of Closure, Actual Date of Closure, Priority (Medium, Low, High, Urgent), Severity (Ranges from 1 to 5), Status, Bug ID, Attachment, Test Case Failed (Test case that is failed for the Bug)
What is Bug Life Cycle?
Bug Life Cycle is nothing but the various phases a Bug undergoes after it is raised or reported.
New or Opened
Assigned
Fixed
Tested
Closed
What is Error guessing and Error seeding ?
Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them.
Error Seeding is the process of adding known faults intentionally in a program for the reason of monitoring the rate of detection & removal and also to estimate the number of faults remaining in the program.
What is the difference between Bug, Error and Defect?
Error : It is the Deviation from actual and the expected value.
Bug : It is found in the development environment before the product is shipped to the respective customer. Defect : It is found in the product itself after it is shipped to the respective customer.
What is Test bed and Test data ?
Test Bed is an execution environment configured for software testing. It consists of specific hardware, network topology, Operating System, configuration of the product to be under test, system software and other applications. The Test Plan for a project should be developed from the test beds to be used.
Test Data is that run through a computer program to test the software. Test data can be used to test the compliance with effective controls in the software.
What is Negative testing?
Negative testing - Testing the system using negative data is called negative testing, e.g. testing the password where it should be minimum of 8 characters so testing it using 6 characters is negative testing.
hat are SDLC and STLC ? Explain its different phases.
SDLC
Requirement phase
Designing phase (HLD, DLD (Program spec))
Coding
Testing
Release
Maintenance
STLC
System Study
Test planning
Writing Test case or scripts
Review the test case
Executing test case
Bug tracking
Report the defect
What is Ad-hoc testing?
Ad hoc testing is concern with the Application Testing without following any rules or test cases.
For Ad hoc testing one should have strong knowledge about the Application.
Describe bottom-up and top-down approaches in Regression Testing.
Bottom-up approach : In this approach testing is conducted from sub module to main module, if the main module is not developed a temporary program called DRIVERS is used to simulate the main module.
Top-down approach : In this approach testing is conducted from main module to sub module. if the sub module is not developed a temporary program called STUB is used for simulate the submodule.
What is the difference between structural and functional testing?
Structural testing is a "white box" testing and it is based on the algorithm or code.
Functional testing is a "black box" (behavioral) testing where the tester verifies the functional specification.
What is the difference between Re-test and Regression Testing?
Re- test - Retesting means we testing only the certain part of an application again and not considering how it will effect in the other part or in the whole application.
Regression Testing - Testing the application after a change in a module or part of the application for testing that is the code change will affect rest of the application.
What is UAT testing? When it is to be done?
UAT testing - UAT stands for 'User acceptance Testing. This testing is carried out with the user perspective and it is usually done before the release.
What are the basic solutions for the software development problems?
Basic requirements - clear, detailed, complete, achievable, testable requirements has to be developed. Use some prototypes to help pin down requirements. In nimble environments, continuous and close coordination with customers/end-users is needed.
Schedules should be realistic - enough time to plan, design, test, bug fix, re-test, change, and document in the given schedule.
Adequate testing – testing should be started early, it should be re-tested after the bug fixed or changed, enough time should be spend for testing and bug-fixing.
Proper study on initial requirements – be ready to look after more changes after the development has begun and be ready to explain the changes done to others. Work closely with the customers and end-users to manage expectations. This avoids excessive changes in the later stages.
Communication – conduct frequent inspections and walkthroughs in appropriate time period; ensure that the information and the documentation is available on up-to-date if possible electronic. More emphasize on promoting teamwork and cooperation inside the team; use prototypes and proper communication with the end-users to clarify their doubts and expectations.
What are the common problems in the software development process?
Inadequate requirements from the Client - if the requirements given by the client is not clear, unfinished and not testable, then problems may come.
Unrealistic schedules – Sometimes too much of work is being given to the developer and ask him to complete in a Short duration, then the problems are unavoidable.
Insufficient testing – The problems can arise when the developed software is not tested properly.
Given another work under the existing process – request from the higher management to work on another project or task will bring some problems when the project is being tested as a team.
Miscommunication – in some cases, the developer was not informed about the Clients requirement and expectations, so there can be deviations.
Why does software have bugs?
Miscommunication or no communication – about the details of what an application should or shouldn't do
Programming errors – in some cases the programmers can make mistakes.
Changing requirements – there are chances of the end-user not understanding the effects of changes, or may understand and request them anyway to redesign, rescheduling of engineers, effects of other projects, work already completed may have to be redone or thrown out.
Time force - preparation of software projects is difficult at best, often requiring a lot of guesswork. When deadlines are given and the crisis comes, mistakes will be made.
What software testing types can be considered?
Black box testing – This type of testing doesn’t require any knowledge of the internal design or coding. These Tests are based on the requirements and functionality.
White box testing – This kind of testing is based on the knowledge of internal logic of a particular application code. The Testing is done based on the coverage of code statements, paths, conditions.
Unit testing – the 'micro' scale of testing; this is mostly used to test the particular functions or code modules. This is typically done by the programmer and not by testers; it requires detailed knowledge of the internal program design and code. It cannot be done easily unless the application has a well-designed architecture with tight code; this type may require developing test driver modules or test harnesses.
Sanity testing or Smoke testing – This type of testing is done initially to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing the systems in every 5 minutes or corrupting databases, the software may not be in a 'sound’ condition to proceed for further testing in its current state.
Functional testing – This a commonly used black-box testing geared to check the functional requirements of an application; this type of testing should be done by testers.
Integration testing – This testing is combining the ‘parts’ of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to the client/server and distributed systems.
Incremental Integration testing – This is continuous testing of an application when a new functionality is added the existing ones; it checks the application functionality by verifying whether it works separately before all parts of the program are completed, in this type it will be checked whether to introduce test drivers or not; this is done by programmers or by testers.
Regression testing – This is testing the whole application again after the fixes or the modifications are done on the software. This is mostly done at the end of the Software development life cycle. Mostly Automated testing tools are used for these type of testing.
System testing – This is a type of black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
End-to-end testing – This is similar to system testing; this involves testing of a complete application environment such as interacting with a database, using network communications, or interacting with other hardware, applications and so on.
UAT ( User Acceptance Testing ) – This type of testing comes on the final stage and mostly done on the specifications of the end-user or client.
Usability testing – This testing is done to check the 'user-friendliness' of the application. This depends on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Compatibility testing – Testing how well the software performs in a particular hardware, software, operating system, network etc.
Comparison testing – This is nothing comparing the software strengths and weakness with another competing product.
Mutation testing – This is another method for determining if a set of test data or test cases is useful, by purposely introducing various code changes or bugs and retesting with the original test data or cases to determine whether the 'bugs' are detected.
How do you decide when you have 'tested enough’?
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
Describe the Software Development Life Cycle
It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.
Describe the difference between validation and verification
Verification is done by frequent evaluation and meetings to appraise the documents, policy, code, requirements, and specifications. This is done with the checklists, walkthroughs, and inspection meetings.
Validation is done during actual testing and it takes place after all the verifications are being done.
What is the difference between QA and testing?
Testing involves operation of a system or application under controlled conditions and evaluating the results. It is oriented to 'detection'.
Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.
What is quality assurance?
Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.
What is the purpose of the testing?
Software testing is the process used to help identify the Correctness, Completeness, Security and Quality of the developed Computer Software.
Software Testing is the process of executing a program or system with the intent of finding errors.
Testing Interview questions
1. What are the documents we are using to send a test report?
** Test Summary Report (# of TCs Executed, # of TCs yet to be executed, # of pass, # of Failure, % Completed, etc)
**Bug Details Report (# of Bugs logged based on the priority and severity)
** Clarification summary report (for TCs that needs inputs from functional or technical aspects)
2. What are the Risks you have faced while testing? Give example?
** Inadequate timeline - Scheduled dates proponed on clients requirements, In these conditions all the business important impact areas identified on the test cases will be executed or the P1 Test cases identified will be ran to make sure the basic business functionalities are bug free
**Frequent Future Changes – Continuous changes in futures makes the testing process unstable. Overcame by proper change control process.
**Poor requirements – Ambiguous requirements will lead the Testing process in wrong direction. A checklist is prepared based on the available Requirements and with an confirmed approval from the client, further process are to be initiated Some More: Systems Get hanged, application gets logged out very often,invalid o/p for valid i/p,re direction of s application 2 some otherpath. 3. What are the 2 types of matrix document?
a) Traceability matrix b) Test Management Matrix - proposed # of TCs planned in each phases and actual # of TCs covered in these phases (or) Proposed # of TCs planned for automation in a phase against the number of TCs actually automated
4. When we will prepare TM (Traceability matrix), who will prepare it?
During Requirement collection phase and these TM will be validated against the product during system testing or during UAT (user acceptance testing)
What is the use of it?
To make sure all the user requirements are adhered as specified in the requirements document..
** Test Summary Report (# of TCs Executed, # of TCs yet to be executed, # of pass, # of Failure, % Completed, etc)
**Bug Details Report (# of Bugs logged based on the priority and severity)
** Clarification summary report (for TCs that needs inputs from functional or technical aspects)
2. What are the Risks you have faced while testing? Give example?
** Inadequate timeline - Scheduled dates proponed on clients requirements, In these conditions all the business important impact areas identified on the test cases will be executed or the P1 Test cases identified will be ran to make sure the basic business functionalities are bug free
**Frequent Future Changes – Continuous changes in futures makes the testing process unstable. Overcame by proper change control process.
**Poor requirements – Ambiguous requirements will lead the Testing process in wrong direction. A checklist is prepared based on the available Requirements and with an confirmed approval from the client, further process are to be initiated Some More: Systems Get hanged, application gets logged out very often,invalid o/p for valid i/p,re direction of s application 2 some otherpath. 3. What are the 2 types of matrix document?
a) Traceability matrix b) Test Management Matrix - proposed # of TCs planned in each phases and actual # of TCs covered in these phases (or) Proposed # of TCs planned for automation in a phase against the number of TCs actually automated
4. When we will prepare TM (Traceability matrix), who will prepare it?
During Requirement collection phase and these TM will be validated against the product during system testing or during UAT (user acceptance testing)
What is the use of it?
To make sure all the user requirements are adhered as specified in the requirements document..
Subscribe to:
Posts (Atom)