Supporting previous versions of the software (Part 6)

The previous post (Supporting previous versions of the software (Part 5)) talked about a team trying to make a decision about whether to drop support for a previous version of the software or not. If you are a user who is impacted by dropping support for the version of the software you are using, you would think that the team has taken such a decision without thinking about users. However, such decisions are not taken without a detailed discussion, and maybe after thinking about this decision at multiple levels before the final decision on dropping support is taken. However, it can be the exact reverse decision that could happen. With some serious defects having risen, the team has proposed that these cannot be fixed easily and also because these problems are for an older version; however, when a decision is finally taken, the decision is the exact opposite. The support for the previous version is not removed, and infact, the team is told that with these severe defects, there needs to be a fix provided to users.
With this decision, it can provide quite a challenge for the team to provide the dot release / patch for the release, but not impossible and hence they have to plan for it. There are a number of parameters that need to be considered, evaluated and a solution found for all of these. Some of these are (this is not an exhaustive list, if you see more parameters, please let me know through comments):
- Whether to release a dot or patch: What is the difference ? The terminology could vary, but typically consider 2 different kinds of releases ? One is where you have a simple small executable that just updates the few files required for the fix, while the other is a complete release that essentially replaces the application that they have on their machine. The reasons for deciding which method to use is also complex; it depends on the number of files to be updated, as well as the actual mechanics of issues such as upgrades, dependencies, etc. This decision is typically an engineering decision.
- Number of resources to be used for the release: In most cases, teams do not get additional resources for handling such updates unless they are doing this on a regular basis. So, some amount of work estimation needs to be done to determine the number of resources needed, as well as the schedule on which they will be needed.
- Support from external teams: For any product release, there is support needed from additional teams such as testing, installer and release, documentation, etc. Even if there is a small update to be provided, there is a need to ensure that these external teams are in place and committed to the effort, This can be a challenge sometimes.
- The timeframe for this effort needs to be decided: This can be a challenge sometimes. Typically a dot or a patch needs to be released pretty quickly, and there is a need to optimize to ensure that the existing engineering work for the current version is not impacted. This schedule can be a challenge, since the priority will remain the work for the existing release, and yet there needs to be an update.
- Update problems / engineering issues: Whenever an update / patch / dot release for a previous release needs to be released, it needs to be checked with the application installed on the user's machine. This includes ensuring that the application continues to work fine with the update, including the standard checks. This means that the team needs to install previous versions of the application and even replicate the operating system version that some of the customers might be having.
- Informing the users through support teams, forums and so on. There needs to be a campaign to inform users about the impending update release and ensure that feedback needs to be taken quickly when the update is released.

What are two fundamental cryptography principles?

In this article we shall discuss about the two fundamental principles that govern a cryptographic system. 

1. Redundancy

- Some redundancy must be there in all the encrypted messages. 

- By redundancy here, we mean the information that is not required for understanding the message reducing the chances for a passive intruder to make attacks. 

- Passive intruder attacks involve putting the stolen information to misuse without understanding it. 

- This can be more easily understood by an example of a credit card. 

- The credit card number is not alone sent over the internet rather it is accompanied by other side info such as the DOB of the card holder, its validity date and so on. 

- Including such info with the card number cuts down on the changes for making up the number. 

- Adding a good amount of redundancy prevents the active intruders from sending garbage values and then getting it verified as some valid message. 

- The recipient must be capable of determining whether the message is valid or not by  doing some inspection and simple calculation. 

- Without redundancy the attackers would simply send junk message and the recipient will decode it as a valid message. 

- However, there is a little concern also with this. 

- N number of zeroes must not be put at the beginning or the end of the message for redundancy because such messages become easy to be predicted thus facilitating the crypt analysts work.

- Instead of zeroes, a CRC polynomial can be used because it proves to be more work. 

- Using cryptographic hash might be even better.

- Redundancy has also got a role to play in quantum cryptography. 

- Some redundancy is required in the messages for the bob to determine if the message has been tampered. 

- Repetition of the message twice is a crude form of redundancy.

- If the two copies are found to be identical, the bob states that somebody is interfering with the transmission or there is a lot of noise. 

- But such repetition process to be expensive. 

- Therefore, for error detection and correction the methods used are reed Solomon and hamming codes.

2. Update

- Measures must be compulsorily taken for the prevention of the attacks by active intruders who might play back the old messages. 

- The longer an encrypted message is held by an active intruder, the more is the possibility that he can break in to it. 

- One good example of this is the UNIX password file.

- For anybody who has an account on the host, the password is accessible. 

- A copy of this file can be obtained by the intruders and they can then easily de-crypt the password.

- Also, the addition of the redundancy allows the simplification of the messages’ decryption.

- It must be checked whether the message has been sent recently or is an old one. 

- One measure for doing so is including a time stamp of few seconds in the message. 

- This message then can be saved by the recipient for that many seconds and can be used for comparing with the incoming messages and filtering the duplicates.

- Messages which exceed this time period will be rejected as being too old.

Apart from the above two principles the following are some other principles of cryptography:

Ø Authentication: For ensuring that the message was generated by the sender itself and no one else so that no outsider can claim as being the owner of the message.

Ø Integrity: In cryptography, the integrity of the messages must be preserved while sending the message from one host to another. This involves ensuring that the message is not altered on the way. Using cryptographic hash is a way to achieve this.

Ø  Non-repudiation

Making sure that all methods are used to inform users about patches or dot releases ..

A patch or dot release is typically done by a product team for defects or some improvements that the team would have made over the past period of time. Most people are familiar with the concept of Service Packs released by Microsoft for Office, Windows, and other tools that it has. So a service pack would typically take a number of improvements and defect fixes and make them available for users to download and install on their machines. A patch release in turn is meant for defect fixes that have been deemed critical enough to provide a fix to users. A service pack is typically meant to be a large patch, combining a large number of fixes and optimizations for the application. A dot release is a slightly different animal. Typically, in my experience, a dot release is when the code of the previously released version of the application is taken, the fixes are all applied to the source codes, and a new version of the application is released. This new version of the application is now ready for use by customers; if the released version of the application was 7.0, now the team can take the 7.0 code, add the fixes to the code, and then release a version called 7.1. This new version, with the fixes, replaces the previous version 7.0, and is the version that is available to consumers.
So, now that you have a new version, or a patch, or a service pack, how do you get this to your users. You would want all your users to take the new version, for multiple reasons:
- If you have fixes for problems available in this release, then with customers adopting such a release, there will be lesser need for support for such issues.
- If you get all your customers to adopt such a release, then it is easier to provide technical support. If you have customers having different versions of software such as 7.0 or 7.1, then it gets more complicated to provide support for such cases. In such cases, it would be easier if all customers have the 7.1 version.
- When you provide a new version post 7.1, it would be easier if you have most or all customers on the version 7.1. When a new version 7.2 is releases, there would be need to provide support for customers to upgrade from versions 7.0 or 7.1. When you have software such as Windows or Adobe Reader, on which there can be a number of service packs or patches released, this kind of upgrade support can make things difficult.

Now that we have the background, how can you increase the chances of more people taking the new patch or release ?
- Spread the information about new releases on the company site. As an example, if you take a large company such as Adobe, it has a section of the site called Updates (link). On this site, all the downloads and patches for different products released by the company is listed. Other large companies also follow a similar practice.
- Use social networking to spread the word. Most popular products have their presence on Facebook or Twitter, and companies should release information on these updates along with details of the major changes, and how to install the application.
- Seed support services such as consumer forums, user forums, customer support services, with information about the updates; for customer support, calls on major defects that are fixed with these updates should tell customers about the same.
- Nowadays, most major products have an update service, and the update should provide information to the customers about the desirability of the update and why the customer should do an update of the product.
- And now for a more forceful approach. Over a period of time, in order to ensure that everybody was on the update, product teams have actually terminated support for those users who are not using the latest patch. As an example, Microsoft a couple of years back stopped providing support for those users who were not on the Service Pack 2 of Windows XP.
All these techniques are important to increase the proliferation of updates among the application users.

What is the Process Control Block? What are its fields?

The task controlling block, switch frame or task struct are the names of one and the same thing that we commonly called as the PCB or the process control block. 

- This data structure belongs to the kernel of the operating system and consists of the information that is required for managing a specific process. 

- The process control block is responsible for manifesting the processes in the operating system. 

- The operating system needs to be regularly informed about resources’ and processes’ statuses since managing the resources of the computer system for the processes is a part of its purpose. 

- The common approach to this issue is the creation and updating of the status table for every process and resource and objects which are relevant such as the files, I/O devices and so on:

1.  Memory tables are one such example as they consist of information regarding how the main memory and the virtual or the secondary memory has been allocated to each of the processes. It may also contain the authorization attributes given to each process for accessing the shared memory areas.

2.   I/O tables are another such example of the tables. The entries in these tables state about the availability of the device required for the process or of what has been assigned to the process. the status of the I/O operations taking place is also mentioned here along with address of the memory buffers they are using.

3.   Then we have the file tables that contain the information regarding the status of the files and their locations in memory.

4. Lastly, we have the process tables for storing the data that the operating systems require for the management of the processes. The main memory contains at least a part of the process control block even though its configuration and location keeps on varying with the operating system and the techniques it uses for memory management.

- Physical manifestation of a process consists of program data areas both dynamic and static, instructions, task management info etc. and this is what that actually forms the process control block. 

- PCB has got a central role to play in process management. 

- Operating system utilities access and modify it such as memory utilities, performance monitoring utilities, resource access utilities and scheduling utilities etc. 

- The current state of the operating system is defined by the set of process control blocks. 

- It is in the terms of PCBs that the data structuring is carried out. 

- In today’s sophisticated operating systems that are capable of multi-tasking, many different types of data items are stored in process control block. 

- These are the data items that are necessary for efficient and proper process management. 

- Even though the details of the PCBs depend up on the system, the common parts can still be identified and classified in to the following three classes:

1.  Process identification data: This includes the unique identifier of the process that is usually a number. In multi-tasking systems it may consists of user group identifier, parent process identifier, user identifier and so on. These IDs are very much important since they let the OS cross check with the tables.

2.   Process state data: This information defines the process status when it is not being executed. This makes it easy for the operating system to resume the process from appropriate point later. Therefore, this data consists of CPU process status word, CPU general purpose registers, stack pointer, frame pointers and so on.

3.   Process control data: This includes process scheduling state, priority value and amount of time elapsed since its suspension. 

How to update and mail defects in Test Director?

Normal tracking of the defects requires too much efforts but tracking the repair of defects in a project just requires the periodic updates of the defects.

This can be done directly using either of the two:

1. Defects grid and
2. Defect details dialog box

However, the ability of both the methods to update some fields of the defects depends pretty much on the permission settings given by user. 

In this article we shall discuss how you can update the information of the defects by assigning different defects to different members of the development team, adding a comment and by changing the severity of the defects.

Steps for Updating Defects in test Director

1. Make sure that you have the defects module on display and if it is not do so by clicking on the defects tab.
2. Now, to update the defects directly using the defects grid, go to the defects grid and select the concerned defect that you also added using the ‘add new defects” dialog box. In order to assign the defect to a member, select the name of concerned member from the list by clicking on the ‘assigned to’ box in the defect  records.
3. Next click on the defect details tab and it will open up defect details dialog box for you.
4. In this defect details dialog box, do the following tasks:

a) Select the required severity from the severity box to change the severity level of the defect.

b)  Add a comment to explain the change in severity level if you wish so by clicking on the add comment button in the description menu.

5. To view all the attachments click on the attachments button in the left menu and you will see the list of URL attachments.
6. For viewing the history of the changes made to the defect click on the history button in the left menu. For every change made to the defect the date of the change, new value and name of the person who made the change is displayed by the test director.
7. When you are done with everything click OK to exit this dialog box and save the changes.

Steps to mail defects in Test Director

- The details about a defect can be shared with another user via e – mail. 

- With this, a routine of the inform development  and quality assurance can be developed regarding the defect repair activity.

- A ‘go to defect’ link is included in the test director using which the user can go directly to the concerned defect. 

- Follow the below mentioned steps to mail a defect to the concerned person:

1. First of all display the defects module by clicking on the defects tab.
2. Next select the defect you want to mail and click on the mail defects button. This will open up another dialog box called ‘send mail’ dialog box.
3. In this box you need to enter a valid e – mail address in the ‘To’ field.
4. For including any attachments or history of the defects select attachments and history option from the include box.
5. You can add your own comments under the additional comments.
6. When you are done composing the e – mail click on the send button. You will get a message box. Click ok.
7. The person to whom you have sent the mail can view it from his/ her mail box.

Even a test in the test plan can be associated with a specific defect in the defects grid. Whenever an association is created it can be determined whether the test is to be executed based up on the status of the defect. 

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.

What are all the default codes WinRunner generates when you start an application?

Automation might be quite a headache but it helps in decreasing the execution time by a great margin and in a way it saves a large number of precious man hours. Once you are done with the default installation of the winrunner you will observe that a winrunner directory has been created under programs. 

This folder consists of the following:

1. Winrunner executable
2. Uninstall winrunner
3. Soft key configuration
4. Read me
5. Fonts expert
6. Sample application folder and
7. Documentation folder etc.

The purpose of the winrunner is that it has been designed for performing functional testing and regression testing. Take a moment to study some sample application saved in the folder “sample application”. Now let us take a look at the winrunner application! 

- A tool bar is there which contains options such as new, open, save and list box for run modes namely:

1. Verify
2. Debug and
3. Update

- Plus a red button for recording purpose, green arrow for running the test scripts from line 1 and a purple line pointer for running scripts from the current line. 

- Apart from this there are start, stop and pause buttons. 

- Rest of the options on this tool bar are for debugging purpose.  

Now let us begin with the recording of a simple script! 

- You open the application software and winrunner as well. 

- Re-size both the windows such that both of them are visible to you and they do not overlap. 

- Start recording by clicking on the record button and perform some specific operations (like entering some user id and password of the start up page is login page) on the start up screen of the application. 

- After performing some 3-4 operations click on the stop button of the winrunner application and the recording will be stopped. 

- After this, the scripts can be played back and if you might have observed there is a code that the winrunner might have developed for you. 

- Now, after saving the script take a look at the code which some what looks like this:

        #startup window

        Set_window(“login”,3);

        Edit_set(“user id”,”active);

        Password_edit_set(“password”,”*****”);

        Button_press(“sign in”);

        And the code continues.

- Like the above code, the default codes are generated by the winrunner up on the start up of an application software.

- The symbol “#” marks the comments in winrunner. 

- The code may or may not contain a couple of comments. 

- The comments are inserted by the winrunner during the recording phase itself. 

- The second arguments or the numbers in the code represent the time lag between any two statements while the scripts are being recorded.

- Whenever a script is saved through winrunner, a folder by either a default name or name given by the user as the case may be is created which consists of a file by the name “script”. 

- This file consists of the default generated code in plain ASCII codes. 

- This code can be run in two modes namely the verify mode and the debug mode. 

- After this phase, comes the development mode in which the debug mode is used. 

- Finally, the verify mode is used. 

- The set_window() statement in the code lays down the focus on the window. - This helps in performing a particular function on a specific window. 

- When you type in the user id, it is identified by the winrunner and the edit_set statement is generated accordingly. 

- The next statement i.e., the  password_edit_set statement is similar to the edit_set statement, the only difference being that this field contains encrypted data and for security reasons is to be displayed as a series of asterisk “*” marks. 

When do you use Verify/Debug/Update Modes? (in Winrunner)

After you have developed the test scripts and finalized your test case, your next step is to run that particular test in order to check the behaviour of your software system or application. Whenever a test is executed using the winrunner, line by line the whole test is interpreted by the winrunner.  

As the TSL statements are interpreted line by line they are marked by an execution arrow which is visible in the left margin of the test script. As the test continues to be executed your software system or application is executed as if it is being controlled by a person. 

The winrunner provides 3 modes for the running your tests namely:

1. Verify run mode
2. Debug run mode
3. Update run mode

In this article we talk about the above mentioned three different types of winrunner run modes. 

- The first mode i.e., the verify run mode checks the application. 

- The second one i.e., the debug run mode debugs the test scripts.

- The third one i.e., the update run mode updates the expected results. 

- Only two modes i.e., the debug run mode and the verify run mode are available when you are using the winrunner run-time.

- Any one of these modes can be chosen from the list on the test tool bar. 

- The verify run mode represents the default run mode in winrunner. 

- You can either run the entire test or just a portion of it using the test and debug menu commands. 

- But always make sure all the necessary GUI map files have been loaded before you start with a context sensitive test. 

- You also have the choice of running individual tests or a group of tests using a batch test. 

- Batch test seems to be quite useful when you have very long tests to be executed and you need an overnight run. 

Now we will discuss about all the three run modes in detail one by one:

Verify run mode: 

- In this mode the current response of your software system or application is compared to the expected response by the winrunner.

- The results of this run mode are called verification results and enlist all the discrepancies that might have been observed in the current response and the expected response. 

- When the execution of the test stops, the verification results window is by default opened for the user to see. 

- As many sets as required of the verification results can be obtained. 

- However, you should always be ready with the expected results for the check points that you created earlier. 

- If there is any requirement for updating the expected results you just need to run the test in update mode.

Debug run mode: 

- This mode also helps in rooting out many of the bugs that might be residing in a test script. 

- The execution of a test in verify mode as well as debug is almost same, the only difference being in the folder in which the results are saved. 

- In this case the test results are saved in the debug folder. 

- Also, here only one set of debug results is stored and so the folder does not opens automatically for the user to view. 

- In this mode, the thing to be taken care of is that the time out variables must be changed to zero while the debugging 0of the test scripts take place.

Update run mode: 

- This mode helps in the updating of the expected results as well in the creation of a new expected results folder.

- Results for a GUI check point can also be updated and an additional set of expected results can also be created. 

Component Based Development (CBD)

Component-based development is a CBSE activity that occurs in parallel with domain engineering. Using analysis and architectural design methods discussed earlier, the software team refines an architectural style that is appropriate for the analysis model created for the application to be built. Once the architecture has been established, it must be populated by components that are available from reuse libraries and/or are engineered to meet custom needs.

For those requirements that are addressed with available components, the following software engineering activities must be done:
- Component qualification : It examines reusable components. These are identified by characteristics in their interfaces, i.e. the services provided, and the means by which consumers access these services. This does not always provide the whole picture of whether a component will fit the requirements and the architectural style. This is a process of discovery by the software Engineer. This ensures a candidate component will perform the function required, and whether it is compatible or adaptable to the architectural style of the system. The three important characteristics looked at are performance, reliability and usability.

- Component adaptation : It is required because very rarely will components integrate immediately with the system. Depending on the component type, different strategies are used for adaptation or wrapping. The most common approaches are:
* White box wrapping : The implementation of the component is directly modified in order to resolve any incompatibilities. This is, obviously, only possible if the source code is available for a component, which is extremely unlikely in the case of COTS.
* Grey box wrapping : This relies on the component library providing a component extension language or API that enables conflicts to be removed or masked.
* Black box wrapping : This is the most common case, where access to source code is not available, and the only way the component can be adapted is by pre/post processing at the interface level.
It is the job of the software engineer to determine whether the effort required to wrap a component adequately is justified, or whether it would be “cheaper” to engineer a custom component which removes these conflicts.

- Component composition : The component composition is a task assembles qualified, adapted, and engineered components to populate the architecture established for an application. To accomplish this, an infrastructure must be established to bind the components into an operational system. The infrastructure provides a model for the coordination with one another and performs common tasks. Among the many mechanisms for creating an effective infrastructure is a set of four “architectural ingredients” that should be present to achieve component composition.
* Data exchange model: Mechanism that enables users and applications to interact and transfer data. The data exchange mechanisms not only allow human-to-software and component-to-component data transfer but also transfer among system resources.
* Automation: A variety of tools, macros, and scripts should be implemented to facilitate interaction between reusable components.
* Structured storage: Heterogeneous data contained in a “compound document” should be organized and accessed as a single data structure, rather than a collection of separate files.
* Underlying object model: The object model ensures that components developed in different programming languages that reside on different platforms can be interoperable.

- Component update : When systems are implemented with COTS components, update is complicated by the imposition of a third party. The organization that developed the reusable component may be outside the immediate control of the software engineering organization.