How do you modify and convert requirements in Test Director?

There is no doubt in the fact that one kicks off a testing process by inputting the specification of the requirements employing the requirements module of the test director. Requirements are a necessity in the testing process. Also, the foundation on which a testing team carries out the testing process is laid down by the requirements itself. The definition of the requirements is represented in the form of what is called a requirements tree. This is actually a graphical representation of the requirements as stated in the document view with the only difference being of hierarchical display. 

The requirements can be grouped as well as sorted out in a requirements tree. The following tasks can also be carried out:

1. Task allocation monitoring.
2. Monitoring the progress of the requirements.
3. Generation of the detailed graphs and reports.

Once the tests have been created in the test plan module they have to be linked to the corresponding requirements. 

Here in this article, we talk about the modification and conversion of the requirements in the test director. 

One can modify the requirements by following the below mentioned step sequence:

1. First, make sure that the requirements module is available on display. If in case it is not you need to open it using the requirements tab. Both the requirements tree as well as the document view will be displayed.
2. Your next step is to copy that particular requirement to which you want to make modifications from the requirements tree by clicking on the copy option. Next clicking on the paste option and you will get a warning saying that you are duplicating the requirement. Click OK and the requirement will be pasted in the same hierarchy level as that of the original requirement. Suffix _copy_ is added to the name of the requirement.
3. Next step, is to rename the requirement by following the usual procedure for renaming an object.
4. Next, move this requirement to a different location but in the same requirements tree. But the requirements should be pasted as child requirement. Click OK for confirmation and drag the requirement to any location you want in the requirements tree.
5. For deleting this requirement as well its child requirement use the delete option.

Once all the requirements have been created and defined, they can be used as a basis for providing definition of the test plan tree module. The conversion to test wizards can be used to get assistance for designing the test plan tree. Using this wizard you can convert the selected requirements from the requirement tree in to subjects or tests for the test plan tree.

Steps for conversion of Requirements

Now the below mentioned steps can be followed for the conversion of the requirements:

1. For the modification procedure make sure that the requirements is up for display and if it is not there do so by clicking on the requirements tab.
2. From the various requirements in the requirements tree select the one which you want to be converted.
3. Now launch the convert to tests wizard from the tool menu and from that click on ‘convert selected’ option.
4. You can go for the automatic conversion method by taking second option i.e., ‘convert lowest child requirements to tests’ for the conversion of the selected requirements in to tests.
5. Now clicking on the next button will start the conversion process and after the conversion the results will be displayed in the step 2 dialog box. 

What are basic practices of iterative development?

So many software development processes have come up with the specifications and benefits of their own. The iterative development is one such development strategy which has been identified as an agile software development process. 

The basic practices of the iterative development have been discussed here. But, before moving on to the approaches will have brief discussion regarding the iterative development.The iterative part forms the first half of the heart of the cyclic software development process with the other half being formed by the incremental development. 

The iterative development strategy was the resultant of the response to the weaknesses spotted in the water fall model of the software development and testing. Like any other cyclic software development process, the iterative development process also has its starting with an initial planning and ends up with deployment and it has so many cyclic interactions happening in between the ned points. 

The iterative development process forms an important and non neglect-able part of the following processes;

1. Rational unified process or RUP
2. Extreme programming or XP and
3. Various other agile software development methods

The idea of a simple business process improvement has been implemented in the iterative development which has its flow like as shown below:

Plan à DO à Check à Act

What is meant by Iterative Development?

- Iterative development is itself an agile software development strategy which has its basic idea revolving around the use of the iterations in smaller intervals of time called the incremental.

- This agile software development strategy helps the testers and the developers to exercise their past experience of the learning in to the current testing scenario.

- With every new iteration, the design of the software system or application is modified and is incorporated with some new functionalities or features. 

- The procedure for the iterative development process consists of the following steps:

1. The Initialization step
2. The iteration step and
3. Project control list

- The first step i.e., in the initialization step involves the building up of the foundation or the base version of the proposed software system or application.

- Actually, a base version is created so that the user can react with the software product and also to have a key sample of the problems of the software system or application and also possible solutions that are easy to understand and implement.

- The control list contains all the tasks that have to be performed in order to complete the software development process. 

- As the analyzation phase progresses, the project control is also revised timely and frequently as and when any change in the requirements is wanted.

- With every iteration, a task from the project control list is accomplished or redesigned. 

- The below mentioned are some of the goals of the iterative development process:

1. Simplicity
2. Straight forward
3. Modular
4. Redesigning supportive at that particular stage etc.

- Every iteration is analysed on the basis of the below mentioned factors:

1. Structure of the iteration
2. Modularity
3. Usability
4. Reliability
5. Achievement of goals and
6. Efficiency

Based on the results of the above factors, the project control list is modified accordingly.

Phases of Iterative Development

 The whole iterative development consists of the following 4 phases:

1. Inception phase: It involves identification of the project scope, risks and both the functional as well the non functional requirements.
2. Elaboration phase: It involves the delivery of a working architecture fulfilling all the requirements and mitigation of the top risks.
3. Construction phase: It involves implementing the production ready code in to the architecture.
4. Transition phase: It involves delivery of the project in to the production environment.

How does a definition clear path play a role in data flow testing?

Definition clear path is a quite less heard term! This article is focussed up on the concept of definition clear path and what role do it plays in the data flow testing. First let us define what is a definition clear path in actual. 

"A definition clear path as it can made out from the term itself that it is a path through which other variables cannot be defined or through which other variable definitions cannot be made."

To make the meaning of definition clear path clearer we shall look up to an example:

- Suppose X be a variable declared or appearing in a software program or procedure. 

- Suppose there is a path $which\; do\; not\; contain\; any\; nodes\; with\; definition\; of\; the\; variable\; X.$

- Such a path not containing any variable definitions has been termed as a definition clear path. 

We can now define this definition clear path as a path between the two nodes namely A and B, with X being defined in A and an use in node B and there exists no other definition of variable X between the two nodes present in the path. 

Let us see another example to explore another type of definition clear path that can exist. 

- Suppose the above same variable X be defined at a node A along with an use defined at the another node B.

- Suppose the path formed by these two nodes A and B does not appears in the sub path, then such a path is also defined as a definition clear path for the X variable defined by the nodes A and B if the variable X is not defined in the sub path. 

- There is another common name for the definition clear path which is “def- clear path”. 

Now let us talk about the role that the definition clear path plays in the data flow testing. Actually in the data flow testing, there are three types of coverage that have to be provided namely:

1. Statement coverage
2. Branch coverage and lastly
3. Path coverage

Basically problems are faced with the path selection process. A definition of the variable X reaches a use if and only if there exists a sub path such that the sub path is a definition clear path with respect to the variable X. The path selection in the data flow testing is based up on the two criteria:

1. Rapps and Weyuker criteria: Under these criteria the definition clear sub paths from definitions to uses are listed.
2. Laski and Korel criteria: Under these criteria the various combinations that reach uses at a node via some sub path are listed.

How does Definition Clear Path play a role in Data Flow Testing?

- Definition clear paths have been known to make remarkable improvements in the control flow techniques for data flow testing.

- A rational is obtained for which there is a need to take in to consideration all the combinations of the sub paths. 

- The “all uses” is the most commonly preferred criteria.

- There are some paths in a program that are infeasible and it is these paths that pose a big problem in the data flow testing. 

- The path testing strategies are based up on the data flow anomalies. 

- Enough paths are required to be tested so that it is ensured that every object in the program has been initialized before use and have been used at least once during the program execution. 

- For a complete data flow testing it is required that definition clear paths are executed by the test cases from each node that contains a defined variable.

What is a template for a test plan?

Testing is responsible for checking the quality level of a program and effective testing requires an effective and efficient test plan.

HOW SHOULD A TEST PLAN BE?
- The test plan should be practical so that it can be easily implemented.
- A test plan is prepared keeping in view the test approach which is suitable for a particular kind of software testing.
- The other important things that are kept in mind while drawing out the test plan are functional specs, design specs and requirements.
- The test plan is a way of implementing the test approach.
- It makes use of test cases specifically designed for a kind of particular testing.

DOCUMENTATION OF TEST PLAN
The test plan is also documented and the documentation serves the following purposes:

1. It gives the details about the test approach used to test the software system or application.
2. The different aspects of a software system or application are identified.
3. The procedure to be followed for the testing is specified.
4. The tools to be used in the software testing are also mentioned in the documentation.
5. The resources to be used in the testing of the software product are specified.
6. The scheduling plan for the test plan is listed.
7. Sometimes it may also include the contact information of the people who are involved in the whole testing process.
8. It lists all the risks that may affect the software and also mentions their effect on the software.
9. The contingency plan is also included.
10.The test plan also specifies the bugs and errors and procedures to manage them.
11.The criterion for the development of the software is specified.

The scheduling plan or the test schedule is prepared by the lead tester. It is based up on the project schedule prepared by the product manager. A test plan template is like a sample on which you can build up your own test plan.

BASIC TEST SAMPLE
1. Introduction
The introduction part covers up the description of the documentation, schedules and other related documents.
(a) Description:
- This documentation contains a test plan for the project: “project name” which has been produced by both quality control and quality assurance.
- The test plan enlists and describes the test strategy and also the test approach.
- Quality assurance has been used for validating the quality of this software product prior to its release.
- Apart from software product, there are other resources which are required for successful execution of this software project.
- The “ project name” aims at improving the development strategy, maintenance and deployment by providing the following new features:

(b) Schedule: (schedule coverage and information based on the estimates of the quality assurance.)
(c) Related documents: (related documents attached to the documentation like design specifications list and functional and non functional specifications list.)

2. Resource Requirements:
It describes all the hardware and software components of the software product.
(a) Hardware:(hardware requirements of the project)
(b) Software:(software requirements of the project and tools used in the testing of the software)
(c) Staffing:(list of the names of the people who are involved in the project along with their responsibilities and what all trainings are required.)

3. Aspects to be tested and test approach: (provides the list of the aspects tested).
4. Aspects not to be tested.
5. Test outcomes
6. Risks
7. Exit criteria

What are different rules of thumb to write good test cases?

Writing good and effective test cases requires great skills since after all effective testing is achieved by effective test cases only!

Writing such test cases is a great skill in itself and can only be achieved by in depth knowledge of the software system or application on which the tests are being carried out and it also requires some experience.

Here I’m going to share some rules of thumb to write effective test cases, basic test cases definition and test case procedures.

What is a test case actually?
A typical test case is comprised of components that are meant to describe an action or event, input and an expected outcome in order to determine whether the software system or application is working as it is meant to or not.

Before writing a test case you should know the 4 levels or categories of the test cases to avoid their duplication.
The levels have been discussed below:

Level 1:
This level involves writing of basic test cases using the available specifications and requirements and documentation provided by the client.

Level 2:
This level is the practical stage and it involves writing of test cases based on the actual system flow and functional routines of the software system or application.

Level 3:
This level involves grouping of some particular test cases. Some test cases are grouped together and a test procedure is written. A test procedure can have maximum up to 10 test cases.

Level 4:
This level involves the automation of the project. This leads to minimization of the human’s interaction with software system or application. This is done basically to maximize the focus upon the currently updated functionality to be tested rather than focusing on regression testing.

Following this whole pattern you can have an automated testing suite from no testable item, i.e., you can observe a systematic growth.
- The tester should know the objective of each and every particular test case.
- The basic objective of all the test cases is to validate the testing coverage of the software system or application.
- You need to strictly follow test cases standards. Writing test cases reduces the chances of following an ad- hoc approach.

Below given is a basic test case format:
- Test case id
- Units to be tested
- Assumptions
- Input /test data
- Execution steps
- Expected outcome
- Actual outcome
- Success or failure
- Observation
- Comments

You need to write a test case statement also. So here’s the basic format:

- Verify:
This is the first word of the test case statement.
- Using tool names, tag names, dialogues etc: this is basically to identify what is being tested.
- Verification with conditions.
- Verification to result.

For any kind of testing:

- You will cover all types of tests like functional test cases, negative value test cases and boundary value test cases.
- Be careful while writing the test cases.
- Keep it simple and easy to understand.
- Don’t write test case statements with the length of an essay.
- Keep it brief and to the point.
- Follow the test cases and test case statements formats stated above.
- Generally spreadsheets are used to write test cases which make them more presentable and easy to understand.
- You can use tools like “test director” when you want to automate the test cases.
- Writing clear and concise test cases forms an important part of software quality assurance.
- Also be careful that a good number of test cases cover functional testing which means that the primary focus is on how the feature works.

What are different characteristics of destructive testing?

Nothing checks the robustness of a software system or application better than destructive testing.
- Destructive testing is basically to determine the robustness of a software system or application.
- In order to determine the robustness of a software system or application, it is subjected to very harsh tests and attempts are made to make the program crash or hang.
- The aim of the destructive testing is to cause the failure of the program.
- The destructive testing has a typical process procedure. The process has the following aspects:

Waterfall development model or CMMI traditional model

- It is always been a common practice of performing software testing on software system by an independent group of software testers after the functionalities of the software system have been fully developed. D
- Destructive testing is carried out before it is delivered to the client or the customer.
- In this kind of practice, the testing stage is also used as a project buffer in order to compensate for project delays.
- But, this results in compromising with the time being consumed for testing.
- In the same model, there is another testing in which the software testing is started simultaneously with the start of the project and it is continued as a regular process until the project is finished.

Extreme development model or Agile model

- The extreme development model and the agile software development model follow the test driven software development model.
- Following this procedure, unit tests are carried out first by the software developers or engineers.
- These unit tests fail initially and this is expected also.
- As the code is written and subjected to these tests, more and more units of the software system pass those unit tests successfully.
- The test cases being used in the testing are updated regularly for the new faults and errors discovered.
- The tests cases thus updated are also made more efficient with the addition of the regression tests developed during the whole process.
- Unit tests are carried out simultaneously with the development and progress of the source code.
- They eventually become an integral part of the build process.
- This model aims at achieving continuous deployment i.e., to say that the software updates can be easily released for the public.

Although there exist some variations between the different models of testing, the testing cycle is typical and same for every kind of model. The following steps are involved in the testing cycle:

- Requirement analysis
- Test planning
- Test development
- Test execution
- Test reporting
- Test result analysis
- Defect retesting
- Regression testing
- Test closure

What are different characteristics of visual testing?

Visual testing is a frequently used testing technique for testing software. But, what it is actually?

Visual testing technique is categorized under non destructive testing. Non destructive testing includes several other techniques. As the name suggests, non destructive testing techniques do not involve vigorous checking of the software structure and so does visual testing or “VT” as it is abbreviated and commonly used.

Visual testing itself suggests that it has everything to do with visual examination of the program or the source code. Anything which is to be tested is first examined visually. Later the operations are carried out. Similarly for software systems and programs also the same procedure is used. They are first checked visually and later they are tested with white box testing or black box testing etc. even though visual testing sounds like an unsophisticated method of testing, it is quite effective.

Many errors and flaws in the source code and programs can be spotted during visual testing. It is more effective when a large number of professionals carry out the visual examination. Visual checks how sound the program or the software application is before it is brought in use.Visual testing sounds very simple but, it requires quite a lot of knowledge.Even though it is very primitive kind of testing it has got a lot of advantages.

Few have been listed below:

- Simplicity
Visual testing is very easy to carry out. One doesn’t require any complex techniques or software.

- Rapidity
Apart from being simple, it is faster in process when compared to other kinds of testing techniques. One doesn’t require any extra efforts.

- Low cost
Visual testing is priced very low. You are charged only for hiring professionals to examine your software and nothing else. If it was to be tested by the writer itself, then it would have been absolutely no cost.

- Minimal training
The individuals or the professionals testing the software visually need minimal training just enough to spot big blunders in the program.

- Equipment requirement
It requires no special equipment.

Visual testing can be performed almost anytime. You can visually examine a program simultaneously while making some modifications or manipulating or executing the program.

In contrast to these advantages there are limitations to visual testing. They have been discussed below:

- Visual testing can detect only the mistakes that appear on the surface of the program. It cannot discover the discrepancies hidden in the internal structure of the program.
- The quality of visual testing also depends on the resolution of the eyes of the tester.
- Extent of visual testing depends on the fatigue of the person who’s inspecting. Due to prolonged testing, the examiner may start getting headaches and pain in the eyes.
- Also during visual examination there’s a lot of distraction due to surrounding environment. It impossible for a person to devote himself entirely to the visual testing without paying attention to what’s happening around him.

Visual testing holds good when it comes to checking the size or length of the program, to determine its completeness, to make sure the correct number of units or modules are there in the program, and to inspect the format of the program; basically to ensure that the presentation of the program is good.

Visual testing spots the big mistakes. They can be corrected at a very low level of testing and this in turn reduces the future workload. Requirements include:
- A vision test of the inspector
- Measurement of light with a light meter.

The inspector only needs to set up a visual contact with the part of the program that is to be tested.Visual testing also gives an idea on how to make a program better.

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation

The Art of Unit Testing: With Examples in .Net

Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing

Mission of testing and what are the situations where exploratory testing can be practiced?

The goal of testing needs to be understood first before the work begins. This could be the overall mission of the test project or could be a particular functionality or scenario. The mission is achieved by asking the right questions about the product, designing tests to answer these questions and executing tests to get the answers. Quite often, the tests do not completely answer. In such cases, we need to explore. The test procedure is recorded and the result status too.

The tester also needs to have a general plan in mind, though may not be very constrained. The tester needs to have the ability to design good test strategy, execute good tests, find important problems and report them. Out of box thinking is necessary.

The time available for testing is a critical factor. Time falls short due to following reasons:
- In a project life cycles, the time and resources required in creating the test strategy, test plan and design, execution and reporting is overlooked. Exploratory testing becomes useful since the test plan, design and execution happen together.
- Time falls short when testing is essential on a short period of notice.
- Time falls short when a new feature is implemented.
- Time falls short when change request come in much later stage of the cycle when much of the testing is done.

In such situations, exploratory testing becomes very useful. A basic strategy of exploratory testing is to have a general plan of attack but also allows yourself to deviate from it in a short period of time. In a session of exploratory testing, a set of test ideas, written notes and bug reports are the results. This can be reviewed by the test lead or a test manager.
- It is very important to identify the test strategy and the scope of the test carried. It is dependent on the project approach to testing.
- The tester crafts the test by systematically exploring the product. He defines his approach, analyze the product, and evaluate the risk.
- The written notes and scripts of the tester are reviewed by the test lead or manager.