Usually, testing is considered as a part of the System Development Life Cycle, but it can be also termed as Software Testing Life Cycle or Test Development Life Cycle.
Software Testing Life Cycle consists of the following phases:
1. Planning
2. Analysis
3. Design
4. Execution
5. Cycles
6. Final Testing and Implementation
7. Post Implementation
1. Test Planning (Product Definition Phase):The test plan phase mainly signifies preparation of a test plan. A test plan is a high level planning document derived from the project plan (if one exists) and details the future course of testing. Sometimes, a quality assurance plan - which is more broader in scope than a test plan is also made.
Contents of a Test Plan are as follows :
· Scope of testing
· Entry Criteria (When testing will begin?)
· Exit Criteria (When testing will stop?)
· Testing Strategies (Black Box, White Box, etc.)
· Testing Levels (Integration testing, Regression testing, etc.)
· Limitation (if any)
· Planned Reviews and Code Walkthroughs
· Testing Techniques (Boundary Value Analysis, Equivalence Partitioning, etc.)
· Testing Tools and Databases (Automatic Testing Tools, Performance testing tools)
· Reporting (How would bugs be reported)
· Milestones
· Resources and Training
Contents of a SQA Plan, more broader than a test plan, are as follows :
The IEEE standard for SQA Plan Preparation contains the following outline :
· Purpose
· Reference Documents
· Management
· Documentation
· Standards, Practices and Conventions
· Reviews and Audits
· Software Configuration Management
· Problem Reporting and Corrective Action (Software Metrics to be used can be identified at this stage)
· Tools, Techniques and Methodologies
· Code Control
· Media Control
· Supplier Control
· Records, Collection, maintenance and Retention
2.Test Analysis (Documentation Phase)
The Analysis Phase is more an extension of the planning phase. Whereas the planning phase pertains to high level plans - the Analysis phase is where detailed plans are documented. This is when actual test cases and scripts are planned and documented.
This phase can be further broken down into the following steps :
· Review Inputs : The requirement specification document, feature specification document and other project planning documents are considered as inputs and the test plan is further disintegrated into smaller level test cases.
· Formats : Generally at this phase a functional validation matrix based on Business Requirements is created. Then the test case format is finalized. Also Software Metrics are designed in this stage. Using some kind of software like Microsoft project, the testing timeline along with milestones are created.
· Test Cases : Based on the functional validation matrix and other input documents, test cases are written. Also some mapping is done between the features and test cases.
· Plan Automation : While creating test cases, those cases that should be automated are identified. Ideally those test cases that are relevant for Regression Testing are identified for automation. Also areas for performance, load and stress testing are identified.
· Plan Regression and Correction Verification Testing : The testing cycles, i.e. number of times that testing will be redone to verify that bugs fixed have not introduced newer errors is planned.
3. Test Design (Architecture Document and Review Phase):One has to realize that the testing life cycle runs parallel to the software development life cycle. So by the time, one reaches this phase - the development team would have created some code or at least some prototype or minimum a design document would be have been created.
Hence in the Test Design (Architecture Document Phase) - all the plans, test cases, etc. from the Analysis phase are revised and finalized. In other words, looking at the work product or design - the test cases, test cycles and other plans are finalized. Newer test cases are added. Also some kind of Risk Assessment Criteria is developed. Also writing of automated testing scripts begin. Finally - the testing reports (especially unit testing reports) are finalized. Quality checkpoints, if any, are included in the test cases based on the SQA Plan.
4. Test Execution (Unit / Functional Testing Phase):By this time. the development team would have been completed creation of the work products. Of Course, the work product would still contain bugs. So, in the execution phase - developers would carry out unit testing with testers help, if required. Testers would execute the test plans. Automatic testing Scripts would be completed. Stress and performance Testing would be executed. White box testing, code reviews, etc. would be conducted. As and when bugs are found - reporting would be done.
5. Test Cycle (Re-Testing Phase):By this time, minimum one test cycle (one round of test execution) would have been completed and bugs would have been reported. Once the development team fixes the bugs, then a second round of testing begins. This testing could be mere correction verification testing, that is checking only that part of the code that has been corrected. It could also be Regression Testing - where the entire work product is tested to verify that correction to the code has not affected other parts of the code.
Hence this process of :Testing --> Bug reporting --> Bug fixing (and enhancements) --> Retestingis carried out as planned. Here is where automation tests are extremely useful to repeat the same test cases again and again.During this phase - review of test cases and test plan could also be carried out. 6. Final Testing and Implementation (Code Freeze Phase):When the exit criteria is achieved or planned test cycles are completed, then final testing is done. Ideally, this is System or Integration testing. Also any remaining Stress and Performance testing is carried out. Inputs for process improvements in terms of software metrics is given. Test reports are prepared. if required, a test release note, releasing the product for roll out could be prepared. Other remaining documentation is completed.
7. Post Implementation (Process Improvement Phase):This phase, that looks good on paper, is seldom carried out. In this phase, the testing is evaluated and lessons learnt are documented. Software Metrics (Bug Analysis Metrics) are analyzed statistically and conclusions are drawn. Strategies to prevent similar problems in future projects is identified. Process Improvement Suggestions are implemented. Cleaning up of testing environment and Archival of test cases, records and reports are done.
Tuesday, August 19, 2008
Software Test Life Cycle
Posted by Software Tester at 8:21 AM 0 comments
Sunday, August 17, 2008
Database Testing Interview Questions
1. What we normally check for in the Database Testing?
In DB testing we need to check for,
1. The field size validation
2. Check constraints.
3. Indexes are done or not (for performance related issues)
4. Stored procedures
5. The field size defined in the application is matching with that in the db.
2. What is Database testing?
Data bas testing basically include the following.
1)Data validity testing.
2)Data Integritity testing
3)Performance related to data base.
4)Testing of Procedure,triggers and functions.for doing data validity testing you should be good in SQL queriesFor data integrity testing you should know about referintial integrity and different constraint.For performance related things you should have idea about the table structure and design.for testing Procedure triggers and functions you should be able to understand the same.
3. How to Test database in Manually? Explain with an example
Observing that opertaions, which are operated on front-end is effected on back-end or not.The approach is as follows :While adding a record thr' front-end check back-end that addition of record is effected or not. So same for delete, update,...... Ex:Enter employee record in database thr' front-end and check if the record is added or not to the back-end(manually).
4. What is data driven test?
An1:Data driven test is used to test the multinumbers of data in a data-table, using this we can easy to replace the paramerers in the same time from deferent locations.e.g: using .xsl sheets.
An2:Re-execution of our test with different input values is called Re-testing. In validate our Project calculations, test engineer follows retesting manner through automation tool.Re-teting is also called DataDriven Test.
There are 4 types of datadriven tests.
1) Dynamic Input submissiion (key driven test) : Sometines a test engineer conducts retesting with different input values to validate the calculation through dynamic submission.For this input submission, test engineer use this function in TSL scriipt-- create_input_dialog ("label");
2) Data Driven Files Through FLAT FILES ( .txt,.doc) : Sometimes testengineer conducts re-testing depends on flat file contents. He collect these files from Old Version databases or from customer side.
3)Data Driven Tests From FRONTEND GREAVES : Some times a test engineer create automation scripts depends on frontend objects values such as (a) list (b) menu (c) table (d) data window (e) ocx etc.,
4)Data Driven Tests From EXCEL SHEET : sometimes a testengineer follows this type of data driven test to execute their script for multiple inputs. These multiple inputs consists in excel sheet columns. We have to collect this testdata from backend tables .
5. How to check a trigger is fired or not, while doing database testing?
It can be verified by querying the common audit log where we can able to see the triggers fired.
6. How to Test Database Procedures and Triggers?
Before testing Data Base Procedures and Triggers, Tester should know that what is the Input and out put of the procedures/Triggers, Then execute Procedures and Triggers, if you get answer that Test Case will be pass other wise fail. These requirements should get from DEVELOPER
7. Is a "A fast database retrieval rate" a testable requirement?
No. I do not think so. Since the requirement seems to be ambiguous. The SRS should clearly mention the performance or transaction requirements i.e. It should say like 'A DB retrival rate of 5 micro sec'.
8. How to test a DTS package created for data insert update and delete? What should be considered in the above case while testing it?What conditions are to be checked if the data is inserted, updated or deleted using a text files?
Data Integrity checks should be performed. IF the database schema is 3rd normal form, then that should be maintained. Check to see if any of the constraints have thrown an error. The most important command will have to be the DELETE command. That is where things can go really wrong. Most of all, maintain a backup of the previous database.
9.How to test a SQL Query in Winrunner? without using DataBase CheckPoints?
By writing scripting procedure in the TCL we can connect to the database and we can test data base and queries. The exact proccess should be: 1)connect to the databasedb_connect("query1",DRIVER={drivername};SERVER=server_name;UID=uidname;PWD=password;DBQ=database_name "); 2)Execute the querydb_excecute_query("query1","write query u want to execute");-Condition to be mentioned-3)disconnect the connectiondb_disconnect("query");
10. How do you test whether a database in updated when information is entered in the front end?
It depend on your application interface..
1. If your application provides view functionality for the entered data, then you can verify that from front end only. Most of the time Black box test engineers verify the functionality in this way.
2. If your application has only data entry from front end and there is no view from front end, then you have to go to Database and run relevent SQL query.
3. You can also use database checkpoint function in WinRunner.
11. How do you test whether the database is updated as and when an information are added in the front end?Give me an example?
It depends on what level of testing you are doing.When you want to save something from front end obviously, it has to store somewhere in the database You will need to find out the relevant tables involved in saving the records.Data Mapping from front end to the tables.Then enter the data from front end and save. Go to database, fire queries to get the same date from the back end.
12. What steps does a tester take in testing Stored Procedures?
First the tester should to go through the requirement, as to why the particular stored procedure is written for. Then check whether all the required indexes, joins, updates, deletions are correct comparing with the tables mentions in the Stored Procedure. And also he has to ensure whether the Stored Procedure follows the standard format like comments, updated by, etc. Then check the procedure calling name, calling parameters, and expected reponses for different sets of input parameters. Then run the procedure yourself with database client programs like TOAD, or mysql, or Query Analyzer Rerun the procedure with different parameters, and check results against expected values. Finally, automate the tests with WinRunner.
13. What are the different stages involved in Database Testing
verify field level data in the database with respect to frontend transactionsverify the constraint (primary key,forien key ....)verify the performance of the proceduresverify the triggrs (execution of triggers)verify the transactions (begin,commit,rollback)
14. How to use sql queries in WinRunner/QTP
in QTPusing output databse check point and database check point ,select SQL manual queries optionand enter the "select" queris to retrive data in the database and compare the expected and actual
15. what is database testing and what we test in database testing?
An1:Database testing is all about testing joins, views, inports and exports , testing the procedures, checking locks, indexing etc. Its not about testing the data in the database. Usually database testing is performed by DBA.
An2:Database testing involves some in depth knowledge of the given application and requires more defined plan of approach to test the data.
Key issues include:
1) Data Integrity
2) Data Validity
3) Data Manipulation and updatesTester must be aware of the database design concepts and implementation rules.
An3:Data bas testing basically include the following.
1)Data validity testing.
2)Data Integritity testing
3)Performance related to data base.
4)Testing of Procedure,triggers and functions.for doing data validity testing you should be good in SQL queriesFor data integrity testing you should know about referintial integrity and different constraint.For performance related things you should have idea about the table structure and design.for testing Procedure triggers and functions you should be able to understand the same.
16. What SQL statements have you used in Database Testing?
The most important statement for database testing is the SELECT statement, which returns data rows from one or multiple tables that satisfies a given set of criteria. You may need to use other DML (Data Manipulation Language) statements like INSERT, UPDATE and DELTE to manage your test data. You may also need to use DDL (Data Definition Language) statements like CREATE TABLE, ALTER TABLE, and DROP TABLE to manage your test tables. You may also need to some other commands to view table structures, column definitions, indexes, constraints and store procedures.
17. How to test data loading in Data base testing?
You have to do the following things while you are involving in Data Load testing.
1. You have know about source data (table(s), columns, datatypes and Contraints)
2. You have to know about Target data (table(s), columns, datatypes and Contraints)
3. You have to check the compatibility of Source and Target.
4. You have to Open corresponding DTS package in SQL Enterprise Manager and run the DTS package (If you are using SQL Server).
5. Then you should compare the column's data of Source and Target.
6. You have to check the number to rows of Source and Target.
7. Then you have to update the data in Source and see the change is reflecting in Target or not.
8. You have to check about junk character and NULLs.
18. What is way of writing testcases for database testing?
An1:You have to do the following for writing the database testcases.
1. First of all you have to understand the functional requirement of the application throughly.
2. Then you have to find out the back end tables used, joined used between the tables, cursors used (if any), tiggers used(if any), stored procedures used (if any), input parmeter used and output parameters used for developing that requirement.
3. After knowing all these things you have to write the testcase with different input values for checking all the paths of SP. One thing writing testcases for backend testing not like functinal testing. You have to use white box testing techniques.
An2:To write testcase for database its just like functional testing.
1.Objective:Write the objective that you would like to test. eg: To check the shipment that i load thru xml is getting inserted for perticular customer.
2.Write the method of input or action that you do. eg:Load an xml with all data which can be added to a customer.
3.Expected :Input should be viewd in database. eg: The shipment should be loaded sucessfully for that customer,also it should be seen in application.
4.You can write ssuch type of testcases for any functionality like update,delete etc.
An3:At first we need to go through the documents provided. Need to know what tables, stored procedures are mentioned in the doc.Then test the functionality of the application. Simultaneously, start writing the DB testcases.. with the queries you have used at the backend while testing, the tables and stored procedures you have used in order to get the desired results. Trigers that were fired. Based on the stored procedure we can know the functionality for a specific peice of the application. So that we can write queries related to that. From that we make DB testcases also.
19;What is Database testing?
An1:here database testing means test engineer should test the data integrity, data accessing,query retriving,modifications,updation and deletion etc
An2:Database tests are supported via ODBC using the following functions: SQLOpen, SQLClose, SQLError, SQLRetrieve, SQLRetrieveToFile, SQLExecQuery, SQLGetSchema and SQLRequest. You can carry out cursor type operations by incrementing arrays of returned datasets. All SQL queries are supplied as a string. You can execute stored procedures for instance on SQL Server you could use “Exec MyStoredProcedure” and as long as that stored procedure is registered on the SQL Server database then it should execute however you cannot interact as much as you may like by supplying say in/out variables, etc but for most instances it will cover your database test requirements
An3:Data bas testing basically include the following.
1)Data validity testing.
2)Data Integritity testing
3)Performance related to data base.
4)Testing of Procedure,triggers and functions. for doing data validity testing you should be good in SQL queries For data integrity testing you should know about referintial integrity and different constraint. For performance related things you should have idea about the table structure and design. for testing Procedure triggers and functions you should be able to understand the same.
An4:Data base testing generally deals with the follwoing:
a)Checking the integrity of UI data with Database Datab)
b)Checking whether any junk data is displaying in UI other than that stored in Databasec)
c)Checking execution of stored procedures with the input values taken from the database tablesd)
d)Checking the Data Migration .
e)Execution of jobs if any
20. What we normally check for in the Database Testing?
An1:In DB testing we need to check for,
1. The field size validation
2. Check constraints.
3. Indexes are done or not (for performance related issues)
4. Stored procedures
5. The field size defined in the application is matching with that in the db.
An2:Database testing involves some indepth knowledge of the given application and requires more defined plan of approach to test the data. Key issues include :
1) data Integrity
2) data validity
3) data manipulation and updates. Tester must be aware of the database design concepts and implementation rules
Posted by Software Tester at 3:19 AM 0 comments
WinRunner FAQ
What’s the WinRunner?
WinRunner is Mercury Interactive Functional Testing Tool.
How many types of Run Modes are available in WinRunner?
WinRunner provide three types of Run Modes. Verify ModeDebug ModeUpdate Mode
What’s the Verify Mode?
In Verify Mode, WinRunner compare the current result of application to it’s expected result.
What’s the Debug Mode?
In Debug Mode, WinRunner track the defects in a test script.
What’s the Update Mode?
In Update Mode, WinRunner update the expected results of test script.
How many types of recording modes available in WinRunner?
WinRunner provides two types of Recording Mode:Context SensitiveAnalog
What’s the Context Sensitive recording?
WinRunner captures and records the GUI objects, windows, keyboard inputs, and mouse click activities through Context Sensitive Recording.
What’s the Analog recording?
It captures and records the keyboard inputs, mouse click and mouse movement. It’s not captures the GUI objects and Windows.
Where are stored Debug Result?
Debug Results are always saved in debug folder.
What’s WinRunner testing process?
WinRunner involves six main steps in testing process. Create GUI mapCreate TestDebug TestRun TestView ResultsReport Defects
What’s the GUI SPY?
You can view the physical properties of objects and windows through GUI SPY.
How many types of modes for organizing GUI map files?
WinRunner provides two types of modes- Global GUI map filesPer Test GUI map files
What’s the contained in GUI map files?
GUI map files stored the information, it learns about the GUI objects and windows.
How does WinRunner recognize objects on the application?
WinRunner recognize objects on the application through GUI map files.
What’s the difference between GUI map and GUI map files?
The GUI map is actually the sum of one or more GUI map files.
How do you view the GUI map content?
We can view the GUI map content through GUI map editor.
What’s the checkpoint?
Checkpoint enables you to check your application by comparing it’s expected results of application to actual results.
What’s the Execution Arrow?
Execution Arrow indicates the line of script being executed.
What’s the Insertion Point?
Insertion point indicates the line of script where you can edit and insert the text.
What’s the Synchronization?
Synchronization is enables you to solve anticipated timing problems between test and application.
What’s the Function Generator?
Function Generator provides the quick and error free way to add TSL function on the test script.
How many types of checkpoints are available in WinRunner?
WinRunner provides four types of checkpoints- GUI CheckpointBitmap CheckpointDatabase CheckpointText Checkpoint
What’s contained in the Test Script?
Test Script contained the Test Script Language.
How do you modify the logical name or the physical description of the objects in GUI map?
We can modify the logical name or the physical description of the objects through GUI map editor.
What are the Data Driven Test?
When you want to test your application, you may want to check how it performance same operation with the multiple sets of data.
How do you record a Data Driven Test?
We can create a Data Driven Test through Flat Files, Data Tables, and Database.
How do you clear a GUI map files?
We can clear the GUI map files through “CLEAR ALL” option.
What are the steps of creating a Data Driven Test?
Data Driven Testing have four steps- Creating testConverting into Data Driven TestRun TestAnalyze test
What’s the extension of GUI map files?
GUI map files extension is “.gui”.
What statement generated by WinRunner when you check any objects?
Obj_check_gui statement.
What statement generated by WinRunner when you check any windows?
Win_check_gui statement
What statement generated by WinRunner when you check any bitmap image over the objects?
Obj_check_bitmap statement
What statement generated by WinRunner when you check any bitmap image over the windows?
Win_check_bitmap statement
What statement used by WinRunner in Batch Testing?
“Call” statement.
Which short key is used to freeze the GUI Spy?
“Ctrl+F3”
How many types of parameter used by WinRunner?
WinRunner provides three types of Parameter- TestData DrivenDynamic
How many types of Merging used by WinRunner?
WinRunner used two types of Merging- AutoManual
What’s the Virtual Objects Wizard?
Whenever WinRunner is not able to read an objects as an objects then it uses the Virtual Objects Wizard.
How do you handle unexpected events and errors?
WinRunner uses the Exception Handling function to handle unexpected events and errors.
How do you comment your script?
We comment script or line of the script by inserting “#” at the beginning of script line.
What’s the purpose of the Set_Windows command?
Set_Window command set the focus to the specified windows.
How you created your test script?
Programming.
What’s a command to invoke application?
Invoke_application
What do you mean by the logical name of objects?
Logical name of an objects is determined by it’s class but in most cases, the logical name is the label that appear on an objects.
How many types of GUI checkpoints?
In Winrunner, three types of GUI checkpoints- For Single PropertiesFor Objects/WindowsFor Multiple Objects
How many types of Bitmap Checkpoints?
In Winrunner, two types of Bitmap Checkpoints- For Objects/WindowsFor Screen Area
How many types of Database Checkpoints?
In Winrunner, three types of Database Checkpoints- Default CheckCustom CheckRuntime Record Check
How many types of Text Checkpoints?
In Winrunner, four types of Text Checkpoints- For Objects/WindowsFrom Screen AreaFrom Selection (Web Only)Web text CheckpointsNotes:* Winrunner generates menu_select_item statement whenever you select any menu items.* Winrunner generates set_window statement whenever you begin working in new window.* Winrunner generates edit_set statement whenever you enter keyboard inputs.* Winrunner generates obj_mouse_click statement whenever you click any object through mouse pointer.* Winrunner generates obj_wait_bitmap or win_wait_bitmap statements whenever you synchronize the script through objects or windows.* The ddt_open statement opens the table.* The ddt_close statement closes the table.* Winrunner inserts a win_get_text or obj_get_text statements in script for checking the text.* The button_press statement press the buttons.* Winrunner generates list_item_select statement whenever you want to select any value in drop-down menu.* We can compare the two files in Winruuner using the file_compare function.* tl_step statement used to determine whether section of a test pass or fail.* Call_Close statement close the test when the test is completed
Posted by Software Tester at 3:00 AM 0 comments
Thursday, August 14, 2008
Interview Questions of Software Testing
What’s the Software Testing?
A set of activities conducted with the intent of finding errors in software.
What’s the Test Plan?
A high level of documents that define the software testing project.
What’s the Test Case?
A set of test inputs, execution, and expected result developed for a particular objective.
What’s the Test Log?
A chronological record of all relevant details about the execution of a test.
What’s the Test Data?
The actual values used in the test or that are necessary to execute the test.
What’s the Database testing?
In database testing, we can check the integrity of database field values.
What’s the Defect?
The difference between the functional specification and actual program text.
What’s the Negative testing?
That testing is designed for break the system.
What’s the Test Bed?
An environment that contain different types of hardware, software, simulator, testing tools, and other support elements that are necessary to conduct a test.
What’s the Test Condition?
A set of circumstances that a test invokes.
What’s the Usability testing?
Usability testing is for user friendliness.
What’s the Volume Testing?
We can perform the Volume testing, where the system is subjected to large volume of data.
What’s the Black Box testing?
Black Box testing is not based on any knowledge of internal logic.
What’s the White Box testing?
White Box testing is based on knowledge of internal logic.
What’s the Regression Testing?
After every update we should test the system and check the effects on all venerable point of system
What’s the System Testing?
After integration of all module check the correctness of functional flow of system.
What’s the performance Testing?
In performance testing we can check the system with valid entry data and minimize the blocker condition possibility.
What’s the Defect Tracking?
Defect tracking is the process of finding bugs in software.
What’s the Unit Testing?
Testing of individual component of software.
What’s the Test Tool?
A computer program that used in testing the systems.
What’s the Test Driver?
A program or test tool used to execute test.
What’s the End-To-End Testing?
Testing a complete application environment in a situation that mimics a real world use.
What’s Coding?
A generation of source code.
What’s the Cause Effect Graph?
It’s graphical representation of inputs and the output effects that are used to design test case.
What’s the Test Life Cycle?
A Test Life Cycle is contains seven steps-
Plan Test
Design Test Case
Run Test
Analyze Result
Documents Test Result
Preparation of Validation report
Regression Testing
What’s the Validation?
Validation refers to a set of activities that ensure that the software has been built is traceable to customer requirements.
What’s the Verification?
Verification refers to a set of activities that ensure that correctly implements a specific function.
What’s Ad Hoc Testing?
A testing where the tester tries to break the software by randomly trying functionality of software.
What’s Compatibility Testing?
In Compatibility testing we can test that software is compatible with other elements of system.
What’s the Data Flow Diagram?
A modeling notation that represent the functional composition of a system.
What’s the Debugging?
Debugging is the method of finding and rectifying the cause of software failures.
What’s the Positive Testing?
In positive testing we can assume that software is working fine.
Who’s the good software engineer?
A good software engineer has “test to break” attitude, an ability to take the point of view of the customers, and strong quality desire.
What’s the Security Testing?
A testing which confirms that the software can restrict the access of unauthorized personnel.
What’s the Software Requirement Specification?
A deliverable that describe all data, functional and behavioral requirement, and all validation requirements for software.
What’s the Static Testing?
In Static testing we can analyze the source code to expose potential defects.
What’s the Accessibility Testing?
Testing that determines if software will be usable by people with disabilities.
What’s the Bottom-up Testing?
An approach to integration testing where the lowest level component are tested first.
What’s the Smoke Testing?
A Smoke testing is a cursury examination of all of of the basic components of the software to ensure that they will work correctly.
What’s the Boundry Value Analysis?
Boundry Valuse Analysis is a test data selection technique in whice values are choosen maximum, minimum, just inside, just outside boundries, typical values, and error values. The hope is then if software work correctly for these values then it’s will works for all values in between.
What’s the Top-Down testing?
An approach to integration testing where the top level component are tested first.
What’s the Acceptance Testing?
A testing conducted to enable a user or customer to determine whether to accept a software project.
What’s the Functional Testing?
In Functional Testing, we can test features or operational behaviour of a product to ensure that they correspond to it’s requirements.
What’s the Integration Testing?
In Integration Testing, we can test combined parts of application to determine if they work together correctly.
When we performed Integration Testing?
Usually performed after unit and functional testing.
What’s the Test Scenario?
It defines a set of test cases or test scripts and the sequences in which they are to be executed.
What’s the Traceability Matrix?
A document that showing the relationship between Test Requirements and Test Cases.
What’s the Validation Strategies?
A Validation Strategies are-
Unit Testing
Integration Testing
System testing
End to End Testing
User Acceptance Testing
Installation Testing
Beta Testing
What’s the Verification Strategies?
A Verification Strategies are-
Requirement Reviews
Design Reviews
Code Walkthrough
Code Inspections
What’s the Code Walkthrough?
Code Walkthrough help in analyzing the coding techniques and if the code is meeting the coding standards.
What’s the Code Inspections?
Code Inspections is formal analysis of the program source code to find defects as defind by meeting system design specifications.
What’s the Beta Testing?
Testing the application after the installation at the client place.
What’s the Installation Testing?
Testing the computer system during the installation.
How many types of testing?
There are two types of testing-
Functional- Black Box Testing
Structural- white Box Testing
How many types of approaches are used in Integration Testing?
There are two types of approaches used-
Bottom-Up
Top-Down
What’s the Alpha Testing?The Alpha Testing is conducted at the developer sites and in a controlled environment by the end user of the software
Posted by Software Tester at 5:13 AM 0 comments
Wednesday, August 13, 2008
Software Metric
Definition of Software Metrics
A metric is a mathematical number that shows a relationship between two variables. It is a quantitative measure of the degree to which a system, component or process possesses a given attribute. Software Metrics are measures that are used to quantify the software, software development resource and software development process.
· Process Metric
· Product Metric
Process Metric a metric used to measure the characteristic of the methods, techniques and tools employed in developing, implementing and maintaining the software system.
Product Metric a metric used to measure the characteristic of the documentation and code
The metrics for the test process would include status of test activities against the plan, test coverage achieved so far, among others. An important metric is the number of defects found in internal testing compared to the defects found in customer tests, which indicate the effectiveness of the test process itself.
Test Metrics
The following are the Metrics collected in testing process
User participation = User Participation Test Time Vs Total Test Time
Path Tested = Number of Path Tested Total Number of Paths
Acceptance Criteria Tested = Acceptance Criteria Verified Vs Total Acceptance Criteria
Cost to Locate Defect
Test Cost
=
No of Defects located in the Testing
This metric shows the cost to locate a defect Detected
Production Defect
No of Defects detected in production
=
Application System size
Test Automation
Cost of Manual Test Effort
=
Total Test Cost
Posted by Software Tester at 10:11 PM 0 comments
Test Reports
A final test report should be prepared at the conclusion of each test activity. This might include
· Individual Project Test Report (e.g., a single software system)
· Integration Test Report
· System Test Report
· Acceptance Test Report
The test reports are designed to document the results of testing as defined in the test plan. Without a well-developed test plan, which has been executed in accordance with its criteria, it is difficult to develop a meaningful test report.
It is designed to accomplish three objectives:
· Define the scope of testing - normally a brief recap of the test plan;
· Present the results of testing; and
· Draw conclusions and make recommendations based on those results
The test report may be a combination of electronic data and hard copy. For example, if the function test matrix is maintained electronically, there is no reason to print that, as the paper report will summarize that data, draws the appropriate conclusions, and present recommendations.
The test report has one immediate and three long-term purposes. The immediate purpose is to provide information to the customers of the software system so that they can determine whether the system is ready for production: and if so, to assess the potential consequences and initiate appropriate actions to minimize those consequences.
The first of the three long-term uses is for the project to trace problems in the event the application malfunctions in production. Knowing which functions have been correctly tested and which ones still contain defects can assist in taking corrective action.
The second long-term purpose is to use the data to analyze the rework process for making changes to prevent defects from occurring in the future. Accumulating the results of many test reports to identify which components of the rework process are detect-prone does this. These defect-prone components identify tasks/steps that, if improved, could eliminate or minimize the occurrence of high-frequency defects.
The third long-term purpose is to show what was accomplished.
Individual Project Test Report
These reports focus on individual projects (e.g., software system). When different testers test individual projects, they should prepare a report on their results.
Integration Test Report
Integration testing tests the interfaces between individual projects. A good test plan will identify the interfaces and institute test conditions that will validate interfaces. Given this, the interface report follows the same format as the individual Project Test report, except that the conditions tested are the interfaces.
System Test Report
A system test plan standard that identified the objectives of testing, what was to be tested, how it was to be tested and when tests should occur. The System Test report should present the results of executing that test plan. If this is maintained electronically, it need only be referenced, not included in the report.
Acceptance Test Report
There are two primary objectives for testing. The first is to ensure that the system as implemented meets the real operating needs of the user or customer. If the defined requirements are those true needs, the testing should have accomplished this objective. The second objective is to ensure that the software system can operate in the real-world user environment, which includes people skills and attitudes, time pressures, changing business conditions, and so forth.
Eight Interim Reports:
1. Functional Testing Status
2. Functions Working Timeline
3. Expected verses Actual Defects Detected Timeline
4. Defects Detected verses Corrected Gap Timeline
5. Average Age of Detected Defects by Type
6. Defect Distribution
7. Relative Defect Distribution
8. Testing Action
Functional Testing Status Report
This report will show percentages of the functions, which have been:
· Fully Tested
· Tested With Open Defects
· Not Tested
Functions Working Timeline report
This report will show the actual plan to have all functions working verses the current status of functions working. An ideal format could be a line graph.
Expected verses Actual Defects Detected report
This report will provide an analysis between the number of defects being generated against the expected number of defects expected from the planning stage
Defects Detected verses Corrected Gap report
This report, ideally in a line graph format, will show the number of defects uncovered verses the number of defects being corrected and accepted by the testing group. If the gap grows too large, the project may not be ready when originally planned.
Average Age Detected Defects by Type report
This report will show the average outstanding defects by type (severity 1, severity 2, etc.). In the planning stage, it is benefic determine the acceptable open days by defect type.
Defect Distribution report
This report will show the defect distribution by function or module. It can also include items such as numbers of tests completed.
Relative Defect Distribution report
This report will take the previous report (Defect Distribution) and normalize the level of defects. An example would be one application might be more in depth than another, and would probably have a higher level of defects. However, when normalized over the number of functions or lines of code, would show a more accurate level of defects.
Testing action report
This report can show many different things, including possible shortfalls in testing. Examples of data to show might be number of severity defects, tests that are behind schedule, and other information that would present an accurate testing picture
Posted by Software Tester at 9:52 PM 0 comments
Defect Tracking
Defects are recorded for following major purposes:
· To correct the defect
· To report status of the application
· To gather statistics used to develop defect expectations in future applications
· To improve the software development process
Most project teams utilize some type of tool to support the defect tracking process. This tool could be as simple as a white board or a table created and maintained in a word processor or one of the more robust tools available today, on the market, such as Mercury's Test Director etc. Tools marketed for this purpose usually come with some number of customizable fields for tracking project specific data in addition to the basics. They also provide advanced features such as standard and ad-hoc reporting, e-mail notification to developers and/or testers when a problem is assigned to them, and graphing capabilities.
At a minimum, the tool selected should support the recording and communication significant information about a defect. For example, a defect log could include:
· Defect ID number
· Descriptive defect name and type
· Source of defect -test case or other source
· Defect severity
· Defect priority
· Defect status (e.g. open, fixed, closed, user error, design, and so on) -more robust tools provide a status history for the defect
· Date and time tracking for either the most recent status change, or for each change in the status history
· Detailed description, including the steps necessary to reproduce the defect
· Component or program where defect was found
· Screen prints, logs, etc. that will aid the developer in resolution process
· Stage of origination
· Person assigned to research and/or correct the defect
Severity versus Priority
The severity of a defect should be assigned objectively by the test team based on pre defined severity descriptions. For example a "severity one" defects maybe defined as one that causes data corruption, a system crash, security violations, etc. In large project, it may also be necessary to assign a priority to the defect, which determines the order in which defects should be fixed. The priority assigned to a defect is usually more subjective based upon input from users regarding which defects are most important to them, and therefore should be fixed first.
It is recommended that severity levels be defined at the start of the project so that they intently assigned and understood by the team. This foresight can help test teams avoid the common disagreements with development teams about the criticality of a defect.
Some general principles
· The primary goal is to prevent defects. Wherever this is not possible or practical, the goals are to both find the defect as quickly as possible and minimize the impact of the defect.
· The defect management process, like the entire software development process, should be risk driven, i.e., strategies, priorities and resources should be based on an assessment of the risk and the degree to which the expected impact of risk can be reduced.
· Defect measurement should be integrated into the development process and be used by the project team to improve the development process. In other words, information on defects should be captured at the source as a natural by-product of doing the job. People unrelated to the project or system should not do it.
· As much as possible, the capture and analysis of the information should be automated. There should be a document, which includes a list of tools, which have defect management capabilities and can be used to automate some of the defect management processes.
· Defect information should be used to improve the process. This, in fact, is the primary reason for gathering defect information.
· Imperfect or flawed processes cause most defects. Thus, to prevent defects, the process must be altered.
The Defect Management Process
The key elements of a defect management process are as follows.
· Defect prevention
· Deliverable base-lining
· Defect discovery/defect naming
· Defect resolution
· Process improvement
· Management reporting
Posted by Software Tester at 9:41 PM 0 comments