Software development - Keeping track of stuff such as images across versions - Part 2

This is a series of posts on the handling of items other than code during the development of different versions of a software application. In the first post of this series (Keeping tack of images and other content during software development - Part 1), I took the case of the icons, images and other graphics that are used in a software product and which may be used as the same across different versions or updated when a new version of the product is used. For example, the application icon would be updated everytime a new version is released, so that it can also be differentiated from previous versions and also seek to graphically display the theme of that specific release. I will be adding more details in this post, focusing on the graphics and images.
The theme of this series is about how we do a lot of effort to ensure tracking of different versions of the code of a product (given that the code is seen as the most important valuable of the release in terms of being its Intellectual Property - and the IP of products such as Photoshop, MS Office, and others is very valued by the organizations that build these products) in a code repository, and with the use of processes such as labeling and branching, easily able to track which version of code was contained in which release.
However, my experience in multiple versions of a major software application led me to believe that this same sort of focus is not put on the non-code items that also form part of the application. I have already talked about the graphics and images that are used in an application and how my experience led to believe that organizations can very disregard the need for having a good process regarding these items. Let me continue on the same example that I was using earlier.
We had a team that would provide us the graphics and we would go through several rounds of discussions, sharing these graphics with the core team and the team that would create the installers that were an integral part of the application. However, the process was so haphazard in terms of their sending us the original set and later versions by email (as .zip attachments), and the process of reviewing them (even though we tried various options such as using Excel, Wiki, or even filing for changes as defects) did not provide a high level of confidence that the process would be error-free. And so it turned out, in the sense that invariably we would find out that some graphic was missing, and so on and so forth. Further, there was an additional element of complexity in this discussions, since the size required of the graphics was different.
The application dialogs, the installer dialogs and other such dialogs had different requirements in terms of size of such graphics, and so there was a need to ensure that we were communicating these different size requirements, and then receive the different sizes. Since they were producing such graphics in a large size, it eventually turned out better for them to send us multiple sizes of each graphic and we could pick and choose the one we liked. We did try using a more process oriented tool for this purpose, but getting a creative team to follow tight processes and the like were very problematic and caused additional stress for the program manager of the team once the process was put in place and the creative team did not follow the defined processes. As a further example, once they provided us these sizes, there was no effective place other than a folder on a server to save these, and if you needed a different size in the next version of the product, it could be real hard to work these.

More in the next version of this post (Keeping track of stuff such as graphics and others across software versions - Part 3 - TBD).

Software development - Keeping track of stuff such as images across versions - Part 1

When you are working on a software, it is not just code that you need to be worried about. A typical large software will contain a large amount of stuff besides the code that your software engineers write. When you look at the menus of the software, there might be cute icons to depict certain functions, or even if you look at the typical Undo option that sits in the Edit menu of a large number of options, there would be a button that you could hit for doing the Undo. If you look at Microsoft office recent versions, there would be a ribbon kind of menu at the top that will have a lot of options, and all of these are complemented by the visual appearance of icons. Typically, software makers try to ensure that their software has easy to remember buttons / icons that users remember and which makes the software apparently more usable by consumers.
However, for code, you would use some sort of code repository; but the same is not truly the same for non-code items such as buttons and other graphic options. Well, actually you can store such icons / visual items in the source safe but you will not be able to do operations such as comparisons between different versions of these items, and in fact, only when you actually export the history of such graphics from the source safe, will you be able to visualize what a previous version of the graphic items looks like.
One of the big challenges that software makers have when using such graphics in their application is about maintaining them. Consider the fact about the application icon (this is typically the graphic that is seen on the desktop, or in numerous other places where the name of the software is referenced). But, as you move from one version to another, you will need to have an application icon that is different from the icon used with the previous version. This helps you to mark that specific version of the software with a specific icon. So what do you do with the icon that you were using for the previous version ? You still need to save it somewhere since it was used in the previous version, and from time to time, people want to reference these icons and other imagery used within the product (once, we had a case where we were in version 7 of the product, and the management team wanted us to present the main graphics (including the application icon) that were being used in the previous 5 versions of the software; the idea was that there was a review team that was looking at a co-relation between the icon and the main focus of that previous release and whether these graphics were effective. It was hard to find the correct imagery, and the specialized team that had been preparing the graphics for us had suffered a lot of attrition over the years; they were unable to provide us the data that we needed. Finally, we had to do a lot of installation of previous versions, compare these with the versions stored in the source safe and then finally come up with the list.).
The idea of the previous story was about how it is much more difficult to maintain items that are different from code; since with code, the source safe will do a quick text comparison and make out the changes in code over a period of time. And mature large applications can have huge number of graphics embedded all over the software, and it is hard to find somebody in the team who will have the knowledge of which graphic was added at what period of time, and more important, the reason for why a specific graphic was added. And there are more complications that come into the picture. Consider that you are using a graphic in your software that was contributed by a team member and it was included in the software, and this happened over 4 years back. The graphic is still being used, and suddenly there is a legal challenge hit for the company over the rights of the graphic. At this time, you better have a good system of maintaining records to ensure that you can solve such a problem.

The next post will be a continuation of this series (Keeping track of stuff such as graphics in the software - Part 2).

What are different HTML errors?

HTML or hyper text mark up language is perhaps one of the most used mark up languages for the web pages, sites and applications with which most of us are familiar. This language is written using the HTML elements which mainly constitute of the tags enclosed in the angle brackets like:

These elements are housed in the web page or site. Most of the HTML tags are implemented in pairs of two.

HTML ELEMENTS AND CONTENT
- Some tags are even empty and are commonly known as empty elements.
- These are usually unpaired unlike the filled elements which are paired.
- In the paired tags, the first tag is called the start tag and the second one is then called the end tag.
- Between these two tags, any text, comments, tags etc can be added by the designer of the web sites.
- The content that is to be added should only be of textual type.
- Due to some wrong designing principles often some errors are introduced in to the html of the web site or the page.
- One of the most common errors is the insertion of the graphical content in to the html.
- Such content is neither displayed nor is it interpreted.
- It simply causes the malfunctioning of the web site.
- Other elements of the html allow the addition of the graphical content and only these should be used whenever some graphics are to be inserted in to the page.
- Html elements provide a means for the creation of the structured documents that denote the structural semantics for textual content like:

1. Lists
2. Links
3. Paragraphs
4. Headings
5. Quotes and so on.

DIFFERENT HTML ERRORS AND THEIR IMPACT

- Html can also be embedded in to the scripts like javascript which also some times leads to errors when inserted incorrectly.
- Such errors affect the behaviour of the web sites and cause them to behave abnormally.
- Whenever the site is affected by an error or a bug is encountered, a set of error messages is generated by the business logic component which is then stored as a string in any of the available scopes.
- For using such functions, you need to define an application scope with the name of default attribute, because if such a scope is not found, then nothing is to be rendered by the business logic.
- Some designers forget to define such scopes and therefore end up with unnecessary errors in their web sites.
- Many more errors occur whenever a requested is generated by the client to the web server.
- In such cases the server responds with some status messages, few of which have been mentioned below along with the possible errors:

1. 400:
Bad syntax of the request is preventing the server to process it.

2. 401:
The request though being cannot be processed because of unavailability of the authentication processes.

3. 404 not found:
The page requested by the client is found to be unavailable at that moment.

4. 405 method not allowed:
The client made request in such a way that is not supported by that site.

5. 407 proxy authentication required:
The client has not authenticated its proxy.

6. 408 request time out:
The server’s request time expired while waiting for the client to generate one.

7. 409 conflict:
The server is not able to process the request because of the presence of some conflict in it.

8. 410 gone:
The page that was requested is no longer available on the web.

What are different tips for testing GUI on smart devices?

WHAT ARE SMART DEVICES?
- Smart devices are most popularity gaining devices in today’s world.
- Though being a small cordless electronic device, it is capable of serving us many purposes.
- It is highly portable and can be connected anywhere to a network like 2G, 3G, 4G, Wi-Fi etc.
- You can have a voice and video communication and browse internet.
- Smart devices in the coming years are going to outnumber many other devices like cell phones and laptops.
- These devices exhibit quite appraisable artificial intelligence and ubiquitous computing factors.

But, what makes these smart deices so popular among users except their features?
It is their user friendly GUI (graphical user interface).
- The abstraction feature of the OOP is employed here in hiding the interactions between the user and the computer.
- These devices are able to optimize themselves according to the environment in which they operate.
- To some extent these devices are self governed.

GRAPHICAL USER INTERFACE ON SMART DEVICES
- The GUI of these devices is vigorously tested to maintain the standard.
- GUIs are a bridge between the software system and the user.
- When agitated, the interface responds to the user’s activity like click or mouse movement.
- GUI makes it easy to implement the software code and also for users to interact with the device.
- GUIs form a major percentage of the program code.
- A lot of time is devoted in developing graphical user interface and testing it. - GUIs account for the usability of the device.
- The current GUI testing methodologies are mostly manual and ad hoc in nature.
- The tools used for GUI testing record the test case execution and captures screen shots during testing.
- The recorded sessions are played again and the input test data is manipulated. - This methodology requires a large effort.

Here we are going to discuss some tips regarding GUI testing of smart devices.

- The effectiveness of GUI testing depends on the ability of the tester to develop new interactions between the user and the software.
- The best advice for graphical user testing will be to use an automated test generating tool.
- This will save you much time and effort.
- Before using an automated test generator, you should code for all possible interactions.

Even though the automated test generator provides a great help, there are many decisions that it misses out.

To compensate for this, the better option is to release the beta copy of the GUI and let the users test it and give you the feedback. More the number of testers, more effective will be the testing.

Here we are listing some tips for making GUI testing more effective:

- Having a defined coverage criterion will make it easy for you to decide what to test first.

- Prepare documentation for the test cases that have to be executed. In this documentation, define the test input data to be used for each test case. The input test data should be related to the requirements specifications of the software system.

- Compare the actual output with the expected output and decide what can be done to get the desired output if the two don’t match.

- After you have predicted the outputs for the test cases, execute them one by one and verify the output.

- Most importantly ask yourself questions like:

a) “how to improve the interaction of the user and the system?”
b) “how to make it easier for the user to access various features of the device through GUI”, “what are the possible where bugs can be found?”
c) “is this GUI compatible with the environment in which it is to be used?”
d) “what are the features that should be compulsorily incorporated in to the GUI?”.