How to determine the Operating System support for your product - Part 8

In this series of posts, I have been talking about the Operating System support provided in your applications. In the previous post (Operating System support for your software application - Part 7), I talked about support for 32 bit vs. 64 bit and also talked about how support provided by components can be a huge factor in the operating systems that you support. I took the example of a video application which depends on a large number of external components for codecs, encoders and decoders, for writing to DVD and Blu-Ray and for other parts of the application. If some of these components drop support for an operating system and that component is a critical part of the application, then it is time to take the decision to drop an Operating System. I know of a number of software applications that finally dropped support for Windows XP because 1) Microsoft is on its way to dropping support for Windows XP, with this support ending in 2014. 2) A number of external components dropped support for Windows XP and these were critical enough that the management team of the application finally bit the bullet and dropped support for Windows XP as well.
What happens when you cannot afford to drop support for an application such as where components have dropped support, but the customer profile is such that there is still revenue to be had from customers on this operating system ? Well, that is not a very nice place to be, but you still need to take a stand. If the revenue is important, then you will need to support that specific operating system. So what do you do ? There are a number of steps that you can take to ensure that your product remains on that operating system.
1. Well, you will need to make another effort to ensure that the external component retains support for that specific operating system. If the company or group providing the external component is not willing to provide full support, ask whether they are willing to maintain it to the level that was previously supported. If this is another group in the company, then the revenue potential provides some leverage to ensure that escalation can happen and support is maintained, even if it is at a lower level (only critical bug fixes are provided rather than all bug fixes).
2. The most risky approach. You take a chance and go with a component that is not supported by the provider on that specific operating system. The problem in this case would be that if there is some critical problem that has emerged, things can go out of control very easily, and lead to a situation where there are no good options.
3. Look for alternatives. There are very few functionality items that would not have multiple providers, even if the alternative is a less than perfect functionality. If using another component provides a solution, then you should evaluate the other component and use it if it meets your purpose (even if less than perfect).
4. Prepare for a reduced functionality. I have seen many products using such an approach. When there are no alternatives, and it is decided that support for the specific operating system needs to be continued, then it may be something as easy as dropping the component which has dropped support for the operating system, and having the product without the functionality provided by that component. This needs to communicated to customers as well so that they know that there will be reduced functionality on that specific operating system.

How to determine the Operating System support for your product - Part 7

In the previous post in this series (Operating System support for your software application - Part 6), I focused on the different roles and responsibility of stakeholders in the team, primarily the Product Management, the QE, and the developers. The Product Manager has to take the decision taking into account the various pros and cons of such a move, and also while evaluating revenue impact; the QE and development team would do their contribution to this discussion keeping in mind the impact on their effort, and any technical factors that could also influence the decision. In this post, I will talk more about the dependency and also briefly touch on the 32 bit or 64 bit discussion.
For some years now, there has been an ongoing discussion about the need to move applications onto a 64 bit architecture and stop support for 64 bit architecture. Most people will not understand this discussion, and the reason why it is a top item of discussion for many teams. In near layman's terms, when you state that your application is now 64 bit, it would mean that it can take inherent advantage of the benefits posed by the new wave of 64 bit operating systems, being able to allocate more memory, and numerous other technical advantages. Also, most Operating Systems that are now available are 64 bit. So why not go ahead and convert your application to 64 bit ? Well, converting your codebase to offer native 64 bit support is a project by itself, requiring a large amount of development and testing time. For teams that have limited resources, making such choices is not easy (and most teams cannot claim to have unlimited resources). In addition, you also need to realize that you would no longer be properly supporting consumers who still have 32 bit operating systems (and where the hardware has been supporting 64 bit for a long time now), so this is a decision that needs to be taken.
The other aspect of this post is in terms of the various components that your application would use. In today's world of software development, it is hard to think of a large software that the development team has totally written. Consider that your product is a large video manipulation application. Even though a lot of the workflows will be written by your team, the functionality of a number of sub-areas are better handled by using external components (which could be built by other teams within the company, or by other companies which specialize in such areas). For example, if you are looking at an application that allows users to organize, edit and manipulate videos, you would need support for the different video formats, you would need access to different encoders and decoders, you would need components for creating DVD's or Blue Ray discs as part of the end process. In all such cases, it is far more efficient and effective to use specialized software rather than trying to replicate all of them.
And this is where you dependency starts to dictate matters for you in terms of the operating system support. The external components that you use are created by companies that in turn have to take the same decision for operating system support as you do, and they would also have a large number of customers, based on whom they need to take decisions. It is entirely possible that you would end up in a scenario where some key component that you are using is dropping support for an operating system, and given its criticality in your own application, you are forced to also stop support for the same operating system.

How to determine the Operating System support for your product - Part 6

This blog has seen a series of posts on deciding the Operating System supported by your application. The previous post (Operating Systems supported by your application - Part 5) talked about the kind of constrains that there are for an operating system that is not supported - whether these prevent the user from installing the application on that operating system, or just give a warning and let the user install on the specific operating system. This post will talk in more detail about the process for the various stakeholders in the team that come to a decision about the operating systems to support.
The most important stakeholder is the Product Manager. It is the product manager who is responsible for the final state of the product, the system requirements for the product (which includes the operating systems to be supported in the application). The Product Manager is also the one who is responsible for the revenue requirements for the product, and supporting or dropping an operating system can make a difference to the revenue generated by a product by a few percentage (and these few percentage can make a huge difference in terms of whether targets are met or missed). Hence, it is for the Product Manager to take a final call on whether the product should drop a specific Operating System or not. However, it is perfectly fine for team members to be able to provide a lot of updates and constraints to the product manager.
Another important stakeholder is the QE team (the testers). During the testing phase, the team needs to draw up a plan of which are all the operating systems that need to be supported, need to decide the amount of effort to be spent in each operating system, and then actually put in the effort. Suppose a team supports Windows XP, Windows Vista, Windows 7 and Windows 8. In such a case, the team would use data about the approximate number of users on each operating system in order to prioritize the testing effort on each operating system (no testing team has enough resourcing to do all the tests and spend the effort that they would like to do). But you would still expect that if there are 4 operating systems, then the team would spend around atleast 15% on each operating system testing. In some cases, the testing for an operating system might take more time because there are more defects to be found on such an operating system (for example, we found a lot more problems on Vista, many of them related to the security issues because of the user security accesses control introduced in Vista).
So, the testing team would want that if there is a possibility of reducing an operating system because of a lesser number of users on such a system, then they would hold a number of discussions with the Product Manager on this topic, to ensure that their voice is heard and if they have any data, that is also passed onto the Product Manager (such data could be the increasing number of bugs that they are finding on older operating systems).
The development team are also important stakeholders. They are responsible for ensuring that the code is there for functionality to work the same on all the supported operating systems, something that can be problematic sometimes because the operating systems behave differently. In addition, there may be components in use that are not supported as well on older operating systems.
All these are stakeholders and opinions that need to be factored in before taking a decision on whether to drop a specific operating system. The decision needs to be taken after factoring in a lot of points.

In the next post, I will add more points on this particular topic (Operating Systems support for your application - Part 7)

How to determine the Operating System support for your product - Part 5

This particular series of posts talks about how to determine the support for previous Operating Systems provided in your application (Operating System Support in your application - Part 4). In the previous post, I talked about one major factor - when the maker of the Operating System (whether that be Microsoft or Apple) decides to drop support for the Operating System and will not provide any more bug fixes or other support. This gives a problem where even if you decide to support such an application, you will not get any bug fixes from the makers of the Operating System, which can be a huge potential problem given the interactions of the application with the Operating System.

In this post, I will talk about the process of cutting off support for an Operating System. There are 2 different methods which I have seen about how to cut off support for an Operating System. One of the ways is to provide a hard constraint, which means that the user will not be able to install on that specific Operating System, and the other is a soft constraint which means that the user is given a warning when trying to install on that version of the Operating System.

Consider the variation about using a hard constraint that prevents the user from installing on such an Operating System. What this means is that when the user tries to load the application on that specific version of the Operating System, the application determines the specific Operating System loaded on the computer, and then checks with the supported list of Operating Systems. If the Operating System is not to be supported, then the application installer will give an error to the user and prevent any installation on the user machine. 

Putting a hard constraint is needed when the makers of the software have made a determination that the user should be prevented on that Operating System. This can be when there is a high deal of uncertainty about whether the application will work well on that Operating System without any defects, or when the makers have decided that the version of the Operating System is not in wide user anymore. The hard constraints are also used when the Operating System installed on the user machines is controlled, such as in the case of higher end or specialized software.

The soft constraint means that the user will get a message during the installation process about the version of the Operating System not being supported, and will get an option about whether to proceed or not. If the user decides to go ahead, then the application will get installed. This is normally done when there is an expectation of very few problems on that specific Operating System, and the company does not really want to force the users of that specific Operating System to try alternative solutions. There will be need to be some testing of that specific Operating System, but not at the same level as that of the supported Operating Systems.

Read more in the next post (Determine Operating System support for your application - Part 6)

How to determine the Operating System support for your product - Part 4

In the previous post of this series (Determining Operating System Support for your application - Part 3), I wrote about the process of determining the number of people in your customer base who are using the Operating System in question. There are ways to do surveys and look at industry data, but there is some amount of variability involved even when analysing the data and some amount of assumptions need to be made. Of course, trying to make such decisions without trying your best case on how to get the data required for such analysis is something that organizations should avoid at all costs. Such decisions could cost money that the organization could ill afford, and hence such decision making should be done with a lot of deliberation.
In this post, let us consider another factor that is of great importance in deciding when to drop support for an Operating System from your application. This is related to the drop in support for a particular Operating System by the makers of the operating system. So, if you could consider the case of an operating system such as Windows NT or Win 2000, the support for all of these have been dropped by Microsoft, and if you were to try to get resolution for a problem on these operating systems with Microsoft, they would decline to provide you any support and ask you to upgrade to the newest operating system.
Now you are developing an application that will run on the operating system. Any application, especially those that accesses files on the local machines or that accesses devices on the local machines such as printers (and most applications give a print interface) have a dependency on the files of the Operating System. From time to time, there are problems that crop up where you need to work with the makers of the Operating System (typically Microsoft or Apple) and even expect them to make some fixes for you. When the makers of the Operating System withdraw support, they stop supporting such problems and no longer want to provide fixes for such problems.
So what do you do ? You could still provide support for the Operating System even when the maker of the Operating System is no longer providing any support, but there is an inherent risk in this decision. During the development process, you could run into a problem that could cripple your system and yet you don't have a solution, or a solution on your end is expensive and time consuming  In such cases, it will cause you significant problems; on the other hand, small problems that really are not problems could be all that are caused. And you have to consider that the maker of the operating system would also have thought a lot about dropping support, and there would have been some factors that went into such a decision.
Apple makes it even easier. As and when Apple releases new operating systems, new machines that are released are packaged with these new systems, and they even stop supporting older operating systems on these machines. Deciding on dropping older versions of the Mac is easier than that of Windows, also because the customer base using the Mac Operating System would be less than that of Windows.

Read the next post in this series (Operating System support for your application - Part 5)

How to determine the Operating System support for your product - Part 3

In the past post in this series related to how to determine the Operating Systems support for your application (Operating System Support - Part 2), I talked about trying to determine what your current users support. If your current users are using an Operating System in fairly significant numbers, then it would be hard for you to drop support for such an Operating System; you would risk turning off these users, preventing them from buying the newer version of your software, and drop a significant potential customer base. But, this decision remains a complicated one.
In the previous post, I talked about getting this data from current users. But it is not only current users from whom data needs to be taken. To ensure that you are not dropping potential users from your customer base, you need to do surveys to determine whether your potential users are having an Operating System that you are planning to drop. Consider the case of Windows XP at this point of time. It is an old Operating System and you would might think that most users have moved on from Windows XP. But suppose you decided to drop support of this Operating System from your newer version and then suddenly see a drop in sales, it would seem obvious that you did not do the required survey of your potential users before making such a significant decision.
So what needs to be done ? Well, this is a survey of your potential customers, and is not as easy as just getting data from existing users. However, at the same time, there are many ways to get data related to Operating System usage. At any time, if you just do a search for Operating System usage, you will find that there are a number of articles where surveys have been done to determine the prevalence of Operating Systems among people worldwide, in specific age groups, across geographies and so on. So, if you have a product whose potential customer base is primarily among people above the age of 40 in the United States, there will be some industry data related to such a customer base. Of course, the data will not be exactly in the way that you need, so you need to account for the assumptions, look at the variables and then do an analysis to determine the data appropriate for you and use that as an input for your decision making.
However, it is not just looking at industry data. Another input for decision making is to call for a survey that looks at a sample of your user base and then provides that data to you along with a factor that determines the error assumptions in the survey. The advantage of this method is that you can determine the exact assumptions to be made in the survey, the queries to ask, and then get the results. However, to get accurate results and to ensure that you are not making inaccuracies, the survey needs to be thought through properly, and this can be expensive. But the science of surveys is pretty much standard, and you can be fairly confident about the results.
Now you have got the data required for your decision making, and you need to add variables regarding whether people who have older operating systems will actually buy your software, since people who are comfortable with their current software and operating systems are likely to have a lower percentage chance of buying newer software, even if it is very useful.

More information in the next post in this series (Deciding Operating System Support for your software - Part 4)

How to determine the Operating System support for your product - Part 2

In the part 1 of their series (Determine the Operating System Support for an application - Part 1), I started with the discussion about the various Operating Systems that product teams could support, and some of the complications that come about in the decision making for deciding the Operating System support. In this post, I will talk about some of the other issues that help decide what the operating system support should be.
One simple factor that determines what older versions of Operating Systems you should support include determining the customer impact if you drop a version. In today's day and age, you would be hard-pressed to find a user who has Windows 95 or Windows NT on their machines or an equivalent older version of the Mac OS. Even if you did find somebody like that, the number of people who are actually on such Operating Systems would be very small, and you should be able to afford such users. The tricky park comes with Operating Systems that are closer to the current version, such as Windows XP. Now Windows XP has had 3 newer versions of the Windows Operating Systems that have been available after that, namely Windows Vista, Windows 7, and Windows 8. But, a number of people (especially older people) do not make their software upgrade decisions based on whether a newer version is available. If a newer version is available, and if their existing version provides the functionality that they are comfortable with, you will find a significant % of people will not upgrade their Operating Systems or their machines. I personally know numerous people who heard bad stuff about Windows Vista, decided that their Windows XP installation was fine, and refused to upgrade. If your expected customer base has people who are like this, then it would be foolhardy to do an upgrade unless you are sure about your figures. And this is where things get tricky. You have to do data reporting and data analysis to get enough information to take a decision.
Now even inferring from the data analysis may not be fairly straight-forward. How do you decide the data collection technique ? You would want to know from 2 sources - one would be the current users of the application, and the other would be potential users. None of these are easy methods.
Suppose you want to get this data from current users ? The ideal way would have been to have a mechanism within the application that connects on a regular basis to your computers and provides some information about the computer of the user, including the Operating System and Service Pack version of the software application. If you were getting this information from all your users, then it is very easy to consolidate this information and quickly determine how many of your users are on the Operating System on which there is a query about whether you should continue to support it. Suppose you have set a benchmark of 10% being the limit above which you will continue to support an Operating System, then this data will easily help you make a decision. At the same time, keep in mind that building such a system in the application is not easy. In this day and age of security and privacy considerations, you would need to ensure that such a mechanism passes legal and privacy guidelines. Further, keep in mind that some of your users may not be connected to the internet on a regular basis and hence the data you get is only from those people who are connected to the internet. As always, when you get data, you need to make sure that this data is an accurate as you can verify. The method used for data collection, the logic used for the data interpretation both need to be accurate and verified, else you will commit the grave mistake of taking a decision based on either wrong data or wrong analysis of data, both of which can cause grave problems.

This is it for this post, will continue in this series in the next (Determine Operating System Support - Part 3).

How to determine the Operating System support for your product - Part 1

You are working on your product, and one of the big factors determining the amount of effort needed for testing, and to some extent development, is the platform support that you offer. For both Windows and Mac, there are a large number of Operating Systems that have been released over the years, and if your product has been getting released into the market over a number of years, you would have had to support many of these Operating Systems. Consider the case of Microsoft Windows; it has had a number of operating systems released as time went by - Win 3.1, Win95, Win98, Win NT, Win 2000, Win XP, Vista, Windows 7 and now Windows 8 (I have been working on products that have been in the market supporting Operating Systems from Win 3.1). A number of people would ask as to what is the problem in supporting previous versions of Operating Systems. If you consider a software that is also released on the Mac, there are also different version of Mac OS that have been released over the years.
Now, there is a huge cost of maintaining software on these multiple Operating Systems (and when I say maintaining, I actually mean supporting these OS's on newer versions of the software). When you say that you are supporting an Operating System, this is not possible unless you have done a round of testing on that particular Operating System. So, the more Operating Systems that you have to support, the additional amount of testing that you have to do. Also consider that every Operating System would have had patches that need to be supported. So Windows XP is actually Windows XP, Windows XP Service Pack 2, Windows XP Service Pack 3. And we have seen many cases that the test results could be different because of the difference in the version number of common DLL's such as the Windows Runtime DLL's that are present in these Service Packs.
Many of these Operating Systems are very old, and not supported by Microsoft (or in the case of the Mac, not supported by Apple) anymore. In fact, Microsoft has already removed OS's earlier than Windows XP from their list of supported Operating Systems, and XP is also quickly on the way out. However, depending on your customer profile, decisions such as dropping support of various Operating Systems are not so easy. For products that are meant for layman consumers, not those who upgrade their machines periodically, you would find that a number of people are fine with using Windows XP and see no reason to upgrade to a newer Operating System. So, if your user base is comprised of such types of users, then dropping support for XP would mean that you no longer want business from such users. Further for people who on XP and have a previous version of your software, it means that you are no longer offering a path to buy a newer version, and they may end up using a software that is from a rival and you would have lost a customer.
So what are some of the other variables involved in decision making and how do you finally make a decision ?

Read the next post in this series (Selecting the supported Operating Systems - Part 2).

Explain QF-Test?

The QFtestJUI has been succeeded by the QF – test and was made available in the year of 2001. 

About QF-Test

- QF test was developed by the QFS or quality first software.

- It is actually a software tool for cross platform testing and automation of the GUI tests. 

- QF – test is limited to the following:

1. Java
2. Swing
3. SWT
4. Eclipse plug – in
5. RCP applications
6. Java applets
7. Java web start
8. ULC
9. Cross browser test automation

- All of the above are applications for dynamic as well as static web based applications such as HTML, GWT, Qooxdoo, Vaadin, rich faces and so on. 

- QF – test also provides assistance with the load testing and regression testing of the web applications and supports all the UNIX systems and windows platforms.

- The first commercial use was in the field of quality assurance and is extensively used by the software testers. 

- QF–test is one of the most popular among the capture and playback tools and scripting tools. 

- It has been developed so that the testers and QA people find it very easy to use. 

- The product is quite reliable and robust and also has the ability to support system testing. 

- The QF–test is estimated to have around 600 customers all over the world. 

- It is the professional java and web applications testing tool and has a great efficiency in coping with the automated testing. 

- Modular as well as reusable tests are supported well by the QF–test in various combinations. 

- The product offers a high ROI i.e., return of investment because of its user – friendly GUI and affordable price. 

- Cross browser testing is supported by QF–test for Mozilla Firefox and Internet Explorer and both on the Unix and Windows platforms. 

- The dynamic UI components that have very high complexity can also be reliably recognized by the QF–test. 

- The tests developed with QF–test have the ability to tolerate any GUI changes and so they do not require any high maintenance. 

- QF–test has various in–built modularization and sequential control mechanisms that allow the testers to create sophisticated tests. 

- The test documentation and the reports produced by the QF–test are highly configurable. 

- The tool has been comprehensively documented and provides the perfect support. 

- Because of its intuitive user interface, both the testers and the software developers find it very easy to use it.

- The documentation of the tool is so extensive and consists of various things such as:

1. Manual
2. Tutorial
3. Mailing list
4. Archive and so on.

- One can obtain training regarding the QF–test on the OFS web site as webinar. 

- The modularization mechanism of the QF–test enables the testers to create large test suites in an arrangement that is concise. 

- There are some users who require a more advanced control over the application.

- The tool provides access to internal structures of the program for them via scripting languages such as java and jython and not to forget groovy. 

- Another feature called the batch mode allows a tester to run a group of tests unattended and generating reports in a number of formats such as HTML, XML and JUnit. 

- This lets the tool to be integrated in to various frame works such as maven, Jenkins and so on. 

What is IBM Rational Purify?

Rational Purify is another dynamic tool from IBM which is meant for carrying out the analysis of the software systems and applications and to provide help to the software developers in producing a code that is more reliable. 

The IBM rational purify comes with unique capabilities:

1. Memory leak detection: This capability is related to the identification of the memory blocks to which there are no valid pointers.
2. Memory debugging: This capability is related to pin – pointing memory errors which are quite hard to be discovered such as the following:

a)   Points in code where the memory is freed improperly,

b)   Buffer over flow

c)   Access to uninitialized memory and so on.

3. Performance profiling: This capability is involved with highlighting the bottle necks of the program performance and improving the application understanding via some graphical representations of the calls to the functions.
4. Code coverage: This capability involves the identification of the code with the line – level precision that is untested.

- Platforms such as the AIX, solaris, windows, Linux and so on support the IBM rational purify. 

- The code that is developed with the help of the IBM rational purify is not only reliable but also faster. 

- This analysis tool is very well supported by the windows application development environment. 

- It has been observed that the windows applications which have been developed using the rational purify have stood to be quite reliable throughout. - There is no need to provide rational purify with a direct access to the source code.

- This makes it capable to be used with the libraries belonging to the third–parties. 

- Languages such as the .NET, visual C++ etc are supported by the rational purify. 

- The IBM rational purify is known to integrate well with the Microsoft visual studio. 

- Almost all the software systems belonging to the windows family are supported by the IBM rational purify. 

- The corruption in the memory is identified and the debugging time is reduced significantly. 

- The reliability pertaining to the execution of the software is also reduced. 

- Also, the software systems and applications now make a better utilization of the memory. 

- The IBM rational purify comes with the binary instrumentation technology in which the code is instrumented at the level of the object or the byte level. 

- Here, re–linking or the re–compilation of the software system or application is not required for the analyzation of the code. 

- Further, the third–part libraries are also analyzed. 

- With the help of the IDE integration feature, the rational purify can integrate very well with the Microsoft visual studio thus cutting down on the need of switching between different tools having different types of user interfaces. 

- It therefore develops a more productive and cohesive development environment and experience. 

- It helps in the testing as well as the analyzation of the code as it is produced by the programmer. 

- A comprehensive support is provided to most of the programming languages. - The ‘selective instrumentation’ feature of the rational purify enables a user to limit the analyzation of the software to a subset consisting of the modules which together comprise the whole application. 

- This helps greatly in the reduction of the run-time and instrumentation overhead.  

- The reporting to the modules concerned also gets limited. 

- The rational purify can be run from the command line also since it comes with a command line interface. 

- Automated testing frame works are among the rest that are supported by the software system or application. 

- In a way the software developers are empowered in delivering the product with the quality that is expected by the users.

How would you connect to database using vbscript?

VBScript or visual basic scripting edition is the basic scripting language for the HP test automation suite called the quick test professional. This scripting language is quite a lively script whose interpretation is done via script host of the Microsoft windows. This scripting language comes with a whole lot of excellent and powerful functions with good support for data types, error handling and variables. 

There are two engines that can interpret the VBScript namely:

1. Wscript.exe and Cscript.exe: it works in the GUI environment f the windows with the help of the WSH or windows script host. However this engine is basically used for automating the administration tasks as well as to automate the systems.
2. VBScript.dll- this engine can be invoked by asp.dll and basically serves in the web environment.

VBScript is used as the following in quick test professional:

1. Data base record set object
2. Data base command object
3. Data base connection object

Here in this article, it has been discussed about how a connection between data base and quick test professional can be established through the VBScript. 

The below mentioned are the various VBScripts available for connecting and accessing data base in quick test professional:

1. Updating records in a record set
2. Deleting a record from the record set
3. Finding a record in record set
4. Clearing a data base table
5. Connecting to an ADO data base
6. Adding a new record to the data base

How to connect to a database using VBScript?

- To connect to a data base using VBScript, a DSN inventory is required. 

- An ADO connection is another requirement for making an open connection with a specific data source. 

- Once this connection is established, the data base can be easily accessed as well as manipulated. 

- Also, once this connection is established it is not important how many times that data base is accessed. 

- Another way to establish a connection with the data base using VBScript is by passing a connection string through some record set object or a particular command. 

- Though this method is quite quick but it holds good only for the single specific queries. 

- An essential connection from a web server to a data base is nothing but a data source. 

- This connection can either be established via a dedicated machine running SQL server or through a data base file on a web server at some other location. 

Two types of DSNs or data sources are available namely:

1. File DSN: This is the connection that is created by the script when an access to the data base is required. Here the path and name of the data base to be accessed needs to be specified. Another condition for this DSN to work is that the data base to be connected to must be residing on a server in a directory which must be accessible by the script.
2. System DSN: Creation of this kind of connection is under the charge of the administrator of the web server which consists of the required data base. This is the most popular data base connection since it is much reliable than its former counterpart.

- After the access to the data base is complete it is important that the connection should be closed at the end of each page. 

- For creating any application, the foremost thing that is required is data base itself. 

- A number of programs are available for developing a data base, however, the Microsoft access remains the most popular of them all. 

- It is important for web application designer to know the basics of the data base usage with VBScript as well as active server pages for developing real web applications.

Explain Quick Test Professional (QTP) Testing process?

The quick test professional is a software package that facilitates both the test automation as well as the software testing. To be an expert in quick test professional it is important that you understand both the test automation and software testing using the quick test professional. 

When the software testing process is carried out using the quick test professional it is referred to as the quick test professional test process. By now you must have got it that the emphasis of this article is on the same testing process. 

To say the quick test professional testing process constitutes of the following steps as mentioned below:

1. Configuring of the record and run settings
2. Creating an object repository (this step is optional is many cases)
3. Creating the basic automation scripts
4. Editing or enhancing the script
5. Executing the script
6. Debugging the script
7. Analyzing the results
8. Summarizing the results (this includes tracking the discovered defects and generating the report)

Major stages of the QTP testing process

1. Analyzation of the application

- This is the first test and is aimed at finding your testing needs. 

- This phase involves the type determination of the development environment of your application i.e., whether it is a web application or a windows application. 

- In either of the cases, you will need to load your quick test professional software with appropriate add ins. 

- There are available separated add – ins for both the web type and windows type applications. 

- These add – ins are required since they only give the power to quick test professional to identify as well work with the objects present in the application. - Next thing to determine are the business processes and functionality required. 

- For determining these two things you need to think about what your customer will do with the application. 

- The required business processes are then divided in to smaller groups or units and the actions based on these units are created. 

- This is done so because with smaller modular actions it becomes easy to read, follow and maintain the tests in the long term.

2. Preparation of the testing infrastructure: 

- Based on the needs that you determined in the first phase, the resources required are determined in this second phase. 

- The resources are either obtained or created as required. 

- The resources may include the following:

      a)   Object repositories along with the test objects.

      b)   Function libraries along with the functions that add to functionality of the quick test professional and so on.

- Also in this phase the settings of the quick test professional are configured as per the tasks need to be performed.

3. Building of the tests and addition of the steps to them: 

- By now the testing infrastructure is complete and now you can start developing your tests. 

- Any number of empty tests can be created and actions can be added to them so as to form the testing skeletons. 

- Relevant actions can be associated with the corresponding object repositories.

- Relevant tests can be associated with the function libraries. 

- Steps can be inserted with the help of key words and test preferences are also considered.

4. Enhancement of the test: 

- This phase includes insertion of the checkpoints so that you can easily search for a specific value of object, page or text etc and know whether or not your application is functioning properly.

5. Debugging, execution and analyzation of the test: 

- This phase ensures that the application is working without encountering any interruption. 

- Only if a test is running properly, it can correctly check the behavior of the application.

6. Reporting of the defects: 

- The defects discovered can be reported to the quality center if you have it installed on your machine. 

What are all the different platforms where WinRunner can be used?

Winrunner and winquick are two of the most powerful functional testing tools ever developed. These two software packages actually are a complete functional test suite.

Winrunner is the older testing tool and had been quite popular among the software testers. Winquick is a new addition to the family of such tools. 

It was because of some of the cons of the winrunner that the HP introduced another such functional testing tool that would overcome the limitations of the winrunner and thus winquick came in to the scenario. 

This limitation was that the winrunner was not compatible with every platform that we have today. 

In this article we shall discuss more about this and what all are the platforms that are supported by the winrunner. Intially people invest too much of time, money and infrastructure in their winrunner code and eventually what happens is that towards the end they find that they have to migrate to some much better tool because the platform on which they are building their software system or application is un supported by the winrunner.

The following are the platforms on which the winrunner did not function well:

1. .NET
2. XML
3. Multimedia
4. Mozilla fire fox

Rest on all the platforms the winrunner seems to be working well.

Its successive counterpart the QTP seems to have a cutting edge over all these limitations of the winrunner. It comes with many advance features like:

1. Active screen technology
2. Smart identification
3. Uniform parameterization and so on.
   
   

For the organizations which are building applications upon the above mentioned platforms find Quick test pro (QTP) quite helpful then winrunner. 

- For the organizations that already made a huge substantial investment in the winrunner platform, the introduction of the QTP came as a dilemma. 

- It is a tough thing for them to maintain and manage the code and resources in both the platforms. 

- This shows that even with the years of investment in developing a much better winrunner do not hold good in QTP.

- One of the ways that are being sought for overcoming this problem is the migration of the existing winrunner suite in to QTP and at the same time consolidating the base code. 

- But this way also has got a problem which is that the manual migration proves to be quite cumbersome. 

- This problem arises because of the technical and architectural difference between the QTP and winrunner. 

- Moreover, the time consumption in manual migration is more and generates quite a large number of errors.

- Such errors can make the whole migration quite cumbersome and this will cause disruption in the regular business. 

- There is a solution for this problem also and is known as winQuick. 

- Winquick provides an automated migration solution. 

- For platforms like linux and unix a separate version of winrunner was created called the Xrunner.

- But now we guess the use of this Xrunner is not known.

The below mentioned platforms are supported by the version 7.0 of the winrunner:

1. Windows 95
2. Windows 98
3. Windows NT
4. Windows 2000

The automated testing of the graphical user interfaces is looking up to a new scenario where a majority of the software systems and applications are being based up on web and the complex and sophisticated graphical user interfaces have become their point of operation. 

The winrunner has proved to be a pioneering tool that has been widely accepted by many for GUI testing. Contrary to the winrunner, the QTP follows the modern conventions of the object oriented programming. However the winrunner system has been declared retired since 2011.

Sliding Window Protocols

These protocols comes under the data link layer.data link layer. It provides services to the network layer. It’s a bidirectional protocol. It means sender deletes the frames when it gets the acknowledgment.

The essence of all sliding window protocols is that at any instant of time, the
sender maintains a set of sequence numbers corresponding to frames it is permitted
to send. These frames are said to fall within the sending window. Similarly,
the receiver also maintains a receiving window corresponding to the set of frames
it is permitted to accept. The sender’s window and the receiver’s window need
not have the same lower and upper limits or even have the same size.



The sequence numbers within the sender’s window represent frames that have
been sent or can be sent but are as yet not acknowledged. When new packet from network layer comes in to send, it is given highest no and the upper edge of window is advanced by 1. When the acknowledgment comes in, lower edge of the window is advanced by 1.

Since frames currently within the sender’s window may ultimately be lost or
damaged in transit, the sender must keep all these frames in its memory for possible
retransmission. The receiving data link layer’s window corresponds to the frames it may accept. When a frame whose sequence number is equal to the lower edge of the window is received, it is passed to the network layer, an acknowledgment is generated, and the window is rotated by one.

Types of sliding window protocols

- One-Bit sliding window protocols.
- Go Back N sliding window protocols.
- Selective Repeat sliding window.