How to design and copy test cases in test director?

Application testing process is not the one that can be completed in a jiffy. It demands constant input in form of efforts, organization and maintenance. Well, all this becomes easy when you are assisted by mercury interactive’s test management tool.
Test director saves you a great deal of efforts for tasks such as requirements analysis, test planning, test execution, defect tracking etc. here in this article we are going to tell you how you can design as well as copy the test cases in test director. After the tests created for all the subjects have been added to the test plan tree and the basic test information has been defined, the test cases or the test steps are defined.
By defining them we mean that more details or step by step instructions are provided for how that particular test case is to be executed. Each step of a test case consists of two things namely:
1. Actions to be performed on the application under testing or AUT and
2. The expected results.

Test steps can be created either for manual tests or automated tests using test director. For manual testing it is said to be complete when you are done with the designing of the tests.
Then, the test execution can be straightaway be started by using the test plan tree. But in the case of the automated testing, an addition step is to create automated test scripts using any other mercury interactive tool such as Winrunner or some other third party tool.

Steps for designing test cases

Below mentioned are the steps that one can follow for designing a test case:
1. It has to be made sure that the test plan module is on display and if it is not click on the test plan tab to turn it on.
2. The test case for which you are about to design the test steps also needs to be displayed. You can do this by simply clicking on the name of that particular test.
3. Next you need to launch the design step editor by clicking on the ‘design steps lab’.
4. In the design step editor dialog box clicking on the new step button you will get a new step dialog box which will ask you enter a step name which is by default a sequential number.
5. Now for defining that step you require to fill up the following fields and click OK:
         a) Step name
         b) Description
         c) Expected result
6. Last step is to click OK which will close the design step editor and display the design steps.

How to copy the test cases?

In test director you get the option of copying the test cases either from the same project or from some other. Follow the below mentioned steps:
1. You need to turn on the design steps tab and select that particular test case from the test plan tree which you want to be copied.
2. Next step involves selecting the steps of the test cases which you want to be copied. You will observe a gray sidebar, position the mouse pointer there and you will see that the pointer changes to  ->. Now hold down the shift and select the steps you want to be copied.
3. By using the copy steps copy down all the selected steps.
4. Next paste the steps where you want them to be copied in the test plan tree by using the paste steps button in the design steps tab.

What are the advantages of optimizing test automation process?

Like all the other processes in the field the test automation process has also been optimized and has reaped huge benefits. 

- Test automation is carried out for the manual testing processes employing formalized testing processes and this automated test is then further optimized to make it much more effective. 

- Test automation is like any other process that requires writing a computer program that will do a particular thing like testing in the case of test automation. 

- Test automation takes a lot of time but once if done can save a whole lot of time afterwards.

In this article we are going to discuss the effect the optimization inflicts up on the test automation process plus we will also chalk up the advantages as well as disadvantages of optimizing the test automation process. 

- Throughput represents a very critical issue in almost all the testing processes.

- It is quite important to take care of the throughput factor especially at the maintenance level. 

- There are some general rules and approaches that have been defined to be used during the analyzation of the total requirements of the software testing system and these rules and approaches have worked wonders in reducing the test time. 

- Apart from these rules and approaches there are other things like new programming environments, new interface standards (like Ethernet) that helps in making a significant improvement in the testing system. 

Till now a variety of approaches have been validated that can be used for the optimization of the test automation process in order to increase the throughput.

For optimization we can say that using it one can make significant gains only with a modest investment of time and effort. The software quality can be optimized by adopting the best of the software testing methodologies available, tools, processes and of course people.

For further optimizing your test automation process you must take a look at the below mentioned aspects:

1. Code, documents and inspections.
2. Unit testing
3. Prototyping
4. Allocation of the time and other resources.
5. Designing and coding according to the testing.
6. Automation of the regression testing.
7. Designing of the tests for the verification of the user expectations and specifications.
8. Document analyzation
9. Performing positive root cause analysis.

- Some of the software systems and applications are quite small and simple and so the time taken to process the requests is quite less and negligible. 

- However, when it comes to the larger software systems and applications, the optimization of the test automation process can save a lot of time for even the most basic test case.

- For testing any big and complex software system or application, the optimization becomes crucial. 

- The goal of every software tesing methodlogy is to ensure that the software applications works just like what the customer has figured in his/ her perspective. 

- One of the myth about the optimization is that it is quite expensive and hence it should be used when extremely necessary.

- There are people who believe that 100 percent optimization of the test automation process is an ultimate objective. 

- However there is no particular formula, the relative merits of the optimization of the test automation process depends up on many factors. 

- When you optimize the test automation process, the efficiency of the whole automation process is increased gradually. 

Everyday we witness a dramatic increase in the complexity of the computing environments which puts quite a great pressure on the automated testing thus calling for optimization. 

Typically, what are the testing activities that are automated?

With the test automation use on the move, a lot of processes and testing activities are being automated nowadays as far as possible. Test automation has been widely accepted since it is quite an effective testing methodology that can help the software engineering industry to keep pace with this fast paced technology savvy world.  

Usually the processes that are automated include manual processes that make use of formalized testing processes. But besides these, there are many other software development processes and activities that are automated using the test automation and process and the best part is that they do not disappoint the testers.

In this article, we have taken up the discussion regarding the activities that are quite often subjected to automation. These activities are mostly concerned with the test automation. Usually test cases for automated software testing are exclusively written but the test cases for most of the manual testing processes that deploy formalized processes are subjected to test automation in order to save time and efforts both. However, before automating any testing activity it is made certain that the automated tests will be compatible with the system on which they will be run.

Today the developers are forced to develop software systems and applications in quite a small time frame which represents quite a big challenge. There is not only the need of testing the software system or application rigorously but also there is a need to do it as quickly as possible. 

What is automated Testing Life Cycle Methodology?

In order to make the development process quite systematic a methodology has been introduced which is commonly known as “automated testing life cycle methodology” or ATLM in short form. 

The ATLM lays down 6 processes or activities in the process of test automation and many of the sub activities are automate.

1. Decision to automate test: This includes:

(a)  Overcoming false expectations of automated testing.

(b)  Benefits of automated testing.

(c)  Acquiring management support.

     2. Test tool acquisition: 

    This is the second phase of ATLM and involves activities like tool evaluation and selection process. Here the activity tool evaluation can be automated to some extent. While selecting the testing tool it is required that the tester should keep in mind the system’s engineering environment.

    

     3. Automated testing introduction phase: This phase involves the following steps:

   

    (a)  Test process analysis: This analysis ensures that all the test strategies and processes are in one place. The test strategies, goals and objectives are all defined in this phase and are documented. In this phase only the testing techniques are defined and test plans are assessed.

    

    (b)  Test tool consideration: This step involves the investigation of the incorporated automated test tools and their viewing in the context of the automated project testing requirements. Also the mapping of the potential test utilities and tools to the test requirements is done. The compatibility factor of the testing tools with the software system or application and environment is verified and solutions are further investigated.

     4. Test planning, design and development

    5. Execution and management of tests: By this phase the test design and test development has been addressed by the testing team. The test procedures are now ready to be automated. The setting up of the test environment after every test case execution is also automated in accordance with the guidelines. Now the test plan is ready and test environment is also set up, the execution of the test cases is started. This whole process is automated in the favor of the exercising the software system or application under the test.

     6. Test program review and assessment

Does automation replace manual testing? What are the main benefits of test automation?

Test automation has proved to be quite useful in reducing the night mares of the testers regarding the testing of very complex, complicated and large software systems or applications. Almost all the manual testing processes that make use of the formalized testing processes have been automated. Although manual testing involves intense concentration and can root many of the defects and faults in the software systems and applications, it requires a hell lot of patience, efforts and time.

Can automation testing replace manual testing?

- In today’s fast paced software world, test automation has undoubtedly become one of the most strategic and critical necessity of the software development. 

- In the past years, the level of testing was considered to quite sufficient since the software systems and applications were not so dynamic.

But in today’s world we have explosive software systems and applications and we need to test them? Here the manual testing alone cannot suffice! 

- There are many classes of defects that cannot be traced without automated testing and there are several other types of errors and bugs that can be discovered using manual testing only. 

- So, we will say the automation testing cannot replace manual testing though it can be considered as a surplus to the manual testing. 

With rising demands for qualitative testing two things are possible:

(i) Either we increase the number of people involved in testing or

(ii) We increase the level of test automation.

- The rising demands for the rapidly developing web clients have made the need for test automation much critical. 

- The most unfortunate thing is that the testers are not full time to hone their software testing skills and the testers remain testers and do not become programmers.

- As a consequence of this, the simplicity of the software systems and application has been ruined and made far too complex and difficult to implement. 

- In order to get the most out of the test automation process, it should be implemented to the maximum extent it is possible. 

- If it is not used appropriately you can even face a failure in the long term development. 

To reap the full benefits of the test automation you need to keep the following things in mind:

1. Test automation is not a sideline rather it is a full time effort.
2. You should not confuse the test framework and test design as same entities.
3. The frame work that is to be used for the test automation should be application independent.
4. The frame work to be used must be maintainable and quite perpetual.
5. The test design as well as the strategy must be independent of the frame work.

Benefits of Test Automation

1. Test automation reduces the population of the staff required to carry out the testing.
2. Consumes less time.
3. Fewer efforts required.
4. Much preferable option when it comes to the size and complexity of today’s software systems and applications.
5. Testing is a repetitive process and this drudgery of the testers is taken by the test automation.
6. Test automation allows the machines to complete tedious task of repetitive testing while in the meantime the testers can take care of the other chores.
7. The testing costs are reduced.
8. Using test automation the load testing and stress testing can be performed very effectively.

Explain Automation of Smoke Testing?

Smoke testing though being a very useful, quick  software testing methodology, if not carried out in an automated way can take up a lot of time and efforts. 

Need for Automation

There is one more thing to manually carry out smoke testing which is that if later if you come to know that the testing was being carried out in wrong direction then it will surely give you a headache to perform whole of the testing once again and again if required. 

Why automation of smoke testing useful?

- Automation of smoke testing proves to be very useful in saving time and efforts.

- Smoke testing is considered to be one of the most effective ways that are used for the validation of the changes that are made to the software system or application program code at a high level before a detailed testing is undertaken on the new build. 

- Carrying out smoke tests can help a lot to stabilize the builds and verify that there are no major problems in the software system or application.

- The reliability factor of the smoke testing determines the success of the smoke test i.e., the more you can rely up on the smoke test for finding major problems, the more you can cut down the costs and increase the quality measures of the software product or artifact.

- Smoke testing provides a reliable, scalable solution that can be quickly and easily be automated. 

- One of the best things about automating the smoke test is that it does not require any programming.

- Smoke tests can be quickly written and automated by testers of any skill level within few minutes.

What functions are provided by the tools used for automating smoke tests?

There are so many tools available for automating the smoke tests. With these tools you can perform the following functions:

1. With these tools smoke tests can be written and automated within few minutes and without requiring any programming.
2. Using these tools all the builds can be validated before any changes are incorporated in to them.
3. These tools are quite helpful when it comes to stabilizing the whole build process and verifying the readiness of a build for further full scale QA testing.
4. With these tools quick tests can be conducted ensuring that the basic functionality is still intact and is working properly.
5. The overall quality of the product can be improved since the problems can be detected early.
6. Costs can be reduced ensuring that the team is having sufficient time for developing the product.

How a smoke test is automated?

- Smoke testing is usually preceded by quality assurance.

- As soon as the errors are discovered, it requires less efforts and money to get fixed.

-In automated smoke test, a continuous build process is deployed that automatically performs a smoke test each time a build is finished developing. 

- With such a methodology, the developers come to know easily if the recently developed build caused the problem. 

- Depending upon the configuration of the build tool and the software system or application, the process of implementing the automated smoke tests will vary despite of the basic steps being followed the same. 

- After the successful completion of the build, some set up steps are performed before the application is tested. The steps may include:

1. Copying files to the appropriate places.

2. Setting up the data base tables.

3. Starting a server.

4. Installing licenses.

- Next step is to obtain all the QA files required for the smoke test and running the smoke test. 

- The report of the smoke test is saved and final step involves clean up including the steps:

1. Stopping a server
2. Emptying data base tables and
3. Deleting files.

What ingredients are necessary to achieve component composition?

Component based software development or CBSD is nowadays becoming a very common practice when it comes to re- using the already existing practice components that have already been validated. This practice has shortened the development cycle gradually and has enhanced the quality of the software products or artifacts. This approach of software development is focussed up on the development of new software systems and applications through the selection and assembling components that belonged to the pre- existing software components. 

Furthermore, CBSD development methodology helps to:

1. Accelerates the productivity of the software development
2. Reduces the overall development cost
3. Reduces maintenance efforts
4. Enhances flexibility
5. Enhances maintainability
6. Assembles system rapidly
7. Reduces the time to market

Usually no wear and tear occurs to the software system but there is a need to change or modify the software in accordance with the changes in business needs and complexity. Since the system keeps on acquiring more and more complexity, and hence more and more errors are introduced. 

This whole concept of component based software development is based up on components and the success of this development approach is highly affected by the composition of the software components that are being used.

What is a Component?

- A component as we know can be defined as a re- usable unit of deployment which has its access through a graphical user interface. 

- Component can be thought of as an independent entity that possesses its own complete functionality that can be distributed separately and shows no problem in upgrading from time to time. 

- Certain standards have been defined according to which the components are developed and are re- used. 

- Smaller pieces of software are aggregated at a high level and this aggregation is what that forms a component.  

Types of ingredients in Component Based Software Development

1. An ideal component consists of the implementation detail obtained from the environment that can be re used by the interfaces of those components. This is essential as re- usability of the components is very much important for the component based software development.
2. The second most important ingredient is the service or functionality that is to be provided by the component.
3. Quality aspects like predictability, component reliability, usability and so on.
4. The composition of the components requires meta information regarding the interfaces of the components and properties so as to support the tools during the process of the component composition. This meta information is obtained from the implementation/ interface repositories, type libraries or introspection or dedicated info classes etc.

Different Means of Component Composition

- Though the implementation inheritance works for most of the object oriented frame works, it does not prove useful for the component composition.

- The composition of the components takes place on a binary level. 

- There are 4 means of component composition:

1. Scripting or glue languages
2. Component frame works
3. System languages
4. Visual programming

All the above mentioned means have their own advantages and disadvantages but, they all are considered to be useful when used in combination. 

- Mostly scripting languages like tcl, visual basic etc are used for component composition rather than using system languages like java, Pascal, C++ etc. 

- The scripting languages are found convenient for this purpose because they are intended for plugging components together operating on a high abstraction level as compared to the system languages. 

- The component composition requires an equivalent object oriented frame work called component frame work and in this the glue code between the classes is predefined for a specific application domain. 

What are different characteristics of build verification test?

Build verification test is often abbreviated as BVT and can be defined as a set of tests that are carried out on all the builds that are newly built in order to verify if those builds are testable or not before they are transferred to the testing team for their further testing. 

Generally, the test cases used in build verification test are considered to be the core functionality test cases which are used to keep the stability of the software systems or applications in check and regulate their testing thoroughly. 

The whole process of build verification test takes a whole lot of efforts and time if carried out manually and therefore the whole process is usually automated. If a build fails the build verification, then the same build is again returned to the developer to fix the faults. 

There are other names also by which the build verification test is known as mentioned below:

1. Smoke testing
2. Build acceptance testing or BAT

In a typical build verification test, there are two aspects that are exclusively tested and are mentioned below:

1. Build acceptance
2. Build validation

Few basics of Build Verification Tests

1. Build verification tests are a sub set of tests that are used for the verification of the main functionalities.
2. Some build verification tests are created on a daily basis and some builds are daily tested and if those builds fail the build verification test, they are rejected and returned back to their developer for making the fixes and when the fixes have been done, a new build is released and is gain subjected to the build verification test.
3. The build verification test has an advantage that it saves the precious efforts of the testing team that are required for setting up a test and testing a build whenever there is a break in the major functionality of the build.
4. The test cases of the build verification test should be designed very carefully so that they provide the maximum possible coverage to the basic functionality of the build.
5.  A typical build verification test is run for 30 minutes maximum and not then this limit.
6. The build verification testing can also be considered as a type of regression testing that is done on each and every build that is new.

Aim of Build Verification Test

- The primary aim of the build verification test is to keep a check on the integrity of the whole software system or application in terms of its build or we can say modules.

- When several development teams are working together on the same project, it is important that the modules that they are developing individually have got good ability for integrating with each other since this is very important. 

Till now so many cases have been recorded in which the whole project failed miserably due to a lack of integration among the modules. There are some worst cases also in which the whole project gets scraped just because of the failure in the module integration. 

- The build release has got a main task i.e., file check in i.e., including all the modified as well as new project files associated with the corresponding builds. 

- Earlier checking the health of the building initially was considered to be the main task of the build verification test. 

- This is called as “initial build health check” and it includes:

1. Whether or not all the files have been included in the release or not?
2. Whether all the files are in their proper format or not?
3. Whether all the file versions and languages have been included or not?
4. Whether the appropriate flags have been associated with the file or not?

What are the strengths and weaknesses of scrum?

Even though a lot of programmers and developers have been opting out for using scrum for the development of their projects, they had always faced some problems when implementing the scrum processes. These problems more or less are a consequence of the weaknesses of the scrum development method. 

However, in comparison to the weaknesses, the scrum has more number of strengths or plus points and this is what that makes the scrum so popular among the programmers and developers in spite of its weaknesses. 

According to a research, scrum was find to be weak in scrum training and certification. As we all know the scrum has always been looked up on as one of the best ways to implement the agile principles in the development process. All these modern agile software development processes like the waterfall, spiral and iterative models are quite different from the traditional approaches to software development. 

Problems and Misconceptions faced by Scrum Methodology

- One thing that really makes the scrum implementation weak is that programmers and developers think that implementing scrum itself is equal to agile implementation which is absolutely wrong! 

- Any software development process on a whole cannot be considered to be a complete agile process until and unless all the disciplines and rules of the agile management have been incorporated in to the development process.

- When one takes the scrum process to be equal to the agile process, then the agile disciplines go missing from the development process without the knowledge of the developer. 

- The developer thinks that he had implemented all the aspects of the agile management via the scrum which is a very false perception. 

- Many people do not understand that scrum is a software development process meant to achieve the goals of agility. 

- Scrum is a means and not a goal in itself. 

- Implementing the scrum without knowing about it in depth is like drawing up an empty process which takes you nowhere except that your time and efforts are wasted.

- When the scrum is simply thought of as a process so many formal activities that are carried out are a total waste. 

- There is another aspect to this weakness! This weakness in some cases becomes the strength of the scrum process making several problems visible to the developers. 

- But this is not the usual case since some developers may identify the problems found, themselves. 

- Plus if such problems are discovered during the implementation of the scrum then one more thing is obvious that the communication between the team members is not fluent and effective. 

Some developers and programmers may also blame the scrum for such problems. Here below we have summarized all the strengths and weaknesses of the scrum:

      

        1. Strengths:

a)  Encourages team work.

b)  Maintains transparency of the development process.

c)   Breaks down hierarchies.

d)  Keeps a focus on user features. (this is a weakness also in some cases)

e)  It is adaptive.

f)   Encourages visibility of the development.

      2.Weaknesses:

a)  Keeps a focus on user features: Focus on user features to some extent is ok but what if the process is totally in to it? A slow and clean approach always seems difficult to a team! Non functional requirements can be ignored since they don’t have any direct impact on the user.

b)   With scrum every team member needs to forget about his/ her area of expertise.

c)   Scrum is more useful to the companies that are product based rather than other aspects.

What are different Myths and Misconceptions surrounding Agile Model Driven Development (AMDD)?

The agile version of the model driven development or AMDD (agile model driven development) is now being recognized one of the most popular development models in the field of software engineering. This agile model driven development methodology was born out of a need of a combined development process of the agile methodology and the test driven development or TDD. 

The agile development in this combination is supposed to make the addressing of the cross entity issues easy while the TDD (test driven development) counterpart is suppose to focus exclusively on each and every individual entity of the software system or application. 

About Agile Model Driven Development

The agile model driven development lately has been known to suffer a lot of criticism giving way to the birth of several myths and misconceptions regarding it.

- The agile model driven development methodology has been characterized as an obsolete agile software development methodology to some extent though not so much. 

- The agile model driven development is thought to involve only a little bit of modeling but quite a lot of coding.

- The iterating efforts are deemed to be spread between the coding activities and the software modeling activities.

- Here a feel like illusion of majority of the designing being carried out as a part of the implementation efforts is created. 

- Such situations are also true for many other traditional software development methodologies. 

- In situations like this what happens is that the designers ultimately put the blame on the developers without questioning their own way of processing the software development.

- One of the misconception regarding the agile model driven development is that it does not specifies what all types of the software models are to be created.

- Even though it is always specified by the agile model driven development that only the right artifact is to be applied, it never does specify what that particular artifact really is. 

- One of the myths is that the agile model driven development works perfectly well with the UCDD (use case driven development) and the FDD (feature driven development). 

Myths and Misconceptions of Agile Model Driven Development

Below mentioned are some of the other myths and misconceptions surrounding the agile model driven development:

1. The agile models do not fulfill their purpose well.
2. It is very difficult to understand the agile models.
3. The agile models do not exhibit sufficient consistency.
4. The agile models are not sufficiently detailed.
5. The accuracy of the agile models is not so high.
6. The agile models exhibit a characteristic complexity.
7. Sometimes negative values are provided by the agile models.

Point of Argument

- Another most argued concept of agile model driven development is that the agile documents and models seem to be sufficient for carrying out the development.

- For this, the people develop false assumptions that the software is not as good as it portraits and expectations regarding the quality of the software artifact. 

- It is also thought that if the artifact has fulfilled the purpose which was intended then any more work that can be carried out on it is considered to be a useless bureaucracy. 

Benefits of Agile Model Driven Development

- The agile model driven development is known to take a more realistic approach and give a description of how the developers and stake holders are supposed to work together in cooperation to create good models.

- Agile model driven development is quite a flexible technology in the way that it allows the use most primitive and unsophisticated development tools for the creation of the models like papers and white boards as mentioned above.

- The agile model driven development is supposed to be independent of any sophisticated CASE tools even though they can be used effectively by the experts.