Sponsored Ad

Tuesday, December 22, 2009

QTP and DotNetfactory – ArrayList

Arraylist contains a list of values, you can add, insert and remove easily. You can add value with no information on the size which makes it a flexible information structure.

To work with this we just need to create an instance of ‘System.Collections.ArrayList’ using CreateInstance method.

Set MyList = DotnetFactory.CreateInstance("System.Collections.ArrayList")

Here are some of the functions which can be used to work with ArrayLists

Add – adds an item in an arraylist

MyList.Add(”ListItem”)

Remove – removes an item from the arraylist

MyList.Remove(”ListItem “)

Insert - inserts an item at a specified position in the array list

MyList.Insert (3, "List Item")

RemoveAt - remove an item from the specified position in the array list

MyList.RemoveAt (3)

Sort - Sort items in the array list

MyList.Sort

Consider a case where you need to sort a list in ascending or descending order.

First create the arraylist and add your list items in the arraylist. We will add five items in the list in random order.

Set MyList = DotnetFactory.CreateInstance("System.Collections.ArrayList")

2.MyList.Add("ListItem5")

3.MyList.Add("ListItem3")

4.MyList.Add("ListItem2")

5.MyList.Add("ListItem1")

6.MyList.Add("ListItem4")

When you add a new item in the arraylist, it adds some empty memory locations, they ought to remove these empty memory locations. To do this they can use ‘TrimToSize’ method, which sets the capacity to the actual number of elements in the arraylist. You can easily understand this with the example below.

QTP test data directly from external sheet

In a quantity of our earlier posts they have seen How to work on QTP datatable, How to import/export datatable, what are the different functions obtainable for datatable & also the basics of QTP Automation Object Model(AOM).

Here they will merge AOM & Excel automation model to import information from an external excel file to QTP without actually importing the file as a ‘datatable’.

The workflow for the method would be:

1. Generate an excel object.

2. Generate a workbook object that takes file path as input.

3. Generate a sheet name object that takes sheet name as input.

4. Perform operations on sheet.

1. …………………………………

2. …………………………………

3. …………………………………

5. Quit excel application.

6. Destroy objects defined above.

We will show the whole process with an example. It will generate a function that accepts the file path and name of the entry sheet and give the output of an array containing all values of column 1 of the entry sheet.

  1. 1: Function ParamValues(InputFilePath,SheetName)
  2.  
  3. 2: Dim input()
  4.  
  5. 3: Set appExcel = CreateObject(“Excel.Application”) ‘Step 1
  6. 4: Set objWorkBook = appExcel.Workbooks.Open (InputFilePath) ‘Step 2
  7. 5: Set objSheet = appExcel.Sheets(SheetName) ‘Step 3
  8.  
  9. 6: For i=2 to 50 ‘Step 4
  10. 7: if objSheet.cells(i,1).value <> “” then
  11. 8: Input(i-2)=Trim(objSheet.cells(i,1).value)
  12. 9: else
  13. 10: Exit For
  14. 11: End If
  15. 14: Next
  16. 15: appExcel.quit ‘Step 5
  17. 16: Set appExcel=Nothing ‘Step 6
  18. 17: Set objSheet=Nothing
  19. 18: Set objWorkBook=Nothing
  20. 19: End Function

InputFilePath & SheetName input arguments are passed to the function call paramValue. The output of the previous function will be an entry () matrix containing all the values in column 1 of the given Excel worksheet.

You can call the function above by: paramValues,

Friday, December 18, 2009

Learn QTP Keyword

QTP (QuickTest Professional) keyword view

In QTP (QuickTest Professional) they first of all record a check, then run a check & then analyze the results, but before jogging the check they can also enhance it with checkpoints & parameters.

First of all let's talk a tiny about keyword view in QTP and then they will talk about recording in QTP and then they will move on to other things. After recording all the operations, QuickTest displays them as steps in the Keyword View, and generates them in a script (in an Expert View).

In the keyword view there are 4 visible columns –

Item- The item on which they require to perform the step and it can be a check object, utility object, function call, or statement. This column shows a hierarchical icon-based tree. The highest level of the tree is actions, and all steps are contained within the relevant branch of the tree.

Operation- The operation (methods or functions) to be performed on the item chosen in the Item column, for example, Click or Select.

Value- The argument values for the selected operation, for example, the mouse button to use when clicking the picture.

Documentation- is a read-only such documentation that the move is not in an easy to understand sentence, for example, click "findFlights" image.

Assignment-The assignment of a value or variable for example, stored in cCols will store the return value of the current stage in a variable called cCols so you can use the value later in the check. This column is not visible by default.

Comment- Any textual information you require to add regarding the step. This column is also not visible by default.

How to Use Checkpoint in QTP

A checkpoint allows you to identify if the Web site or application is functioning properly controlled or not by comparing a current value of a particular property with the expected value for that property.

By default, the control point name of the object is called to verify that the checkpoint is being performed. They can alter the name of the checkpoint if necessary. After adding a checkpoint, QuickTest adds a checkpoint in the current row in the view of keywords and adds a checkpoint Time statement at the hearing of experts.

Types of Checkpoints:

  • Standard checkpoint.
  • Image checkpoints.
  • Bitmap Checkpoint.
  • Bitmap Checkpoint.
  • Accessibility Checkpoint.
  • Text Checkpoint.
  • Page Checkpoint.
  • XML checkpoints.

Standard checkpoints permit checking the object property values in the Website or application under check. Standard checkpoints evaluate (compare) the expected values of object properties captured during recording to the object's current values during a run session. For example they can check that a radio
button is activated after it is selected. Standard checkpoints are supported for all add-in environments.
Standard checkpoints can be used to perform checks on

Images,

Tables,
Other objects within your application or Web site.

Standard checkpoints can be created for all supported testing environments (as long as the appropriate add-in(s) are loaded).
Image checkpoints let you check the properties of an picture in the application or Web page. For example, you can check that a selected image's source file is correct or not. An picture checkpoint can also be created by inserting a standard checkpoint on an picture object. Picture checkpoints are supported for the Web add-in environment.
With Bitmap Checkpoint they can check an area of a Web page or application as a bitmap. While generating a check, they must specify the area to check by selecting an object. An entire object or any area within an object can be checked. Bitmap checkpoints are supported for all add-in environments.
By adding table checkpoints to the check, they can check the content of tables displayed in the application. For example, they can check that a specified value is displayed in a positive cell. Positive environments also support checking the properties of the table object. For example, a check that a table has the expected number of rows & columns. A table checkpoint can also be created by inserting a standard checkpoint on a table object.
Accessibility Checkpoint recognizes areas of your Web-site that may not conform to the World Wide Web Consortium (W3C) Web Content Accessibility Guidelines. For example, check if the images on a Web page include ALT properties, necessary by the W3C Web Content Accessibility Guidelines.
Accessibility checkpoints are supported for the Web add-in environment        
Checkpoint control page features a Web page. For example, you can check the time a web page takes to load or if a Web page contains broken links. A page checkpoint can also be created by inserting a standard checkpoint on the page object. Page checkpoints are supported for the Web add-in environment.
QuickTest can check that a string is displayed in the appropriate place in an application or a Web page with text Checkpoint. The text checkpoints are compatible with the Web add-in environment, and some Web-based add-in environments.
The contents of a database to access your application may be verified by the Checkpoint database. The checkpoint database is compatible with all the add-in settings
By adding XML checkpoints for verification, you can check the contents of individual files or XML data documents that are part of the Web application. Checkpoint XML option is compatible with all the add-in settings.

Work VBScript in QTP

VBScript (short for Visual Basic Scripting Edition) is a scripting language interpreted by Live Microsoft Windows Script Host.

VBScript has lots of powerful functions & provides excellent support for variables, information types, & error handling.

Two engines VBScript-Vbscript.dll can interpret, it is invoked by asp.dll is used in the web environment and Wscript.exe & Cscript.exe in Windows graphical environment using Windows Script Host (WSH, VBScript often used WSH to automate systems management tasks. WSH is the process module that converts a VBScript file in a Windows executable file). Wscript.exe is used to display output and obtain an entry in the Windows graphical format, such as dialog and input boxes. Cscript.exe is used in a command line environment. When VBScript source code is contained in separate files with the extension. Vbs

Tuesday, December 15, 2009

How to work with QTP

Working with Large Object Hierarchies (Siebel Objects)

I received an e-mail from Suni Reddy, who asked me to share with her an easy way of working with Siebel objects – primarily because of their giant object hierarchy. I have thought about it several times, but because our work on Siebel goes on a temporary basis, I was never able to come up with something. Until now. This news story will portray how you can generate a single library with all the parent objects and call those objects on demand.
Normally, if you would like to select an item from a SiebList, you would do something like:


SiebApplication("MyApplication").SiebScreen("MyScreen").SiebView("MyView")_
    .SiebApplet("MyApplet").SiebList("MyList").Select "Open"


The above hierarchy can be greatly simplified – and this editorial will show a few ways how it can be achieved. Also, the way we’re going to structure our hierarchy, changing two object in a single place will account for an overall alter. In other words, in lieu of changing a single object multiple times (because something changed in the application) we’ll alter it only two times.

 

With Statements

This is by far the most common approach used when dealing with large hierarchies, and quite simple too. However, as the parent objects change, we end up creating more and more blocks of such statements. An example of With..End With statement in use:

 

  1.     With SiebApplication("MyApp").SiebScreen("MyScreen1").SiebView("MyView").SiebApplet("MyApplet")
  2.     .SiebList("MyList").Select "Open"
  3.     .SiebButton("MyButton").Click
  4. End With
  5. 'SibScreen changes from MyScreen1 to MyScreen99: re-write.
  6. With SiebApplication("MyApp").SiebScreen("MyScreen99").SiebView("MyView").SiebApplet("MyApplet")
  7.     'your code
  8. End With

Using Functions to Build Sieb Hierarchy

This technique uses several functions to create an entire hierarchy, but the result is good. Moreover, it also simplifies how events are performed on objects. Let's start building our first function of the database object (SiebApplication):

  1. 'Base Object: SiebApplication
  2. Function oSiebApplication
  3.     Set oSiebApplication = SiebApplication("MyApp")
  4. End function
  5. Let’s create instances for our Child objects:
  6. 'oSiebScreen retrieves its parent (oSiebApplication) from the function above
  7. Function oSiebScreen
  8.     Set oSiebScreen = oSiebApplication.SiebScreen("MyScreen")
  9. End Function
  10. 'oSiebView_ retrieves its parent (oSiebScreen) from the function above
  11. Function oSiebView
  12.     Set oSiebView = oSiebScreen.SiebView("MyView")
  13. End Functions
  14. 'oSiebApplet retrieves its parent (oSiebView) from the function above
  15. Function oSiebApplet
  16.     Set oSiebApplet = oSiebView.SiebApplet("MyApplet")
  17. End Function
  18. To demonstrate, if we want to set a value in the “lstApplication1″ SiebList, we can simply do the following:
  19. oSiebApplet.SiebList("lstApplication1").Select "Urgent"

Using Classes

This is my favorite, and very similar to what we have above, but the advantage of using this technique is that we have several multiple parenting classes or one class to the group at all. Suppose we have the following hierarchy, with an even

  1.     
  2.     SiebApplication("MyApp").SiebScreen("MyScreen").SiebView("MyView")_
  3.     .SiebApplet("MyApplet").SiebList("lstApplication1").Highlight
  4. First, let’s create a sample class for the Base object(s) that will be common for all classes.
  5. 'Demo class for the top-most object (Parent Class)
  6. Class clsSiebApplication
  7.     Public Property Get oSiebApplication
  8.         Set oSiebApplication = SiebApplication("MyApp")
  9.     End Property
  10. End Class
  11. Now, let’s build the child classes, that will use the base class to complete object hierarchies:
  12. 'Child Class: Derives its Base Object from clsSiebApplication (Parent Class)
  13. Class clsSiebObjects
  14.     Private oShared
  15.     'We will reuse the Base class to retrieve some common objects
  16.     'An instance of the base class will be initialized as the class loads
  17.     Private Sub Class_Initialize        
  18.         Set oShared = new clsSiebApplication
  19.     End Sub
  20.     'Terminate the instance while exiting.
  21.     Private Sub Class_Terminate        
  22.         Set oShared = Nothing
  23.     End Sub    
  24.     'oSiebScreen Property will retrieve its parent from oSiebApplication
  25.     Public Property Get oSiebScreen
  26.         Set oSiebScreen = oShared.oSiebApplication.SiebScreen("MyScreen")
  27.     End Property
  28.     'oSiebView Property will retrieve its parent from oSiebScreen (above)
  29.     Public Property Get oSiebView
  30.         Set oSiebView = oSiebScreen.SiebView("MyView")
  31.     End Property
  32.     'oSiebApplet Property will retrieve its parent from oSiebView (above)
  33.     Public Property Get oSiebApplet
  34.         Set oSiebView = oSiebView.SiebApplet("MyApplet")
  35.     End Property
  36. End Class

This can be used in a way that makes it very easy for the reader to understand the objects with which the script is working. We will use the same example we used above with the "lstApplication1" SiebList:

  1.     
  2.     Dim oSieb
  3. 'Create an instance of clsSiebObjects
  4. Set oSieb = New clsSiebObjects
  5. 'Performing an event on the SiebList Object
  6. oSieb.SiebApplet.SiebList("lstApplication1").Highlight

Using an Object Dictionary

This technique is based on Article Meir, Implementation of a layer of graphical user interface classes. I would recommend you read the article to better understand this approach. I used a high-level approach to this concept, and to better utilize this process, the article should be read carefully. This technique can be used as follows to simplify a large object hierarchy:

  1. Class clsSiebObjects
  2.     Private m_htContext
  3.     'Loads the Object Dictionary
  4.     Public Function Load
  5.         LoadContext
  6.         Set Load = m_htContext
  7.     End Function
  8.     'Represents the Object Context
  9.     Private Function LoadContext
  10.         m_Context = CreateObject("Scripting.Dictionary")
  11.         'Loading objects in the dictionary.
  12.         With m_Context
  13.             'SiebApplication
  14.             .Add "SiebApplication", SiebApplication("MyApp")
  15.             'SiebScreen (Parent: SiebApplication)
  16.             .Add "SiebScreen", .Item("SiebApplication").SiebScreen("MyScreen")
  17.             'SiebView (Parent: SiebScreen)
  18.             .Add "SiebView", .Item("SiebScreen").SiebView("MySiebView")
  19.             'SiebApplet (Parent: SiebView)
  20.             .Add "SiebApplet", .Item("SiebView").SiebApplet("MySiebApplet")
  21.         End With
  22.     End Function
  23.     'Property Get/Let m_Context
  24.     Private Property Let m_Context(ByVal Val)
  25.         Set m_htContext = Val
  26.     End Property
  27.     Private Property Get m_Context()
  28.         Set m_Context = m_htContext
  29.     End Property
  30. End Class
  31. The snippet below shows usage of the above class to simplify Siebel Hierarchy:
  32. Dim oSieb
  33. 'Instance of the Class
  34. Set oSieb = New clsSiebObjects
  35. Set oSieb = oSieb.Load
  36. oSieb.Item("SiebApplet").SiebPickList("lstApplication1").Select "Open"

Summary

In the examples above, you may notice why only the top 4 objects (Application, Screen, View, Applet) of the hierarchy have been included. This is because, including all the objects will water your libraries and make spotting the right object a cumbersome task. Thus, by including only the top 4 hierarchies, they can simplify our work on a great scale. If the hierarchy changes, they would basically need to alter the elements at one place, only.
For developers who wish to use descriptive programming with Siebel applications, please note that you will have to write descriptions of the objects of the parents only once. When these changes in the descriptions, the update in one place will be the only maintenance required. I am using descriptive programming 100%, with our Siebel application and techniques in this article have really simplified my job much care only for the parent objects.
I hope Automation Developers using Siebel with QTP find this news story useful. Thanks for visiting Relevant Codes.

What is QTP

Mercury Quick Test Professional offers the best solution in the industry for performance testing and regression testing automation - addressing every major program applications and environment. This next-generation automated solution deploys the concept of evidence-driven testing to radically simplify keyword creation and maintenance check. Distinctive to Quick Test Professional's Keyword-driven approach of verification automation experts have full access to the basic verification and properties of the object, a script integrated debugging environment that is round-trip synchronized with the Keyword View.QuickTest professional meets the needs of technical and nontechnical users. Allows you to deploy higher quality applications faster, cheaper and less risky. It works hand-in-hand with Mercury Business Method Testing™ to bring non-technical subject matter experts in to the quality method in a meaningful way. And, it empowers the entire testing team to generate sophisticated check suites with minimal training.The deployment of Mercury Quick Test Professional is optimized through the use of Mercury best practices. Mercury best practices cover all aspects of deployment, including product installation and operation, organizational design, method implementation, continual method improvement and measurement of return on investment (ROI). Throughout your implementation Mercury applies these best practices to your specific situation, generating world-class procedures for you that drive long-term success source.

Learning basics of QTP automation tool and preparation of QTP:-

This post is in continuation with QTP interview questions series.

What are the features and benefits of Quick Test Pro(QTP)

•    Key word driven testing
•    Suitable for both client server and web based application
•    VB script as the script language
•    Better error handling mechanism
•    Excellent data driven testing features

How to handle the exceptions using recovery scenario manager in QTP

You can instruct QTP to recover unexpected events or errors that occurred in your testing environment during the period of verification. Recovery Scenario Manager provides a wizard that guides you through the recovery scenario definition. Recovery scenario consists of six steps

•    Triggered Events
•    Recovery steps
•    Post Recovery Test-Run

What is the use of Text output value in QTP

The output enable values for the values that talks to the application at runtime. When parameters, the change of values for each iteration. Thus, by generating output values, you can capture the values that the application has for each race and the output to the information desk.

What is the file extension of the code file and object repository file in QTP

File extension of
Per test object rep: filename.mtr
Shared Object rep: filename.tsr
Code file extension id: script.mts

What are the properties you would use for identifying a browser and page when using descriptive programming

“name” would be another property apart from “title” that we can use. OR
We can also use the property “micClass”.
ex: Browser(”micClass:=browser”).page(”micClass:=page”)

What are the different scripting languages you could use when working with QTP

You can write scripts using following languages:
Visual Basic (VB), XML, JavaScript, Java, HTML

Explain the keyword create object with an example.

creates and returns a reference to an Automation object
syntax: CreateObject (servername.typename, [place])
Arguments
ServerName: Required. The name of the application providing the object.
class: Required. The type or class of object to create.
Location: Optional. The name of the network server where the object being created.

Friday, December 4, 2009

Software Testing - User Stories

1st of the usual query that they hear most of the time is how user histories are different from use cases. User histories are much simple than use cases. User histories are very easy to generate, discuss & create. They also do not contain any technical details.

Typically lovely user histories are defined in the following format

User histories are one of the primary development artifacts for the XP project teams. A user history contains information so that development team can reasonably give estimate about completing, tester can talk about how it will validate & customer can see its value.

While discussing User histories, you should make sure that they are not very massive. A massive user history leaves the chances of ambiguity & absence of clarity in the mind of growth team. Ideally, you should be able to break user histories so that it can be done by six people in a week's time.

As a I would love to do so that

During consideration of histories of users, you must ensure that there are very large. A user story leaves great potential for ambiguity and lack of clarity in the minds of the development team. Ideally, you should be able to break user stories so that it can be done by two people in a week.

If you are working as a tester in an Agile project and see any history taking longer to complete, consider this as an opportunity to ask questions and see if this can be broken by the functionality or platform or otherwise.

Once a story breaks at the last level, this story is given some points based on how long it will take a couple of programmer to finish it. These user stories that are broken down into tasks and assigned to appropriate developers. Typically, the start of the project, establishing a set of user stories for each iteration or Sprint chooses stories based on the priority and time it would take to complete.

User histories are written in the paper such as cards or post-its. This also ensures that no unnecessary details on the User histories. Once the development team decides on the stories to be developed in a sprint, which is divided into tasks and resources are allocated accordingly.

Most times, these user stories are defined only in terms of acceptance. For example,

As a user should be able to register on the site in order to receive the newsletter is a good example of the user story. As a tester, should be your job to find out negative scenarios and assumptions in this story. For example, what should I provide information to users to register? Is there a distinction between optional and required information? Should we validate the email address of the user before registering? And many more.

Recall, one of the main reasons for the use of user histories is to have an invitation to conversation. According to Ron Jeffries, each user story in Windows XP has three components - Cards (Physical Environment), Conversation (discussion about them) and confirmation (tests that verify them.) One of the widely used acronym for good use cases is called INVEST. How user histories rights is essential to the success of any project fast and therefore INVEST this acronym is used to justify the investment you make in creating user stories.

According to this acronym

  • I for independent
  • N for negotiable
  • V for  value
  • E for Estimable
  • S for small and
  • T for verifiable

As a tester on agile projects is very important for you to make sure that all histories that is consistent with work on the characteristics defined by these terms. There are good reasons to do so.

Histories should be independent so that it is easier to plan. Consider the situation where the need to decide which stories to include in the sprint and most of the stories are dependent on each other.

Histories should be negotiable, user histories are not contract with the client are a platform for a clear understanding among totally involved. Anyone should be able to challenge its intention and its application.

User histories should be valuable to someone. You will have situation where in their histories do not provide direct value to his client, but should provide value to someone, could be a developer or tester. For example, as a tester should be able to access the application layer beneath the user interface so that automation is not dependent on the user interface. As We should oppose the application functionality with access to the user interface.

Histories should be estimable, remember we're not saying accurate estimate, but must be

Reasonable estimate. Since stories are negotiable, these estimates may change but should in principle be possible to reasonably estimate the amount of time it takes to complete histories.

Most of the characteristics described above to ensure that user stories are clear and small. This is very important; most of the times of great stories are inaccurate. It is also possible to keep the team moving, with little stories, since it gives a sense of accomplishment or finishing something. Normally, you should try to complete at least 2histories by Sprint (two programmers and a tester for two weeks).

From user stories are the requirement that drives the development should ensure that these stories are verifiable. You can find this for some features like ambiguity, clarity etc that may be used in the verification requirements in the traditional development model.

Remember, user stories are the focus of the agile methodology of software development and as a tester must ensure that their equipment investment of user stories.

Smoke and Sanity Testing

There are two types of evidence which by nature are of very short duration and are usually designed so that major problems are found much earlier in the cycle. These two types of test are:

1. Testing for sanity

2. Smoke Testing

It seems that the smoke test of the word comes from the industrial test equipment. The smoke testing procedure is considered a safety test by a curtain of smoke into parts of the sewerage and drainage to detect sources of unwanted leaks and sources of sewer odors.

Proving for sanity is a surface test, but is performed whenever a cursory analysis is sufficient to prove the coating works consorting to specifications. This level of analysis is a subset of regress testing. Normally includes a set of fundamental tests of basic GUI functionality to demonstrate connectivity to the database, application servers, printers, etc.

However, in the field of trial software smoke test is a very important element. I often look for the two words have been used interchangeably. I will focus on the aspect of smoke test in this article.

Smoke Testing is applicable when adding new components and are integrated with existing code. Ensures that the building is not broken. The product in its current state is smoke tested daily. Merely ensures that the building is not broken and is ready to test further. Once an engineer certifies the smoke test is successful, the test team can take action to test deeper.

Typical features of Smoke Testing:

  • It exercises the entire system end to end.
  • It is not exhaustive, but should be capable of exposing major problems.
  • It ensures that the core functionality is the accumulation of work and is stable enough for further testing thoroughly.

Smoke Testing Advantages:

  • Reduction of Risk of Integration: From smoke testing is carried out integration problems are discovered at a much earlier stage than later in the cycle.
  • Find big problems: A good test designed smoke can increase the probability of finding a big problem when software is built early in the cycle. So catch bugs earlier in the cycle.
  • You can save time and money - If a major problem is detected at the stage when the software is ready built, it can save time and enormous costs if the mistake was discovered at the end of the cycle.

Thursday, December 3, 2009

Software Testing - Stress Testing

Stress testing has a different meaning for different industries where it is used. For financial sector and the sector stress testing, a testing process of financial instruments to determine their robustness and accuracy level that can sustain under extreme conditions such as sudden market decline continued or at a certain level, sudden or extreme change on various parameters, for example, interest rates, repurchase agreements and time used in the financial sector, the sudden rise or fall in price of substances that may affect financial forecasts, etc. for manufacturing, testing effort can include different operating parameters and processes for the testing of different systems. For the medical industry, stress testing, a process that can help understand the condition of the patient, etc.

Stress tests in the IT industry

Stress tests in the IT sector (hardware and software sectors) means of testing software / hardware for its effectiveness to provide a consistent and satisfactory performance in extreme environments and stresses such as heavy network traffic, loading procedures, below or above the underlying hardware clock, working on applications for the maximum utilization of the resources of the periphery or in the system, etc.

In other words, stress testing helps find the level of robustness and consistency of performance as satisfactory or even crossed the limits for convention procedure of the system (software / hardware).

The most important use of stress testing is in testing software and hardware that are supposed to work at critical or real situation. As a website is always online and the server hosting the website must be able to handle the traffic in every potential way (even if traffic increases the variety), a mission-critical software or hardware that works on stage in real time, etc stress testing in relation to certain websites or software is considered an effective process to determine the limit, in which the system / / software hardware / website shows strength, is always available to perform its task, effectively manages the load that the normal scenario, and even shows effective error handling in extreme conditions.

Need for exercise testing

Stress testing is considered important for the following reasons:

1. Almost 90% of software / systems are developed with the assumption that they will operate in the normal scenario. And even if one considers that the limit of the normal operating conditions met, not much higher than might actually be.

2. The cost or the effect of a very important (critical) software / system / website failure in extreme conditions in real time can be huge (or can be catastrophic for the organization or entity that owns the software / system).

3. It is always best to be prepared for extreme conditions instead of letting the system / / software crash site, when it crosses the boundary of normal operation.

4. Tests conducted by the system developer / software / website may not be enough to help illuminate the conditions that lead to system crash or software when it is actually presented with the operating environment.

5. It is not always possible to make any problems or errors in a system or software, unless it is subjected to such tests.

To help overcome problems such as denial of service attacks, in the case of Web servers in a Web site, violation of safety due to problems with spam, hackers and viruses, etc., the problems arising from the conditions where / system software or website needs to process applications for resource allocation processes of interest at the time when all the necessary resources are already committed to some other process that needs more resources to complete its work (known as deadlock), memory loss, race condition, etc.

This type of testing is done mainly with the help of stress testing different programs available on the market. These tools are configured to automate a process of increasing tension (ie, the creation and increasing degree of adverse environment) in a system / software / website and capture the values of various parameters that help confirm the robustness, availability and performance of the system / software / web is being tested. Few of the actions involved in the stress test are bombarding a website with a large number of applications, the management of many sources of applications on a computer, making numerous attempts to access ports of a computer to hack it and used for various purposes, such as spam spread of viruses, etc.

Open Source Software Testing Tools and Scripts

Tester Tools is the largest website of Software Testing Tools with a variety of specific tests of open source software testing tools, ranging from scripts to test software security software systems, test harnesses and cloud computing .

We all live in the era of computers, there are plenty of inventions and changes are happening every day that relates directly to the computer. These updates and assistance to inventions in the heart of computer technology to be stable, but there is a kernel that has the ability to control even the core of the computer.

It's just the software

Acts as an effective interface between humans and computers. Since the first program built in the 1940s to the latest version of Google Earth 5, software diligence is the only industry that became a super star in the night. Now, we have software that rescues people from committing suicide to those used for the Mars mission.

However, all these programs have to undergo rigorous testing before being marketed or used. In principle, this test is performed manually with a software tester trying to do different things with the software, the test of reliability and other Aspects of the software for a specified period of time, check whether the software codes are properly and then loop software is released.

It took a long time for this process of testing to do, so the engineers came up with the idea of software that can try different software. And these programs were then known as generally as software testing tools. There are plenty of websites offering different software testing tools for a software engineer to test your software, but no comprehensive website offering the software testing tools of all kinds, but not anymore!

Besides all these features, the website also allows developers to upload their own software testing tools for the web, all you need is go to the page Send an instrument, then complete some simple details of the tool software testing is presented. The administrator will check the tool and add it to the list of other tools.

With all the great features and flexibility of this software testing center, stands out from the rest of other sites, and will become one stop location for all the testers out there.

Software Testing - A Cautionary Tale

There are some basic rules of them, who will serve you well in testing any application that deals with lists of data (and applications that do not?).

1.1, few, many "

2. "They make no hypothesis"

3. "Remember to mix a little"

This case study covers a very interesting example of where following the rules of thumbs * exactly * dividends.

The problem of

There was no interactive reporting solution that was having performance issues: in essence, there was some pathological performance degradation in some circumstances.

It contributes the lion's share of wasted time was in a 3rd party component that really could not be

There were several passes on the problem and things always did:

  • Direct: get the draft issue and simply pause the debugger at the point of obvious pain
  • Scrub indirect: the code in search of opportunities
  • (Time) through validation tests: write an automated script to perform the information component through a series of configurable settings

These scrubs palpable difference in each iteration: for reasons related to the limitations of the component of the 3rd party application and framework which was held on traceability was not large in the code and found to be difficult to get the right job the first time.

There were significant improvements made however: minutes became seconds in some cases, giving an indication of the potential seriousness of the issue of interactive applications.

However, it is that even if the encoding was achieved "first law" was not a hidden track that would have caused a return to the bench due to a serious performance problem.

The pump

In this case, it pays to enter a small detail:

Developers and testers have a certain level of awareness of the importance and complexity of a given process run time: in essence, tend to have an expectation that (approximately) the runtime is going as O (n) and many other applications is a strong pressure of nitrogen to a small number, otherwise the user experience can be very disappointing. Many defects arise around the issue that n is not really a small number. In this case, no figure appeared to be an acceptable if not excellent.

Developers and testers got a big surprise when at the last minute of the product release cycle of a project that was presented wholly challenged the performance as seen by developers and quality control. It took years to carry out what is immediately in much larger chunks of data.

What was happening?

The developer to debug the application: the calling sequence like any other data, only taken a very different time.

What is different in the project?

Well, one of the arrested were limits to open from the default of several hundred to several thousand people - that there was never any evidence of this number of elements in these lists but still a thousand years is a small number of modern machines with the functions that have an acceptable order of n.

Therefore, expectations are challenged: What was happening?

The automated test was repeated with the limits set to the default-busting - the quality was still acceptable and much better than the proposed problem.

It has reduced the data in the project. The automated test data that was created in a controlled manner and could not help.

Back to the developer.

They work hard for the last days of term development of the answer suddenly became clear in the purification and compare the behavior of large projects "good" and "bad" major projects.

The behavior of a key role to participate in the interactive exercise component was not simply characterized as O (n). A better indication would be O (n) + O (x) where x and y are the counts of items in the lists used by the component.

Where X and Y, below the default implementation of the second term was never observed by the behavior and the 3rd party component source was never discussed at the level where the fault could be found. When the defaults of the application exceeds this mass O (x) had the opportunity to be - "very important".

Why not capture the automated tests that when the larger sizes, were established in new settings?

Because the tests made a reasonable assumption - that n matter and therefore was not observed by the evaluator and advocate that the size of the list were all the same – x y is always zero

The proposed issue has real data with lists of great and different - all he did was a list that several articles of 1000 long and the other to be small for the performance problem besetting be exposed.

The moral of the story

One could argue the original bug report contained the core of the solution, providing an example of a rule of thumb # 3.

Golden Rule # 1 was initially intended to be covered adequately, but fatally compromised by the pathological behavior of the application. The application appears to be the game of assessors and internal model of development of certain very specific conditions; they were sadly realistic that a key feature.

Custom software development

During the development of complex projects you are faced with the choice between centralized management and decentralized projects. Centralized management means that the application of all phases of the project (from the simplest to the most difficult) is under control. At that time, there is a "Think Tank", keeping track of everything happening in the project. Decentralized management does not mean total rejection of project manager, who makes major decisions. This type of management implies that the control phase of the projects lies primarily with mini centers to report to the head of the general course of some phase of implementation, without elaborating.

Both approaches are in use, but its effectiveness depends on the structure of the company and developing the project. The centralized approach provides an advantage of full control over the process, and provides an opportunity to react in time if some phase of the project fails. Higher project risks to the terms or expected issue is reduced to the minimum in this case. But it is the reverse: the Think Tank is overloaded with information flow if the project has many steps and is divided into several subtasks. That has to process a large number of reports and consequently, the risks of failure of its primary mission: total control. The overworked heart can focus on the quality of various stages of project implementation, but may lose the main idea of the project in that. It is particularly relevant in the case of projects of large scale, complex developments, where project participants are in different time zones. Mini-sites can be created on the basis of pieces of projects, divided according to their subjects, or participants, close to each other in their geographical location. The central office does not know exactly what is happening in that or another area, but still free to support the main idea of the project and control over the major stages of project implementation. Using the decentralized approach risks doubt the main campus to inquire about the failure of sometime in the last minute.

The world has been experiencing a wide application of the recently decentralized system. It has a direct relationship to globalization and expansion projects. Many companies have employees working in offices located in different countries, or even at home. But one should not completely abandon the centralized approach - that is able to ensure the correct application of small tasks and projects that bring real benefit and ensure the development of your business.

Software testing: Static

A static test is necessary for detection of defects in the design phase and verify precisely the tasks for development of program modules and test plan. Thus, immediate performers of software modules will have a minimal sufficient package, but at the same time documents allowing them to begin working with waste minimal time in the study documents and comprehension tasks. Testers, in turn will have a comprehensive test plan, allowing them to verify the operation of the program product according to a criterion of "how it should work", not "how it was to work", as often happens.

The economic benefits are obvious static tests. Most of the large errors in the products of the program are derived from incomplete lists of demands of the tasks or incorrect. A developer often receive inadequate or excessive package of documents. These difficulties will be solved, using the static test. This means that the possibility of serious errors is dropping in the development phase. According to estimates, the costs of correcting errors in the static testing phase is 5 times less than in dynamic testing phase and 20 times less than in the operation stage of the product program. Our team will offer a series of operations necessary for the static test, ensuring high quality project documents and minimize the possibility of critical errors in the software already done.

The static testing involves contacts with the client or the contractor for the project, i.e. a person, able to express explicitly and the task of correcting the claims, if necessary.

The next job of the requirements for the software product: the client or his representative, the representative of the developer’s team representative team of assessors. At this stage the team of testers to control, to the list of requirements is complete and consistent. In the development stage of the testers of the composition of tasks, together with a leading developer of check, if tasks are full and not excessive.

A test plan for dynamic testing is formed during the static test. In it, including control of all the requirements for software products, and control of checkpoints, defined together with developers, as the choice of endpoints of the test depends on the programming tools significantly.

Conventional software testing in a Scrum team

If you are a professional application tester, or work in quality assurance, I consider you to be
(like me) a "conventional application tester." Increasingly, conventional application testers are finding themselves on teams using the Scrum development method. For testers unfamiliar with iterative lifecycles, this can be a real challenge. Having been on a variety of projects using Scrum as a conventional application tester, I'll share four stories that describe different approaches for testers.

The Scrum methodology can pose a challenge for application testers who are used to more traditional waterfall-inspired development processes. Jonathan Kohl relates his experiences working on Scrum teams who found some clear advantages in changing their methods.

What is Scrum?

According to the website of Scrum, Scrum is an agile process, light that can be used to manage and control software and product development using iterative, incremental practices. "The best place to start learning about Scrum is the page About the Scrum website. It's a good idea to learn as much as possible about Scrum as a tester, in particular the principles and theory behind it. To understand the terminology of this article, I will summarize some aspects of Scrum.

Scrum is a software management process that uses an iterative lifecycle and focuses on communication, including feedback loops. Each iteration, called Sprint, takes about four weeks. A Sprint is a block of time in completing the software development. Ideally, a complete vertical section of the application is submitted at the end of each Sprint. When each "slice" board, you have the full product. A Sprint is a longer cycle of votes in which the software developed in the last iteration is demonstrated to project sponsors and end users.

Short resubmit loops are also produced every day. These everyday Scrum meetings last fifteen minutes, during which team members describe what we are working and raise issues they might find. The Scrum Master (the person who manages the project management) will Scrum meetings.

Work to be undertaken during the life of a project (a project contains several Sprints) is summarized in an accumulation of products. The Product Backlog contains a list of characteristics needed for the project; this is the scenario for the project. Each also has a Sprint backlog tasks to meet a number of features in the Product Backlog. This describes the work of a special sprint. These documents are often written in a high level. The details can be filled in according to the practices of the team. How to perform tasks to achieve the objectives of the project left the team in Scrum, so it's common to see Scrum teams using Extreme Programming or other within Scrum.

For the evaluator, the most important things to note about Scrum are its iterative lifecycle and frequent communication. Both may require some adjustments by the examiner, who can be relied on to do the following:

  • Proof of within each iteration, rather than the end of a development cycle
  • Decide what to test when a product is still unfinished
  • Collaborate with team members rather than working in isolation
  • Participate in daily status meetings are a maximum of 15 minutes duration

Request Information on individual chemical through tests, and work with other team members to determine what to test, rather than testing requirements documents.

Sponsored Ad

Development Updates

Tech Updates