Working with different UI elements for translation ..

When you look to make your product available in many languages, or when you are looking to extent the availability to a new language, there is the need to do an effort estimation. After all, there is a cost involved with ensuring that your product is available in a new language; with these costs being:
- Cost of manipulating your code to ensure that it can support the new language (for example, if you want to have your product available in Arabic, you need to ensure that your product support the right-to-left style that is supported by Arabic, rather than the convention left-to-right that is supported by English and most other languages). There are other areas in the code which may need to be manipulated before the product can be available in the new language.
- Cost of translation of the application. This involves translation of all the UI elements in the application (and in the second half of this post, I will provide more details of what this means).
- Cost of doing an initial testing of the application in the new language to ensure that you have identified places where the translation needs to be done (this is different from the more detailed testing that needs to be done once all the translated elements are put into the application)
- Functional and linguistic testing that needs to be done to ensure that the application works properly in the new language. You would wonder as to why the translated application needs to have functionality testing, after all, there is no change in functionality. However, there is a lot that can go wrong from a functional perspective during the translation process. Once we had a case where the parameter for the new language was being passed incorrectly, which meant that the application was not working in a specific area, and this was caught during the functional testing and quickly corrected.
- If the application uses external components, then it is needed to be ensured that all these external teams either already support the new language, or provide the required support in your scheduled time.

Once you have worked out all these effort estimates, you need to get onto the actual effort involved with translation, and this can be tricky. There are different UI elements that need translation, with different levels of effort required for these translations. For example:
- There are simple UI text elements. These need to be sent off to the translating team and received back. There is very little complexity in such elements.
- There are images that need translation. If the images have either a snapshot of a section of the application or something in text inside the image, then there is a problem. You need to get snapshots of the application with the new language, and that takes time and effort, but is not complex. However, if you have text within an image (supposed this is showing an image of a template), then you need to get the original image (typically a Photoshop format, a PSD) and then translate the text, and re-insert the new image. This is more complex, and if the application has been in existence for some time, the original image may even have been misplaced.
- If you have videos within the application, that either show instructions or show the application interface, then it gets more complicated. You may need to re-shoot the videos, and that can quickly turn out expensive. Similarly, if you use Flash Video within your application, you will need to generate them again.
- And then there is the complexity associated with languages where the length of the text in certain languages is more than that of the original language. So, when you consider conversions into say German or Japanese, the converted text would be longer than the original text and may not fit properly in the application. In such cases, either the translation has to be tweaked and made shorter, or the application needs to be tweaked to accept the longer text. In both cases, there is a lot of coordination and process.

What Tools are used for code coverage analysis?

Code coverage analysis is quite an essential process that makes up the complete and efficient software testing process. 

This analyzation consists of the following three basic activities:

1. Checking out for the areas of the software system or application that have not been exercised by the set of tests that have been performed so far.
2. Creation of the additional test cases so that the code coverage can be increased.
3. Determination of the quantitative measure for the code coverage which some what provides an indirect measure of the quality of the software system and application.

Apart from this, there is one more optional aspect of the code coverage analysis which is that it helps in the identification of the redundant test cases that add to the measure of the code coverage but do not merely increase it.

In this article we have discussed about the tools that make this whole process of code coverage analyzation quite easy.

Tools Used for Code Coverage Analysis

- The code coverage analyzation is quite an effort and time consuming process and therefore is nowadays automated using tools like code coverage analyzer. 

- But a code coverage analyzer cannot be used always like in situations when the tests have to be run through the release candidate.

- For different languages, there are many different and vivid tools are available for code coverage analysis.

1. For C++ and C programming languages:

a)  Tcov

b)  Bulls eye coverage

c)  Gcov

d)  LDRA test bed

e)  NuMega True Coverage

f)   Tessy

g)  Trucov

h)  Froglogic’s squish coco

i)   Parasoft C++ soft

j)   Test well CTC++

k)  McCabe IQ

l)   Insure++

m)Cantata

2. Tools for C#:

a)  Mc Cabe IQ

b)  Jet brains dot cover

c)  Ncover

d)  Visual studio 2010

e)  Parasoft Dottest

f)   Test driven.NET

g)  Kalistick

h)  Dev partner

3. Tools for Java:

a)  McCabe IQ

b)  Clover

c)  EMMA

d)  Kalistick

e)  JaCoCo

f)   JMockit coverage

g)  Code coverage

h)  LDRA test bed

i)    Jtest

j)   Den partner

k)  Cobertura

4. Tools for Java Script:

a) Mc Cabe IQ

b) JS coverage

c) Code coverage

d) Script cover

e) Coveraje

5. Tools for Perl:

a) Mc Cabe IQ

b)  Devel cover

6. Tools for Haskell:

a) HPC (Haskell program coverage) tool kit

7. Tools for Python:

a) Mc Cabe IQ

b) Fig leaf

c) Pester

d) Coverage.py

8. Tools for PHP:

a) Mc Cabe IQ

b) PHP unit

9. Tools for Ruby:

a) Rcov

b) Mc Cabe IQ

c) Simple cov

d) Cover Me

10. Tools for Ada:

a) GNAT coverage

b) Mc Cabe IQ

c) Rapi Cover

Out of all the above mentioned tools for C and C++, the bulls eye coverage has proven to be the best code coverage analyzer in terms of reliability, usability and platform support etc. 

This coverage analyzer is different from the other analyzers in the following ways:

1. Better coverage measurement
2. Wide platform support
3. Rigorously tested
4. Efficient technical support
5. Quite easy to use.

- Using this tool it can be determined that how much of the software system’s or application’s code was tested and this information later can be employed to focus your testing efforts and areas that require some improvement.

- With the bullseye coverage a more reliable code can be created and time can be saved. 

- The function coverage provided by the bulls eye coverage gives you a very high precision.

You can include or exclude the parts of the code of your choice. And what more? You can even merge the results you obtained from the distributed testing plus the run time code can also be included from custom environments. 

What skills needed to be a good software test automator?

If you have studied the history of the test automation process you might have observed that there have been so many failures which have now become the lessons for the entire testing community. Because of the lessons learnt it was decided, that the scripts that will have to be developed must be reusable. 

In order make most of any testing methodology, it is required that it must be made manageable as well as reusable. 

There are certain things that a tester should keep in mind to be a good tester:

1. Test automation is not a sideline but rather a full time effort.
2. Test frame work and test design should be treated as separate individual entities an not as the same one.
3. The test frame work should be independent of the software system or application that is under testing.
4. It should be easy to expand, perpetuate and maintain the test frame work.
5. The test design as well as the test strategy should be independent of the frame work.
6. The test strategy should be so effective that is should be capable of removing the complexities related to the test frame work from the testers.

Skills needed to be a good software test automator

In this article we have focussed up on the skills that are needed to be a good software test automator. Some other skills are:

1. Good logic for programming code of the scripts.
2. The automator must have good analytical skills.
3. The automator must have adequate knowledge about the testing tools that are to be used in the automation process.
4. He/ she should have the habit if thinking out of the box.
5. Critical in nature
6. A good automator can think well from the user’s point of view.
7. A good automator keeps an eye on the details of the test automation process.
8. The knowledge about domain is a must.
9. Good judgement skills.
10. Good code writing skills.

Qualities of a good Test Automator

- A good test automator is the one who implements a test strategy that supports development of the intuitive tests and can be executed both via automated tests and manually.

- The test strategy that a good test automator uses will allow the tests to highlight the steps to be performed.

- A good test automator develops a frame work to harness the benefits form the implementation of the key word drive testing scripts and tradition testing scripts. 

- A good automator implements a test automation frame work in such a way that it is completely independent of the software application that is under question. 

- A good automator fully documents and publishes the test automation frame work.

- One thing that should always be kept in mind is that the testers are only testers and not programmers. 

- Good testers and automators are those who have both the testing as well as programming skills. 

- Most of the testers are domain experts only having zero or very little technical skills that are an immediate requirement for the software testing. 

- Many testers also have a habit of splitting the time between testing and development phases and so they do not require to learn a complex scripting language. 

What is meant by project velocity?

The project velocity is one of the terms that you come across while discussing about the iteration planning and release planning! The project velocity has a got a very important and  not to be ignored part to play in these two mentioned planning processes but still most of us are not aware of its importance. 

This article is centred on the project velocity and has been discussed in detail. Like the normal physics velocity, the project velocity gives the speed of the development of a software project. 

In other words, the project velocity gives the amount of work being and efforts being spent on the software project. 

About Project Velocity

- The project is simply the summation of all the estimates of the user stories that were involved in the iteration. 

- For the release planning, you add up the estimates of the user stories and for the iteration planning the estimates of the programming tasks are added up. 

- But anyway, both the factors can employed for determining the project velocity in the case of the iteration planning. 

- In the iteration planning meeting, the number of the user stories chosen by the customer is same as it was in the previous iteration. 

- There is a rule that the project velocity of the consecutive iterations must not exceed their preceding iterations. 

- These programming tasks are nothing but a broken down or divided version of the user stories. 

- The development team is supposed to take up or sign up for only the same number of tasks that were present in the previous iteration. 

- Such an arrangement proves to be a great help to the developers when they stuck in a sticky situation and need to recover and clean up from it and thus getting the average for the estimates. 

- The project velocity is suppose to rise when the developers are allowed to question the customers for other user stories when they have already finished their work and tasks like cleaning up are also accomplished.

Please do not think that you will get the project velocity consistent throughout the development cycle! It is expected to follow through some ups and downs. 

- But if a dramatic change is observed in the project velocity, then it is an issue of concern. 

- But there is no need to worry since all this can be kept in check by re- estimation and re- negotiation of the release plan. 

- It is not just in this case that the project velocity may change! 

- Even when the system is put under production for the maintenance tasks, again the project velocity is subjected to changes. 

- Division of the project velocity by the length of the iteration or the number of people involved. 

- Furthermore, the number of the people involved in the iteration is not an appropriate way for making comparisons between the productivity of two products. 

- This is so because each and every team has got its own different criteria for estimating the user stories and so we get some high estimation and some low estimation. 

- Important is to keep a track of the amount of work being done on the project so that a steady project velocity for the development can be maintained that can also be easily predicted.

The problem comes while making the first estimation! 

- At least for the following iterations you will have a clue that what project velocity is required. 

- If this measure is used properly you may be able to detect a major fault in your project much before the time at which you would have known with the help of the traditional development methods. 

What is meant by the term system metaphor? What is its use?

System metaphor- well this is a term which is related to the extreme programming but less known of! What is the system metaphor and what is its use and what is the need? 

We shall be discussing all these aspects of the system metaphor in this article. 

"A system metaphor in the simplest words can be defined as a story that any one includes customers, programmers and managers) can tell reading how a system works".

Reasons why we need to use System Metaphor

There are several reasons for why we need to use the system metaphor.  They have been listed below:

1. Architecture: The metaphor is consider to shape the software system or application exactly as it is required by us with the help of identifying the key objects and giving suggestions regarding the aspects of their interfaces. The dynamic and the static models of the system are supported by the system.
2. Shared Vocabulary: A common system of names for the objects and relationships that exist between them are suggested by a system metaphor only and thus it provides a powerful vocabulary for the developers and programming experts. The vocabulary created is shorthand and specialized.
3. Common Vision: System metaphor comes in to as a very handy tool that helps in enabling all the stake holders to agree up on the working of the software system or application. The key structure of how the problem and the solution have been perceived is provided by the system metaphor itself. Overall, this helps in understanding the working of the system well.
4. Generativity: A system metaphor by the means of its analogies can get you new ideas regarding the problem and its solution and can further dig out many other important issues.

How to choose a System Metaphor?

- Even though choosing up a proper system metaphor for your system may take some time and efforts, it is the best option that you have for exploring several possibilities just by looking at the system through various views. 

- If by combining two metaphors you are getting the one that is fit for your then go for it. 

- Now what if you come to know that you could have got a better metaphor for your system than what you have already opted for? No need to worry, you can still develop your system in that direction. 

- Such a measure will also help you in achieving a greater understanding of your problems. 

- What if you are not able to think of any good metaphors? 

- There are some naive metaphors always available to your rescue. Below mentioned are some examples of the system metaphors:

1. Use of a pension tool as a spreadsheet.
2. Using desktop metaphor for graphical user interface.
3. Buckets, lines and bins in C3 payroll.
4. Bills of materials in VCAPS.
5. A double entry system being used as book keeping and spreadsheet.

More about System Metaphor

- Suppose you sign a contract with a client for developing some software system, what you do next? 

- You search for a good system metaphor that will guide the development of your software system or application.

- A metaphor very well guides the development process of a project. 

- Not any one can choose a good metaphor, it requires skills, practice and of course deep knowledge.

- A system metaphor is nothing but a metaphor having a simple design and some essential qualities that the original needs to have. 

What is meant by time boxed iterative development?

The iterative type of the agile software development has always been the favourite choice of the developers and testers when it comes to adopting a time and effort efficient and effective agile software development process. 

Till now three approaches to the iterative development have been developed namely:

      1. Risk based iterative development

      2. Client based iterative development

      3. Time boxed iterative development

This article is here to focus up on the time boxed iterative development. But before we move on to the time boxed iterative development, let us brief up ourselves with the concepts of the iterative and incremental development so that it will be easy for us to understand the time boxed iterative development better.  

What is Iterative Development?

- Iterative and incremental development is an essential part of the agile software development process and lies at the heart of it.

- The iterative came in to existence as a response to the weaknesses of the other agile software development models especially the waterfall model.

- Apart from just being an essential part of the agile software development, it is also necessary to the extreme programming, rational unified process and many other agile software development frame works. 

- It is based up on a similar process of the business process improvement. 

- The iterative development is a way to develop a whole software system or application in small steps via the repeated cycles at a time. 

- There are two approaches that can be followed for accomplishing a task:

   1. We can either work non stop to accomplish the goal or

   2. We can define a time limit for ourselves and achieve as how much we can in that time period. 

The second approach is called time boxing. 

What is a Time Boxed Approach?

- It is a simple one yet effective technique from the perspective of planning and over the years has been found effective in completing the jobs within a time limit. 

- If we look at this approach from the perspective of planning, it is found to be useful in the development processes which are involved with the development of a complex software system or application and the starting point is quite uncertain. 

- On the other hand if we look at it from the perspective of the personal development, it is extremely helpful in improving the effectiveness as well as the productivity.

- In fact this approach is quite easy to follow but requires maximum effort. 

- Using time boxing approach, you fix up a time period and try to achieve the maximum you can within that time frame. 

What is meant by Time Boxed Iterative Development

- Time boxing approach employed for the iterative development is termed as the time boxed iterative development. 

- In such an approach to iterative development the task is divided in to several small iterations and each iteration is provided with a time box.

- Each of these iterations has its own budget, deadline and the deliverable. 

- In some cases, time boxing iterative development is employed for managing the risk.

- Since it is important to meet deadlines, it is necessary that the deadlines are not changed without the prior permission of the project owner. 

- An inadequate breakdown of the task can lead to the underestimation of the time requirement of the project. 

- To avoid changing of the deadline following three points can be followed:

1. Reduction in the scope: requirements having lower impact can be dropped from the plan.
2. Keeping time as the fixed constraint throughout.
3. Increase in the cost: the resources and the over timing can be added in to the plan.

Many projects that have been developed with the time boxing technique have been reported to be successful. 

What are different design specifications while drawing a test plan?

When a development team is working on a project, how do they ensure that the functionality is being coded correctly? Design specification documentation serves this purpose.

What are Design Specifications?

- A design specification document must be free of any ambiguities and should be complete, since an incomplete design specification document full of ambiguities can have you reaching for the costly rewrites.

- A good design specification follows a pyramidal approach i.e., from the top it provides a complete and broad overview of the software system or application and its components and at the lower levels it provides a detailed overview of the primary components of the application.

- The details should be as much required by the development team.

- Most of the software developers tend to work with design specifications documents which include detailed description of every function, sample screen shots, layouts of the data base as well as reports.

- Many a times it happens so that the client does not provides sufficient detail; in such a case the developer responds in writing asking as many questions required getting a detailed overview of the project.

- These questions are supposed to enquire in depth regarding the design specifications of the application under development.

- Writing an effective and a self sufficient design specification document is an art in itself.

- If you find it difficult to write a design specification document, you can first write a basic outline and then fill it up based up on the needs of the client as well as the skills of the developers.

- Coming up with a document that fits the requirements and needs of both the client and the developer is quite a difficult and requires a lot of struggle.

- There is no need to show the entire specification document to the client or the customer since they won’t understand it.

- Some organizations even take up the extraneous effort for creating two design specifications documents.

- One contains only a broad overview of the application for the customers and clients while the other one consists of detailed description of the application and its primary components meant for the developers.

- There are some artistic developers who themselves like to fill up the details for the design specifications after knowing what functions are to be performed by the application.

- To make it easier, you can start off with a high level description of the design specifications followed by signing off by the client.

- Then you can go for writing second file with more detailed descriptions.

- Keep the design specification document updated as regularly as possible.

- IEEE has come forward to help in this regard and it has laid down “IEEE 1016- 1998 standard” for specifying a structure for the SDD or software design description.

What should a design specification include?

According to IEEE standard, the design specifications must include at least the following:

1. Introduction: It includes
(a) overview of the design and
(b) Requirements traceability matrix

2. System architectural design: It includes (a) discussion regarding the alternative designs
(b) Chosen system architecture
(c) System interface description

3. Detailed description of the application components

4. User interface design: It includes
(a) description of the interface
(b) Objects and events (actions)
(c) Screen image

5. Additional information

After completing writing down the design specifications, you should compulsorily have it signed off by the client or the customer so as to have a proof that they abide by everything that is there in the specifications document.

This also provides coverage to your bases and enforces that the customer reads the whole specifications document. The design specifications should also be reviewed by the quality assurance people since a good design specification helps in creating better test cases.

What are three main purposes of software testing?

It is a world wide established fact that the software testing has proved all the way very effective in improving the satisfaction of the clients and customers by delivering them a software product that is quite free of defects, errors and bugs.

Only the stable, error free and reliable software systems and applications are accepted in to the business. There is no place for the unstable and buggy software systems.

WHAT HAPPENS IF TESTING IS NOT DONE PROPERLY?

- There is a substantial increase in the chances of the failure of a software system or application if it is not tested or tested only up to a small extent.

- This in turn increases the rates of wastage of time as well as one’s precious efforts.

- The rework and rewrites and their maintenance cost the organization so much and also annoys the customers and clients.

- If a software system fails, it only gives an indication towards the inadequacy of the efficiency of the system and a lack of testing.

- The failure of the software systems or applications can cost too much in certain cases where very sensitive and critical matters are dependent on the working of the software.

- Software testing has been scientifically defined as a process that deals with the verification and validation of the software system or application.

- It ensures whether or not the system meets all the requirements specifications that have been used all along its development cycle to guide its designing and makes sure that the software system or application is working as expected by the makers.

THREE MAIN PURPOSES OF SOFTWARE TESTING

Three main purposes of the software testing have been laid down as mentioned below:

1. Verification
This purpose deals with the verification of the development process of the software system or application and ensures that the software is being developed or built in the right way.

2. Validation
This is all about making sure that the right software artefact is being produced.

3. Defect finding verification
This is for the purpose of ensuring that the software system or application that is being built, meets the technical specifications and requirements stated for it by the customer or the clients. It also checks out for the variation of the defect range between the actual outcome and the expected outcome.

BENEFITS OF SOFTWARE TESTING

- Software testing has very well taken up the responsibility for ensuring that the software system or application meets the business requirements as specified for it and thus whether or not works as expected.

- The compatibility of the software system or application with a range of different platforms is also evaluated and the performance rating is given.

- Whether the software system or application should be released or not, is determined on the basis of the results of the software testing.

- Software testing has a whole lot of benefits, the greatest ones being the saving of the time and efforts which are indeed very priceless commodities.

- Defects, bugs and errors if detected earlier eat up less time and money and reduce development time and also if the application or system is kept error free in the beginning itself, then less problems will be faced in the future development phases.

Software failures as mentioned above can give rise to life threatening issues to the:

- People (for example, control system failure resulting in a plane crash, life support system failure in hospitals causing deaths)

- Environment (for example, a software failure causes the harmful radiations and chemicals to be released in to the environment and thus affecting the whole eco system)

- Companies (for example, some times the software might do the bill incorrectly due to some discrepancy in it causing the company a great money loss) and so on.