SOFTWARE TESTING MATRICES PART TWO

Going through TESTING MATRICES PART ONE will give better understanding of this concept.

Cascading Test Matrices

The tests that occur on functional events vary based on the events themselves. If generic actions are used, it may be possible to include several functional events in the same matrix.

However, it is generally better to limit a matrix to a single functional event.

Including only one functional event on a matrix provides the following two advantages:

1• Tests can be customized for specific functional events.

2• Tests on the functional events can be the creation of new functional events which show a relationship between the events.

One functional event leading to the creation of another and leading to another will cause several matrices to be prepared. Properly prepared, they will demonstrate the cascading events illustrating how one event can create another event which can create yet another event.

An example of a cascading matrix is illustrated in the figure . This matrix is from an order entry billing system.

Click the picture for brooder view.


The first functional event is the order for a product placed by a customer. The type of actions that would occur on this is the initiation of the order, the acceptance of the order, the entry of the order, and the credit approval action.

That action creates a new functional event which is the formal approval of customer credit. The figure shows how the action in the first matrix cascades or points to the second matrix.

The tests for the functional event of approving credit involves such tasks as determining that the customer is an authorized customer, causing a decision about the customer’s credit.

If good action occurs, it creates a new functional event to ship a product. The figure shows how the action to ship a product creates a new functional event and a new matrix. This process would continue until the entire order entry billing application was complete.

In the creation of the test plan, IT people sometimes lose track of the interrelationship of functional events. The creation of the cascading test matrix reinforces the interrelationship of functional events and enables that aspect of systems to be better tested.

The coming post is regarding independent testing.

Life cycle testing
can be understood in detail here.

The complete testing course can be browsed for further reference.



To Do Next: Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .

TESTING METRICES

The test matrix shows the interrelationship between functional events and tests. The completed test matrix defines the conditions that must be tested during the test process to verify the proper functioning of the application system. It does not represent the totality of testing because there may be types of tests that verify the structure of the system, such as verifying the correct use of program statements that are not included in the test matrix.

The left side of the matrix shows the functional events and the top identifies the tests that occur on those events. Within the matrix cells are the process that needs to be tested. During requirements, the process may be generalized and vague, but it must become more specific as the life cycle progresses.

The example illustrated in Figure is for the functional event of an employee getting a pay increase. The tests have been selected because each test:

  1. Represents the actions that must be performed on this functional event in order for the employee to get a raise .
  2. Represents a task that is performed individually.
  3. Can be associated with the individual responsible to perform that action.
  4. Is broad enough to limit the actions to a reasonable number .
Click the figure to enlarge.


In the figure example there are nine identified conditions that must be tested to determine whether or not employees’ pay increases are processed correctly by the application system.

Let’s examine the nine tests to illustrate the conditions that must be tested:

1 • Initiate Event Action

This action creates the functional event which will eventually give an employee a pay raise. Within the matrix is the process that needs to be evaluated. The process is for the supervisor to complete Form X. The information on the matrix must be condensed. If we were working with the application we would know, for example, that Form X was the organizational form for initiating a pay increase.

2 • Increase Approved Action

After the supervisor has completed the form it must be approved by management. The test condition indicates that management will initial Form X. Our test process or test condition would then be designed to verify that procedures are established so that this will happen. Note that this and the previous action are manual actions.

3 • Data Entry Action

The information on Form X is entered into the computer through a key entry process.The test condition is to verify that the keyed information is correct. Since this is in the early life cycle stages, we may not know all of the detailed information that will be keyed in or the verification process, but even in requirements we could substantiate that the requirements include a process to verify the accurate entry of data into the computer.

4 • Form Storage Action

Form X needs to be retained until it is no longer of value to the organization. The test condition states that the form should be stored for 90 days in the personnel department. Again, our test process would verify that this is reasonable and that the system process provides for this condition.

5 • Data Entry Validation Action

The verification that the information entered into the computer is correct. The test conditions outlined in the matrix state that the application system should validate that the pay increase amount is numeric, and that the increase is less than $100.

6 • Logical Validation Action

The test suggests that additional validation determination will be made beyond the data values. Three test conditions are outlined as: 1) a logical check that the employee exists, 2) the pay increase will be within the pay range the employee is authorized, and 3) that the pay increase is within plus or minus 15 percent of the amount the employee was earning prior to the increase.

7 • Updated Pay Record Action

The pay amount increase should be added to the employee’s pay rate so that the pay record will properly reflect the new amount. The test condition is to ensure that the changed pay rate amount in the storage area is performed correctly.

8 • Audit Trail Action

A record should be maintained on the increases provided the employee. The action shows that the increase in payroll should be maintained on a history file.

9 • Report Action
The results of computer processing should be sent back to the supervisor as a confirmation process. The test condition is to verify that the system provides for such a confirmation.

This testing matrix would be typical of one prepared during the requirements phase. The functional events, as well as the actions, will be used throughout the systems development life cycle.

However, the test conditions will become more specific as the life cycle progresses. For example, there is an action indicating that data will be entered into the computer. During requirements, how that will occur may not be known, so that the test condition must still be generalized as Figure Testing Matrix shows. However, as the system progresses through the life cycle, the testing matrix becomes more specific. Eventually, the testing matrix will be expanded to the point where test transactions can be prepared from the matrix information.


SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE

WHY SHALL WE TEST A SOFTWARE PRODUCT ?

TESTABILITY OF A SOFTWARE

APPROACHES TO SOFTWARE TESTING

TESTING STRATEGIES


ORGANIZING SOFTWARE TESTING

TESTING COMPLETION CRITERIA

SOFTWARE DEVELOPMENT PROCESS

SOFTWARE DEVELOPMENT LIFE CYCLE

PROJECT MANAGEMENT AND SOFTWARE TESTING

ECONOMICS OF SOFTWARE TESTING

DIFFERENT TEST LEVELS

TESTING TECHNIQUES

SPECIAL TEST TYPES


TESTING STANDARDS

ISO STANDARDS OF TESTING

TESTING PROCESS

TESTING PROCESS PART TWO

Life cycle Teting

Life cycle testing involves continuous testing of the solution even after software plans are complete and the tested system is implemented. At several points during the development process, the test team should test the system in order to identify defects at the earliest possible
point.

It testing cannot occur until you formally develop your process. IT must provide and agree to a strict schedule for completing various phases of the process for proper life cycle testing to occur. If IT does not determine the order in which they deliver completed pieces of software, it’s impossible to schedule and conduct appropriate tests.

It testing is best accomplished by forming a test team. The team is composed of project members responsible for testing the system. They must use structured methodologies when testing; they should not use the same methodology for testing that they used for developing the system.

The effectiveness of the test team depends on developing the system under one methodology and testing it under another. The life cycle testing concept is illustrated in Figure.


It shows that when the project starts, both the development process and system test process also begin. Thus, the testing and implementation teams begin their work at the same time and with the same information.

The development team defines and documents the requirements for implementation purposes, and the test team uses those requirements for the purpose of testing the system. At appropriate points during the development process the test team runs the compliance process to uncover defects. The test team should use the structured testing techniques a basis of evaluating the corrections.

As you’re testing the implementation, prepare a series of tests that your dept can run periodically after your revised system goes live. Testing does not stop once you’ve completely implemented your system; it must continue until you replace or update it again!


SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE

WHY SHALL WE TEST A SOFTWARE PRODUCT ?

TESTABILITY OF A SOFTWARE

APPROACHES TO SOFTWARE TESTING

TESTING STRATEGIES


ORGANIZING SOFTWARE TESTING

TESTING COMPLETION CRITERIA

SOFTWARE DEVELOPMENT PROCESS

SOFTWARE DEVELOPMENT LIFE CYCLE

PROJECT MANAGEMENT AND SOFTWARE TESTING

ECONOMICS OF SOFTWARE TESTING

DIFFERENT TEST LEVELS

TESTING TECHNIQUES

SPECIAL TEST TYPES


TESTING STANDARDS

ISO STANDARDS OF TESTING

TESTING PROCESS

TESTING PROCESS PART TWO

TESTING COMPLETE COURSE ADVANCED TOPICS

Here is the good list of all advanced topics of software testing with full length concepts.

If you are new to software testing you can consider the basics of it with SOFTWARE TESTING COMPLETE COURSE.

Your feed back regarding this topics are most welcome.

Here is the list of testing advanced topics subject wise and i will keep this list updating.

Thank you for being here.


UNIT TESTING


UNIT TESTING PART ONE

UNIT TESTING PART TWO

UNIT TESTING PART THREE

GUI TESTING

WINDOWS COMPLIANCE GUI TESTING PART ONE

WINDOWS COMPLIANCE GUI TESTING PART TWO

WINDOWS COMPLIANCE GUI TESTING PART THREE

WINDOWS COMPLIANCE GUI TESTING PART FOUR VALIDATION TESTING

WINDOWS COMPLIANCE GUI TESTING PART FIVE CONDITION TESTING

WINDOWS COMPLIANCE GUI TESTING PART SIX GENERAL CONDITION TESTING

CONDITION TESTING

TESTING CONDITIONS PART ONE

TESTING CONDITIONS PART TWO

TESTING CONDITIONS PART THREE

TESTING CONDITIONS PART FOUR

SPECIFIC FIELD TESTING

USABILITY TESTING

INTEGRATION TESTING

INTEGRATION TESTING PART ONE

INTEGRATION TESTING PART TWO

INTEGRATION TESTING PART THREE

INTEGRATION TESTING PART FOUR

INTEGRATION TESTING PART FIVE

INTEGRATION TEST STANDARDS

INTEGRATION TEST STANDARDS PART TWO

QUALITY TESTING

QUALITY ASSURANCE

QUALITY ASSURANCE PART TWO

QUALITY ASSURANCE SQA

QUALITY OF DESIGN OF TEST CASE

QUALITY MANAGEMENT IN SOFTWARE TESTING

TOOLS FOR QUALITY MANAGEMENT

STATICAL QUALITY ASSURANCE

ISO APPROACH TO QUALITY TESTING

TEST CASE DESIGN

TEST CASE DESIGN

TEST CASE DESIGN TWO

DESIGN OF TEST CASES PART THREE

TEST CASE DESIGN PART THREE

TEST CASE DESIGN PART FOUR

TEST CASE DESIGN PART FIVE

TEST CASE DESIGN PART SIX

TEST CASE DESIGN PART SEVEN

TEST CASE DESIGN PART EIGHT

TEST CASE DESIGN PART NINE

REVIEWS AND APPROVAL OF TEST CASES

WRITING SOFTWARE TEST CASES PART ONE

WRITING SOFTWARE TEST CASES PART TWO

WRITING SOFTWARE TEST CASES PART THREE

WRITING SOFTWARE TEST CASES PART FOUR

BOX TESTING

WHITE BOX TESTING

WHITE BOX TESTING PART TWO

WHITE BOX TESTING PART THREE

WHITE BOX BASIC PATH TESTING

BLACK BOX TESTING PART ONE

BLACK BOX TESTING PART TWO


AUTOMATION IN TESTING

AUTOMATED TESTING TOOLS

AUTOMATED TESTING ANALYSIS

AUTOMATION BEST PRACTICES

AUTOMATED TESTING PROCESS

CHECK POINTS IN AUTOMATED TESTING

SILK TEST

SILK TEST INTRODUCTION

FEATURES OF SILK TEST

FEATURES OF SILK TEST PART TWO

LIMITATIONS

TEST PLAN FOR SILK TEST

INSTALLATION TIPS FOR SILK TEST

TEST CASES IN SILK TEST


To Do Next: Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .


C Programming Rules

The following rules that are applicable to all C programs:

1. Each instruction in a C program is written as a separate statement. Therefore a complete C program would comprise of a series of statements.

2. The statements in a program must appear in the same order in which we wish them to be executed; unless of course the logic of the problem demands a deliberate ‘jump’ or transfer of control to a statement, which is out of sequence.

3.Blank spaces may be inserted between two words to improve the readability of the statement. However, no blank spaces are allowed within keyword.

4. All statements are entered in small case letters.

5. C has no specific rules for the position at which a statement is to be written.

6. Every C statement must end with a ;. Thus ; acts as a statement terminator.

7. Comment about the program should be enclosed within /* */.

For example, the first two statements in our program are comments.

8. Though comments are not necessary, it is a good practice to begin a program with a comment indicating the purpose of the program, its author and the date on which the program was written.

9. Any number of comments can be written at any place in the program. For example, a comment can be written before the statement, after the statement or within the statement as shown below:

/* formula */ si = p * n * r / 100 ; si = p * n * r / 100 ;

/* formula */ si = p * n * r / /* formula */ 100 ;

10. Sometimes it is not so obvious as to what a particular statement in a program accomplishes. At such times it is worthwhile mentioning the purpose of the statement (or a set of statements) using a comment.

For example:

/* formula for simple interest */

si = p * n * r / 100 ;

11. Often programmers seem to ignore writing of comments. But when a team is building big software well commented code is almost essential for other team members to understand it.

12. Although a lot of comments are probably not necessary in this program, it is usually the case that programmers tend to use too few comments rather than too many. An adequate number of comments can save hours of misery and suffering when you later try to figure out what the program does.

13. The normal language rules do not apply to text written within /* .. */. Thus we can type this text in small case, capital or a combination. This is because the comments are solely given for the understanding of the programmer or the fellow programmers and are completely ignored by the compiler.

14. Comments cannot be nested.

/* Cal of SI /* Author sam date 01/01/2002 */ */ is invalid.

15. A comment can be split over more than one line, as in,

/* This is a
multi
comment */

Such a comment is often called a multi-line comment.

SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE

WHY SHALL WE TEST A SOFTWARE PRODUCT ?

TESTABILITY OF A SOFTWARE

APPROACHES TO SOFTWARE TESTING

TESTING STRATEGIES


ORGANIZING SOFTWARE TESTING

TESTING COMPLETION CRITERIA

SOFTWARE DEVELOPMENT PROCESS

SOFTWARE DEVELOPMENT LIFE CYCLE

PROJECT MANAGEMENT AND SOFTWARE TESTING

ECONOMICS OF SOFTWARE TESTING

DIFFERENT TEST LEVELS

TESTING TECHNIQUES

SPECIAL TEST TYPES


TESTING STANDARDS

ISO STANDARDS OF TESTING

TESTING PROCESS

TESTING PROCESS PART TWO

PROGRAMMING WITH C COMPLETE COURSE

INTRODUCTION TO C PROGRAMMING

Programming with C an introduction part two

Data types for C programming


C PROGRAMMING CHARACTER SET

CONSTANTS IN C PROGRAMMING

PROGRAMMING C VARIABLES

C PROGRAM INSTRUCTIONS

COMPILATION AND EXECUTION OF C PROGRAM

C PROGRAMMING RULES PART ONE

C PROGRAMMING RULES PART TWO

COMPILATION AND EXECUTION OF C PROGRAM

INSTRUCTIONS TO WRITE C PROGRAM

ARITHMETIC INSTRUCTIONS TO WRITE C PROGRAM

CONVERSION OF CONSTANTS IN C PROGRAM

PRIORITY OF AR THEMATIC OPERATIONS IN C

OPERATORS ASSOCIATIVITY IN C

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE


BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING


Functions and usage in C part two

Coding in C functions


OTHER PROGRAMMING COURSES:

Dot Net Complete Course Part one and two

ASP.NET part one and two

Programming with C and C Sharp

Interview Questions in dot net

asp.net part one part two

Software Testing Complete course part one two and Interview Questions

SOFTWARE TESTING COMPLETE COURSE

Hi every one ,

This blog covers the programming aspects of MICROSOFT DOT NET,JAVA,C,C++ and SOFTWARE TESTING.

The subject software testing is covered here extensively and here are the links where you have to start learning.

SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO


DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique


Operation testing technique


Compliance software testing technique

Security testing technique
Here i am adding the further topics list on software testing subject and the topics may be scattered and you can find under different groups.

MAJOR SYSTEM FAILURES IN THE HISTORY

WHAT IS A SOFTWARE BUG ?

ROLE OF A TESTER

SOFTWARE TESTING INTRODUCTION PART ONE

TESTING INTRODUCTION PART TWO

TESTING INTRODUCTION PART THREE

TESTING INTRODUCTIONS PART FOUR

SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE

WHY SHALL WE TEST A SOFTWARE PRODUCT ?

TESTABILITY OF A SOFTWARE

APPROACHES TO SOFTWARE TESTING

TESTING STRATEGIES


ORGANIZING SOFTWARE TESTING

TESTING COMPLETION CRITERIA

SOFTWARE DEVELOPMENT PROCESS

SOFTWARE DEVELOPMENT LIFE CYCLE

PROJECT MANAGEMENT AND SOFTWARE TESTING

ECONOMICS OF SOFTWARE TESTING

DIFFERENT TEST LEVELS

TESTING TECHNIQUES

SPECIAL TEST TYPES


TESTING STANDARDS

ISO STANDARDS OF TESTING

TESTING PROCESS

TESTING PROCESS PART TWO

TESTING PROCESS PART THREE

WHAT TEST PLAN SHALL HAVE ?

SOFTWARE RELIABILITY

TEST DESIGN

DEFECT CLASSIFICATION

DEFECT TRACKING

TEST METRICS

TEST REPORTS

CHANGE REQUEST MANAGEMENT

UNIT TEST SPECIFICATIONS

UNIT TEST SPECIFICATIONS PART TWO

FUNCTIONAL FLOW MATRIX PART ONE

FUNCTIONAL FLOW MATRIX PART TWO

PROGRAM INSPECTION AND REVIEWS

CODE INSPECTION IN SOFTWARE TESTING

ERROR CHECK LIST FOR INSPECTIONS

WALK THROUGHS IN TESTING

TESTING FOR SPECIALIZED ENVIRONMENTS PART ONE

TESTING FOR SPECIALIZED ENVIRONMENTS PART TWO

VALIDATION TESTING

SYSTEM TESTING


DEBUGGING AND TESTING

DEFECT AMPLIFICATION AND REMOVAL

ITERATIVE SPIRAL MODEL

STANDARD WATER MODEL

CONFIGURATION MANAGEMENT


CONTROLLED TESTING ENVIRONMENT

RISK ANALYSIS PART ONE


RISK ANALYSIS PART TWO

BACK GROUND ISSUES

SOFTWARE REVIEWS PART ONE

SOFTWARE REVIEWS PART TWO

SOFTWARE RELIABILITY

SAFETY ASPECTS

MISTAKE PROOFING

SCRIPT ENVIRONMENT

V MODEL IN TESTING

You can go through TESTING ADVANCED TOPICS LIST HERE.

To Do Next: Thank you for visiting PROGRAMMING BLOG. If you liked the post, please subscribe to my blog via email or RSS FEED.You can contact me here for any specific feed back .


Testing Software and constraints part two

Lacking or Poorly Written Requirements

If needs are lacking or poorly written, then the test team must have a defined method for uncovering and defining test objectives.

A test objective is simply a testing “goal.” It is a statement of what the test team or tester is expected to accomplish or validate during a specific testing activity. Test objectives, usually defined by the test manager or test team leader during requirements analysis, guide the development of test cases, test scripts, and test data.

Test objectives enable the test manager and project manager to gauge testing progress and success, and enhance communication both within and outside the project team by defining the scope of the testing effort.

Each test objective should contain a statement of the objective, and a high-level description of the expected results stated in measurable terms. The users and project team must prioritize the test objectives. Usually the highest priority is assigned to objectives that validate high priority or high-risk requirements defined for the project. In cases where test time is cut short, test cases supporting the highest priority objectives would be executed first.

Test objectives can be easily derived from using the system requirements documentation, the test strategy, the outcome of the risk assessment, and the test team assignments. A few techniques for uncovering and defining test objectives if the requirements are poorly written include brainstorming and relating test objectives to the system inputs, events, or system outputs.

Ideally, there should be less than 100 test objectives for all but the very largest systems. Test objectives are not simply a restatement of the system’s requirements, but the actual way the system will be tested to assure that the system objective has been met.

Completion criteria define the success measure for the tests.

As a final step, the test team should perform quality control. This activity entails using a checklist or worksheet to ensure that the process to set test objectives was followed, or reviewing them with the system users.

Changes in Technology

Effective testing must be done by a team comprised of information services professionals and users. In corporations where the users are not readily available, i.e., they are in a remote location, a professional test group can represent the users. Also vendors of software may not be able, or may not want to have users testing their systems during the developmental process.

Again, in these instances, a professional test group can represent the users. The test group is known by different names, including IT testing,.
The following technological developments are causing organizations to revise their approach to testing:

1 • Integration

Technology is being more closely integrated into day-to-day business resulting in business being unable to operate without computer technology. For example, the airlines can only take reservations when their computer systems are operational.

2 • System Chains

Computer systems are interconnected into cycles of chains such that problems in one can cascade into and affect others.

3 • The Domino Effect

One problem condition, such as a wrong price or a program defect, can cause hundreds or even thousands of similar errors within a few minutes.

4 • Reliance on Electronic Evidence

With hard-copy documents being removed from processing, the validity of the transactions is dependent upon the adequacy of controls, and thus a control error may result in extensive losses.

5 • Multiple Users

Systems no longer belong to single users, but rather to multiple users, making it difficult to identify a single organizational unit responsible for a system.

The organizational approach to testing commences with a policy on testing computer systems. The policy should be developed under the direction of the IT department, but should represent the philosophy of the entire organization. Once the policy has been established, then the procedures and the methods of testing can be developed based upon the desires of management as expressed in the testing policy.

Limited Tester Skills

Testers should be competent in all ten of the CSTE Common Body of Knowledge skill categories to be effective. Lack of the skills needed for a specific test assignment constrains the ability of the testers to effectively complete that assignment.


SOFTWARE TESTING FUNDAMENTALS

SOFTWARE TESTING FUNDAMENTALS PART TWO

SOFTWARE TESTING FUNDAMENTALS PART THREE

WHY SHALL WE TEST A SOFTWARE PRODUCT ?

TESTABILITY OF A SOFTWARE

APPROACHES TO SOFTWARE TESTING

TESTING STRATEGIES


ORGANIZING SOFTWARE TESTING

TESTING COMPLETION CRITERIA

SOFTWARE DEVELOPMENT PROCESS

SOFTWARE DEVELOPMENT LIFE CYCLE

PROJECT MANAGEMENT AND SOFTWARE TESTING

ECONOMICS OF SOFTWARE TESTING

DIFFERENT TEST LEVELS

TESTING TECHNIQUES

SPECIAL TEST TYPES


TESTING STANDARDS

ISO STANDARDS OF TESTING

TESTING PROCESS

TESTING PROCESS PART TWO

Testing Software and constraints

Anything that inhibited the tester’s ability to fulfill their responsibilities is a onstraint.Constraints include:

1 • Limited schedule and budget

2 • Lacking or poorly written requirements

3 • Changes in technology

4 • Limited tester skills

Budget and schedule constraints may limit the ability of a tester to complete their test plan.Understanding why the lack of life cycle testing can cause budget and schedule problems can help relieve the constraint.

Testing should begin during the first phase of the life cycle and continue throughout the life cycle. It’s important to recognize that life cycle testing is essential to reducing the cost of testing.

Most problems associated with testing occur from one of the following causes:

1 • Failing to define testing objectives

2 .Testing at the wrong phase in the life cycle

3 • Using ineffective test techniques

The cost-effectiveness of testing is illustrated in Figure . As the cost of testing increases,the number of undetected defects decreases. The left side of the illustration represents an under test situation in which the cost of testing is less than the resultant loss from undetected defects.

At some point, the two lines cross and an over test condition begins. In this situation, the cost of testing to uncover defects exceeds the losses from those defects. A cost-effective perspective means testing until the optimum point is reached, which is the point where the cost of testing no longer exceeds the value received from the defects uncovered.

Few organizations have established a basis to measure the effectiveness of testing. This makes it difficult for the individual systems analyst/programmer to determine the cost effectiveness of testing. Without testing standards, the effectiveness of the process cannot be evaluated in sufficient detail to enable the process to be measured and improved.

The use of standardized testing methodology provides the opportunity for a cause and effect relationship to be determined. In other words, the effect of a change in the methodology can be evaluated to determine whether that effect resulted in a smaller or larger number of defects.

The establishment of this relationship is an essential step in improving the test process. The cost-effectiveness of a testing process can only be determined when the effect of that process can be measured. When the process can be measured, it can be adjusted to improve the cost-effectiveness of the test process for the organization.
99.4

You can here consider reading SOFTWARE TESTING LIFE CYCLE part three .

This web site also covers c programming and you can learn discussion regarding c variables.

You like this post and interested in getting updates.

Subscribe to RSS FEED here or get updates directly into your EMAIL BOX.

Programming C variables

Variable names are names given to locations in memory. These locations can contain integer, real or character constants. In any language, the types of variables that it can support depend on the types of constants that it can handle. This is because a particular type of variable can hold only the same type of constant.

For example, an integer variable can hold only an integer constant, a real variable can hold only a real constant and a character variable can hold only a character constant. The rules for constructing different types of constants are different. However, for constructing variable names of all types the same set of rules apply.

Rules for Constructing Variable Names:

1. A variable name is any combination of 1 to 31 alphabets, digits or underscores. Some compilers allow variable names whose length could be up to 247 characters. Still, it would be safer to stick to the rule of 31 characters. Do not create unnecessarily long variable names as it adds to your typing effort.

2. The first character in the variable name must be an alphabet or underscore.

3. No commas or blanks are allowed within a variable name.

4. No special symbol other than an underscore (as in gross_sal) can be used in a variable name.

Ex.: si_int m_hra pop_e_89 These rules remain same for all the types of primary and secondary variables. Naturally, the question follows... how is C able to differentiate between these variables? This is a rather simple matter.

C compiler is able to distinguish between the variable names by making it compulsory for you to declare the type of any variable name that you wish to use in a program. This type declaration is done at the beginning of the program. Following are the examples of type declaration statements:

Ex.: int si, m_hra ; float bassal ; char code ; Since, the maximum allowable length of a variable name is 31 characters, an enormous number of variable names can be constructed using the above-mentioned rules.

It is a good practice to exploit this enormous choice in naming variables by using meaningful variable names. Thus, if we want to calculate simple interest, it is always advisable to construct meaningful variable names like prin, roi, noy to represent Principle, Rate of interest and Number of years rather than using the variables a, b, c.

C Keywords :

Keywords are the words whose meaning has already been explained to the C compiler (or in a broad sense to the computer). The keywords cannot be used as variable names because if we do so we are trying to assign a new meaning to the keyword, which is not allowed by the computer. Some C compilers allow you to construct variable names that exactly resemble the keywords.

However, it would be safer not to mix up the variable names and the keywords. The keywords are also called ‘Reserved words’.

30
Here we have a discussion on constants used in c programming.

Like this post and would like to get updates regularly.

Here you can subscribe to RSS FEED or get them into your mail box directly.

Constants in c programming

This discussion is in continuation with c language programming character sets.

Rules for Constructing Integer Constants :

1. It must not have a decimal point.
2. It can be either positive or negative.
3. If no sign precedes an integer constant it is assumed to be positive.
4. No commas or blanks are allowed within an integer constant.
5. The allowable range for integer constants is -32768 to 32767.
6. An integer constant must have at least one digit.

Truly speaking the range of an Integer constant depends upon the compiler. For a 16-bit compiler like Turbo C or Turbo C++ the range is –32768 to 32767. For a 32-bit compiler the range would be even greater. Till that time it would be assumed that we are working with a 16-bit compiler.

Ex.: 426
+782
-8000
-7605

Rules for Constructing Real Constants:

Real constants are often called Floating Point constants. The real constants could be written in two forms—Fractional form and Exponential form. Following rules must be observed while constructing real constants expressed in fractional form:

1. A real constant must have at least one digit.
2. It must have a decimal point.
3. It could be either positive or negative.
4. Default sign is positive.
5. No commas or blanks are allowed within a real constant.

Ex.: +325.34
426.0
-32.76
-48.5792

The exponential form of representation of real constants is usually used if the value of the constant is either too small or too large. It however doesn’t restrict us in any way from using exponential form of representation for other real constants.

In exponential form of representation, the real constant is represented in two parts. The part appearing before ‘e’ is called mantissa, whereas the part following ‘e’ is called exponent. Following rules must be observed while constructing real constants expressed in exponential form:

1 . The mantissa part and the exponential part should be separated by a letter e.
2 . The mantissa part may have a positive or negative sign.
3 . Default sign of mantissa part is positive.
4 . The exponent must have at least one digit, which must be a positive or negative integer.
5 . Default sign is positive.
6 . Range of real constants expressed in exponential form is -3.4e38 to 3.4e38.

Ex.: +3.2e-5
4.1e8
-0.2e+3
-3.2e-5

Rules for Constructing Character Constants :

1 . A character constant is a single alphabet, a single digit or a single special symbol enclosed within single inverted commas. Both the inverted commas should point to the left. For example, ’A’ is a valid character constant whereas ‘A’ is not.

2 . The maximum length of a character constant can be 1 character.

Ex.: 'A'
'I'
'5'
'='
If you are looking for advanced java programming basics try here.



JAVA Complete Course

c programming Character Set

If you are very new to programming with you can start with introduction to c programming lesson.

This particular lesson deals with different types of variables and constants used in c programming.

A character denotes any alphabet, digit or special symbol used to represent information.

The following is the list of allowed characters in c programming.

Constants, Variables and Keywords The alphabets, numbers and special symbols when properly combined form constants, variables and keywords.

A constant is an entity that doesn’t change whereas a variable is an entity that may change. In any program we typically do lots of calculations. The results of these calculations are stored in computers memory. Like human memory the computer memory also consists of millions of cells. The calculated values are stored in these memory cells.

To make the retrieval and usage of these values easy these memory cells (also called memory locations) are given names. Since the value stored in each location may change the names given to these locations are called variable names.

Consider the following example. Here 3 is stored in a memory location and a name x is given to it. Then we are assigning a new value 5 to the same memory location x. This would overwrite the earlier value 3, since a memory location can hold only one value at a time. This is shown in Figure.

Since the location whose name is x can hold different values at different times x is known as a variable. As against this, 3 or 5 do not change, hence are known as constants.

Types of C Constants C constants can be divided into two major categories:

(a) Primary Constants

(b) Secondary Constants

These constants are further categorized as shown in Figure.


25.2
Regarding constants in c programming further discussion will be made in the next posts.Just not to miss the lessons subscribe to the feed.

Your comments are welcome.

DOTNET CLR

The crux of the CLR is physically represented by a library named mscoree.dll (a.k.a. the common Object Runtime Execution Engine). When an assembly is referenced for use, mscoree.dll isloaded automatically, which in turn loads the required assembly into memory. The runtime engine is responsible for a number of tasks.

First and foremost, it is the entity in charge of resolving the location of an assembly and finding the requested type within the binary by reading the contained metadata. The CLR then lays out the type in memory, compiles the associated CIL into platformspecific instructions, performs any necessary security checks, and then executes the code in question.

In addition to loading your custom assemblies and creating your custom types, the CLR will also interact with the types contained within the .NET base class libraries when required. Although the entire base class library has been broken into a number of discrete assemblies, the key assembly is mscorlib.dll. mscorlib.dll contains a large number of core types that encapsulate a wide variety of common programming tasks as well as the core data types used by all .NET languages.

When you build .NET solutions, you automatically have access to this particular assembly.

The below Figure illustrates the workflow that takes place between your source code (which is making use of base class library types), a given .NET compiler, and the .NET execution engine.



The previous post in this blog is regarding software testing interview questions and you can have a quick look about that at here.

Testing Interview Questions complete

Here is the list of software testing interview questions.This list includes large number of interview questions devided into number of parts for convinience. Here there is also a list of Load Runner interview questions.Go through them and get the clarity. Your comments on this post and about the blog is welcome. Here is the list.

SOFTWARE TESTING INTERVIEW QUESTIONS PART ONE

SOFTWARE TESTING INTERVIEW QUESTIONS PART TWO

SOFTWARE TESTING INTERVIEW QUESTIONS PART THREE

SOFTWARE TESTING INTERVIEW QUESTIONS PART FOUR

SOFTWARE TESTING INTERVIEW QUESTIONS PART FIVE

SOFTWARE TESTING INTERVIEW QUESTIONS PART SIX

SOFTWARE TESTING INTERVIEW QUESTIONS PART SEVEN

SOFTWARE TESTING INTERVIEW QUESTIONS PART EIGHT
LOAD RUNNER INTERVIEW QUESTIONS PART ONE

LOAD RUNNER INTERVIEW QUESTIONS PART TWO

LOAD RUNNER INTERVIEW QUESTIONS PART THREE

LOAD RUNNER INTERVIEW QUESTIONS PART FOUR
LOAD RUNNER INTERVIEW QUESTIONS PART FIVE


The previous post is regarding very basics of programming with c language.The first famous programming language can be learned at this blog further.
The introduction of c programming can be learned here.

Programming with C introduction

C is a programming language developed at AT & T’s Bell Laboratories of USA in 1972. It was designed and written by a man named Dennis Ritchie. In the late seventies C began to replace the more familiar languages of that time like PL/I, ALGOL, etc. No one pushed C. It wasn’t made the ‘official’ Bell Labs language.

Thus, without any advertisement C’s reputation spread and its pool of users grew. Ritchie seems to have been rather surprised that so many programmers preferred C to older languages like FORTRAN or PL/I, or the newer ones like Pascal and APL. But, that's what happened.

Possibly why C seems so popular is because it is reliable, simple and easy to use. Moreover, in an industry where newer languages, tools and technologies emerge and vanish day in and day out, a language that has survived for more than 3 decades has to be really good.

Getting Started with C

Communicating with a computer involves speaking the language the computer understands, which immediately rules out English as the language of communication with computer. However, there is a close analogy between learning English language and learning C language.

The classical method of learning English is to first learn the alphabets used in the language, then learn to combine these alphabets to form words, which in turn are combined to form sentences and sentences are combined to form paragraphs.

Learning C is similar and easier. Instead of straight-away learning how to write programs, we must first know what alphabets, numbers and special symbols are used in C, then how using them constants, variables and keywords are constructed, and finally how are these combined to form an instruction. A group of instructions would be combined later on to form a program.




22
The previous post of this blog is regrading software testing life cycle.

Testing Life Cycle part three

This post is in contiunation with TESTING life cycle part two.

Program (Build/Construction)

Actual testing occurs during the construction stage of development. Many testing tools and techniques exist for this stage of system development. Code walkthrough and code inspection are effective manual techniques.

Static analysis techniques detect errors by analyzing program characteristics such as data flow and language construct usage. For programs of significant size, automated tools are required to perform this analysis.

Dynamic analysis, performed as the code actually executes, is used to determine test coverage through various instrumentation techniques. Formal verification or proof techniques are used to provide further quality control.

Test Process

During the test process, careful control and management of test information is critical. Test sets, test results, and test reports should be catalogued and stored in a database. For all but very small systems, automated tools are required to do an adequate job – the bookkeeping chores alone become too large to handle manually. A test driver, test data generation aids, test coverage tools, test results management aids, and report generators are usually required.

Installation

The process of placing tested programs into production is an important phase normally executed within a narrow time span. Testing during this phase must ensure that the correct versions of the program are placed into production; that data if changed or added is correct; and that all involved parties know their new duties and can perform them correctly.

Maintenance

A large portion of the life cycle costs of a software system are spent on maintenance. As the system is used, it is modified either to correct errors or to augment the original system. After each modification the system must be retested. Such retesting activity is termed regression testing. The goal of regression testing is to minimize the cost of system re validation.

Usually only those portions of the system impacted by the modifications are retested. However, changes at any level may necessitate retesting, re-verifying and updating documentation at all levels below it. For example, a design change requires design re-verification, unit retesting and subsystem retesting.

Test cases generated during system development are reused or used after appropriate modifications. The quality of the test documentation generated during system development and modified during maintenance will affect the cost of regression testing. If test data cases have been catalogued and preserved, duplication of effort will be minimized.

95