Performance testing - It is performed to evaluate the performance of components of a particular system in a specific situation. It very wide term. It includes: Load Testing, Stress Testing, capacity testing, volume testing, endurance testing, spike testing, scalability testing and reliability testing etc. This type of testing generally does not give pass or fail. It is basically done to set the benchmark & standard of the application against Concurrency / Throughput, Server response time, Latency, Render response time etc. In other words, you can say it is technical & formal evaluation for responsiveness, speed, scalability and stability characteristics.

Smoke Testing: Software Testing done to ensure that whether the build can be accepted for through software testing or not. Basically, it is done to check the stability of the build received for software testing.

Introduction:

• HP quality center is web-based test management tool
• QC is used to manage the application testing process
• QC is used to define releases, specifying requirements, planning tests, executing tests, tracking defects, alerting on changes, and analyzing results
• QC also shows you how to customize your project
• Defect: Anything that is extra or missing or wrong in application is termed as defect
• QC helps you to add defects to application when found and track the defect repair progression.
• QC provides a central defect tracking system that can be used by testing and development teams to resolve defects

QC testing process includes 5 phases:

• Specifying release
• Specifying requirements
• Planning Tests
• Running Tests
• Tracking Defects

Defect Modules:

• QC Defect module provides complete system for logging, tracking, managing, and analyzing application defects
• QC Defect tracking tools are organized into: Defects grid, Grid filter, Description, Attachments, History

Defect Logging: Steps to Log a defect

• In Defect module, click New Defect
• New defect dialog box contains data fields and multiple tabbed pages. This multiple tabbed pages are custom-defined by QC administrator for your project
• You can also add attachments to provide more information about the defect. QC supports five types of attachments
• Click Submit to save the defect to your project database

Defect Organizing - Grid filter provides two ways to organize defect grid:

• Use entry boxes under each field heading in grid filter to select the criteria for filtering the data in the defects grid
• Use the Filter dialog box to set a filter condition
• To clear filter criteria, click the Clear Filter/Sort button

Defect Status:

• New: Default status when defect is reported
• Open: Indicates defect is assigned to review
• Reopen: Indicates testing team reopened the defect which was closed
• Fixed: Indicates defect is verified
• Closed: Defect is closed and waiting fro approval by tester
• Rejected: Defect is rejected , rationale fore rejecting defect to be provided

Defect association with other entities - Defects can be associated with the following entities:

• Requirement
• Test
• Test set
• Test instance
• Test run
• Test steps
• Other Defect

This linkage of defects with entities enables to

• Trace your defects from perspective of QC entities
• Search defects that are related to specific QC entities
• Link multiple entities of same type to the same defect

Defect Requirement:

• Associating defects with test requirements will help to ensure consistency throughout the testing process
• The defect-requirement association enables us to utilize the status of defects to determine whether requirements have been met
• A requirement can be associated with more than one defect
• Either a existing defect can be associated with the requirement or new defect can be added to requirement

Defect Test:

• Association of defect with test helps to ensure defect traceability throughout the testing process. A defect may be indirectly linked to a test through other entities, such as a test instance, a test run, or a test step
• Tests from Test plan module can be associated with defects that have been logged in the Defects module

Defect Matching:

• Matching defects enables you to eliminate similar and duplicate defects in your project
• Each time you add a new defect, Quality Center stores lists of keywords from the Summary and Description fields
• When you search for similar defects, keywords in these fields are matched against other defects
• Note that keywords must be more than two characters and letter case does not affect your results

Updating the defects:

• A defect can be regularly updated to record all the information about an issue.
• A defect can be regularly updated to record decisions made as different individuals review the defect.
• While updating the defect ,click Details to update specific data fields.
• Click Attachments to attach files to defect.
• Click Linked entities and then click the Defects tab to link a defect to another defect.
• Click Others tab to link a defect to other entities such as a test or test set.
• Click History to view the changes made to defect.

Favorite view: A favorite view is a view of a Quality Center window with the settings you applied to it. Steps to create favorite view in defects grid:

• Defect module should be displayed
• Define a filter to view defects, Click the Set Filter/Sort button. The Filter dialog box opens.
• Click the Filter Condition box, Click the browse button. The Select Filter Condition dialog box opens. Click OK to close the Select Filter Condition dialog box. Click OK to apply your chosen filter.
• Add a favorite view. In the Favorites menu, choose Add to Favorites. The Add Favorite dialog box opens.

Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as expected. Each unit is tested separately before integrating them into modules to test the interfaces between modules.By means of effective Unit testing large percentage of defects are identified. Unit testing is performed by developers.

Each module that is developed by designers need to be tested individually to verify proper operation so that any faulty module can be fixed immediately rather than let it exist and then cause some major issue in the integration phase. Once all of the units in a program have been found to be working efficiently and without any bugs, larger components of the program can be evaluated by means of integration testing. Though Unit testing may be time consuming, tedious and requires thoroughness on the part of the development team, but in the long run it can avoid major pitfalls in the software.

Benefits of unit testing:

• The modular approach during Unit testing eliminates the dependency on other modules during testing. 
• We can test parts of a project with out waiting for the other parts to be available.
• Designers can identify and fix problem immediately, as the modules are best known to them. This helps in fixing multiple problems simultaneously.
• Cost of fixing a defect identified during the early stages is less compared to that during later stage.
• Debugging is simplified. 
• Structural coverage of code is higher.
• Unit testing is more cost effective compared to the other stages of testing

Misconceptions about Unit Testing:

• Integration Tests will Catch all the Bugs Anyway: This is one of the common misconceptions of designers. Complexity of the issue rises while it passes through various testing cycles and then when the bug is raised during the later stages, the resolution time will be high as the scope of the bug widens. It is better to weed off the crop before it poisons the whole farm.
• Programmers Dilemma: Most designers believe Unit testing is not actually required as it is time consuming. They feel they are too good programmers and their software doesn’t need Unit tests. But in the real world, everyone makes mistakes. Real software systems are much more complex. Software behavior various in different environment and with different scenarios. Coding is not a one pass process. Enhancements to the code can be made only when we know the existing module is functioning as expected.
• It Consumes Too Much Time: Developers are often in a hurry to complete their code and integrate it. Unit Testing is most often considered a useless activity, as they feel anyways the code will be tested by QA. There is no point in having a system which works but not exactly as it is supposed to function and is  to be full of bugs. Practically, such an approach to development will often result in software which will not even run. The net result is that a lot of time will be spent tracking down relatively simple bugs which are wholly contained within particular units. Individually, such bugs may be trivial, but collectively they result in an excessive period of time integrating the software to produce a system which is unlikely to be reliable. This can also lead to failure to meet the required deadlines.

Unit Testing Best Practices:

• Ensure each Unit Test case is independent of each other. As the software is prone to changes during the Unit Testing due to enhancements/changes to the requirements. Hence any given behavior should be specified in one and only one test. Otherwise if you later change that behavior, you’ll have to change multiple tests.
• Test only one code at a time. It is always recommended to test each of the modules independently and not while all are chained together. Otherwise you will have lots of overlap between tests and changes to one unit may effect all other modules and cause the software to fail.
• Name your unit tests clearly and consistently. Ensure that your test cases are easily readable so that anyone picking up Unit test cases can execute them without any issues. Ensure the test case nomenclature is consistent throughout.
• Before changing a module interface or implementation, make sure that the module has test cases and that it passes its tests before changing the implementation. This way you can know that your changes didn't break anything.
• Always ensure the bug identified during Unit Testing is fixed before moving it to the next phase.

Unit Testing  Techniques: Structural, Functional & Error based Techniques

Structural Techniques: It is a White box testing technique that uses an internal perspective of the system to design test cases based on internal structure. It requires programming skills to identify all paths through the software. The tester chooses test case inputs to exercise paths through the code and determines the appropriate outputs. Major Structural techniques are:

• Statement Testing: A test strategy in which each statement of a program is executed at least once. 
• Branch Testing: Testing in which all branches in the program source code are tested at least once.
• Path Testing: Testing in which all paths in the program source code are tested at least once.
• Condition Testing: Condition testing allows the programmer to determine the path through a program by selectively executing code based on the comparison of a value  
• Expression Testing: Testing in which the application is tested for different values of Regular Expression.

Functional testing techniques: These are Black box testing techniques which tests the functionality of the application. Some functionality testing techniques are:

• Input domain testing: This testing technique concentrates on size and type of every input object in terms of boundary value analysis and Equivalence class.  
• Boundary Value: Boundary value analysis is a  software testing design technique in which tests are designed to include representatives of boundary values.  
• Syntax checking: This is a technique which is used to check the Syntax of the application. 
• Equivalence Partitioning: This is a software testing technique that divides the input data of a software unit into partition of data from which test cases can be derived

Error based Techniques: The best person to know the defects in his code is the person who has designed it.
Few of the Error based techniques are:

• Fault seeding techniques can be used so that known defects can be put into the code and tested until they are all found.
• Mutation Testing: This is done by mutating certain statements in your source code and checking if your test code is able to find the errors. Mutation testing is very expensive to run, especially on very large applications.
• Historical Test data: This technique calculates the priority of each test case using historical information from the previous executions of the test case. 

Careful approach to Unit testing helps detecting many bugs at a stage of the software development where they can be corrected economically. It is a tedious process when bugs are detected and corrected at later stages of software development as fixing the bugs is difficult, time consuming and costly. Efficiency and quality are best served by testing software as early in the life cycle. Whenever any changes are made to the software we need to ensure regression testing is performed. Testing strategies like thorough unit testing, good management of the testing process, and appropriate use of tools helps in maximizing the effectiveness of testing effort. Effective unit testing is all part of developing a very high quality software product which can benefit the organization on a whole.

Test Manager/Lead has to take the responsibility of communicating the defects to the respective Dev teams and all other stake holders. The process should be defined in such a way as depending on the severity of the defect the SLA for turnaround times should exist.

The bug tracking & management tools should trigger an e-mail to the assigned team when the defect is assigned. If no tool is used Test leads will be sending e-mail communication to the Dev teams.

While communicating bugs, always remember:

• Do not share the actual Defect sheets through emails. Create share location and share the location details. This will avoid different people working on different versions of sheets.
• Make sure Dev team also have write access to the share point and allow them to add comments and change the status of the defect

Depending on the time lines and the number of defects raised, the schedule for Triage has to be defined. Ideal way is to have this meeting every end of the day. Discuss all the defects and decide the actions.

For an effective bug triage, always remember:

• Set up the conference call/Meeting and invite all the intended recipients.
• Share the list of defects and their details to the Triage participants well in advance of meeting.
• Make sure one representation is available from all groups.
• Prepare an MOM for the Triage and log all the actions
• Discuss on Actions pending from previous meetings.
• Discuss defects and create new actions and identify the responsible person for each action.
• Share the MOM with all the stake holders.

Working with different stake holders in a project, teams would be facing difficulty in keeping transparency on bugs because of following common problems:

• Lack of process for bug logging: Typical scenario like testing & development teams are not well educated on severities & priorities to be used and their importance.
• No clear communication to testing team on required fields as part of bug logging. Testers may skip to mention required data like reproducible steps or may skip to attached screen shots.
• Lack of a standard bug tracking / logging template. If all team members will follow their own template to describe defects, it may lead to discrepancy at a later stage.
• Team will not have a dedicated SPOC communicate defects to all the stake holders
• Team will follow their own communication channel to communicate defects using phone/email. Sometimes they won’t even log defect after communicating issue to Dev and getting fix on the fly.
• Team will not maintain appropriate statuses for defects. Even after they retest and close some times defect still shows as ‘Ready for Test’.
• Improper Defect Triage/Communication Process: Triage process allows all stake holders to gather at one place (Physically or virtually) to discuss on all open defects and decide on action items. Without this call/meeting in regular intervals it will be difficult to have a common understanding on issues/defects or reasons for blocking of test execution.
• Test team some time will not have control on Test environments and they would not know when the fix is deployed in to test environment. Sometimes Dev team adhocly performs certain actions on test environment and fixes the issue. Not having complete control on Test Environment would cause so many issues in ensuring quality of defect retest.
In today’s market conditions, we have so many Freeware tools available for Test/Defect management tools. Some projects also afford to have cost assigned to Defect Management tools and buy required amount of licenses. Even after having a tool in place, if the process is not defined about how to utilize the tool then we will have many challenges to be faced in handling Defects.

The below are the common blind spots identified in the poor or No process scenarios.
• No Training on tool(s) to the team
• No clear guidelines on the process to the team
• No availability of tool till the execution starts
• No planning about how many licenses required for the team
• No Communication process defined
• No Triage process defined
All the above will lead to poor reporting of the Defect status and eventually Test Execution status.

In LoadRunner, you can add C Vuser functions to any Vuser script in order to enhance the script. VuGen generates only a few of the general Vuser functions while you record. If required, the remaining functions can be manually programmed into a script.

As per my knowledge, below is a list of general API functions for ANSI C scripts. It includes all protocols except for Java, VB, and GUI:

Transaction Functions:

1. lr_end_sub_transaction --> Marks the end of a sub-transaction for performance analysis.

2. lr_end_transaction --> Marks the end of a transaction.

3. lr_end_transaction_instance --> Marks the end of a transaction instance for performance analysis.

4. lr_fail_trans_with_error --> Sets the status of open transactions to LR_FAIL and sends an error message.

5. lr_get_trans_instance_duration --> Gets the duration of a transaction instance specified by its handle.

6. lr_get_trans_instance_wasted_time --> Gets the wasted time of a transaction instance by its handle.

7. lr_get_transaction_duration --> Gets the duration of a transaction by its name.

8. lr_get_transaction_think_time --> Gets the think time of a transaction by its name.

9. lr_get_transaction_wasted_time --> Gets the wasted time of a transaction by its name.

10. lr_resume_transaction --> Resumes collecting transaction data for performance analysis.

11. lr_resume_transaction_instance --> Resumes collecting transaction instance data for performance analysis.

12. lr_set_transaction_instance_status --> Sets the status of a transaction instance.

13. lr_set_transaction_status --> Sets the status of open transactions.

14. lr_set_transaction_status_by_name --> Sets the status of a transaction.

15. lr_start_sub_transaction --> Marks the beginning of a subtransaction.

16. lr_start_transaction --> Marks the beginning of a transaction.

17. lr_start_transaction_instance --> Starts a nested transaction specified by its parent’s handle.

18. lr_stop_transaction --> Stops the collection of transaction data.

19. lr_stop_transaction_instance --> Stops collecting data for a transaction specified by its handle.

20. lr_wasted_time --> Removes wasted time from all open transactions.

Command Line Parsing Functions:

1. lr_get_attrib_double --> Retrieves a double type variable used on the script command line.

2. lr_get_attrib_long --> Retrieves a long type variable used on the script command line.

3. lr_get_attrib_string --> Retrieves a string used on the script command line.

Informational Functions:

1. lr_user_data_point --> Records a user-defined data sample.

2. lr_whoami --> Returns information about a Vuser to the Vuser script. Not applicable for Application Management.

3. lr_get_host_name --> Returns the name of the host executing the Vuser script.

4. lr_get_master_host_name --> Returns the name of the machine running the LoadRunner Controller or Tuning Console. Not applicable for Application Management.

String Functions:

1. lr_eval_string --> Replaces a parameter with its current value.

2. lr_save_string --> Saves a null-terminated string to a parameter.

3. lr_save_var --> Saves a variable length string to a parameter.

4. lr_save_datetime --> Saves the current date and time to a parameter.

5. lr _advance_param --> Advances to the next available parameter.

6. lr _decrypt --> Decrypts an encoded string.

7. lr_eval_string_ext --> Retrieves a pointer to a buffer containing parameter data.

8. lr_eval_string_ext_free --> Frees the pointer allocated by lr_eval_string_ext.

9. lr_save_searched_string --> Searches for an occurrence of string in a buffer and saves a portion of the buffer, relative to the string occurrence, to a parameter.

Message Functions:

1. lr_debug_message --> Sends a debug message to the Output window or the Business Process Monitor log files.

2. lr_error_message --> Sends an error message to the Output window or the Business Process Monitor log files.

3. lr_get_debug_message --> Retrieves the current message class.

4. lr_log_message --> Sends a message to a log file.

5. lr_output_message --> Sends a message to the Output window or the Business Process Monitor log files.

6. lr_set_debug_message --> Sets a debug message class.

7. lr_vuser_status_message --> Generates and prints formatted output to the Controller or Console Vuser status area. Not applicable for Application Management.

8. lr_message --> Sends a message to the Vuser log and Output window or the Business Process Monitor log files.

Run-Time Functions

1. lr_load_dll --> Loads an external DLL.

2. lr_peek_events --> Indicates where a Vuser script can be paused.

3. lr_think_time --> Pauses script execution to emulate think time—the time a real user pauses to think between actions.

4. lr_continue_on_error --> Specifies an error handling method.

5. lr_rendezvous --> Sets a rendezvous point in a Vuser script. Not applicable for Application Management.

Also See: Other LoadRunner Tutorials

Testing the software system or software application as a whole is referred to as System Testing of the software. System testing of the application is done on complete application software to evaluate software's overall compliance with the business / functional / end-user requirements. The system testing comes under black box software testing. So, the knowledge of internal design or structure or code is not required for this type of software testing.