http://blogs.msdn.com/b/micahel/archive/2004/07/07/did-i-remember-to.aspx

Appraisal

Resignation

In appraisal meeting they will speak only about your weakness, errors and failures.

In resignation meeting they will speak only about your strengths, past achievements and success.

In appraisal you may need to cry and beg for even 10% hike.

In resignation you can easily demand (or get even without asking) more than 50-60% hike.

During appraisal, they will deny promotion saying you didn’t meet the expectation, you don’t have leadership qualities, and you had several drawbacks in our objective/goal.

During resignation, they will say you are the core member of team; you are the vision of the company how can you go, you have to take the project in shoulder and lead your juniors to success.

There is 90% chance for not getting any significant incentives after appraisal.

There is 90% chance of getting immediate hike after you put the resignation.

Denger and Gutierrez survey analyzed 13 approaches to derive test cases from the functional requirements. These approaches have got some solved and unsolved aspects in the process of generation of test cases. The survey concludes that approaches work at a theoretical level without describing how to generate executable test cases.

inteGREAT Studio has practically solved one of the approach of test case generation process and the solution it is fully compliance with Heumann02 approach deriving test cases from the use cases. User has to develop a model to express the functionality expected in the system in terms of use cases and system test cases can easily be derived from them.

System testing can be divided into two stages.

1. The first stage verifies the behavior of each use case in isolation
2. The second stage verifies the use cases work and satisfy integration requirement

inteGREAT Studio is fully compliance with the first stage approach and deriving adequate number of functional test cases from functional requirements (use cases). Future work scope includes the second stage of integration requirements currently its design and specification has been outlined and will be implemented and released in subsequent releases.

Test case categorization

inteGREAT Studio assures the delivery of high quality system, it generates the adequate test cases that are enough for comprehensive system test coverage. Test cases are categories in 4 different categories that help test managers to define what level of test execution is sufficient for any system.

• Simple
• Basic
• Medium
• Advance

Basic type of test case is designed on the logic of the McCabe’s Basis Path Testing. A basis path is a unique path through the software where no iterations are allowed - all possible paths through the system are linear combinations of them. Basic test cases are fit for BAT execution or minimum test coverage for any use case. Medium and Advance type of test cases are defined for comprehensive test coverage of the use case with all possible combination of alternate flows.

A basis path is a unique path through the software where no iterations are allowed - all possible paths through the system are linear combinations of them.

Format of Test Case Document

• Test Case Name
• Test Case Objective
• Test Case ID
• Category
• Actors
• Steps
• Valid/Invalid Conditions
• Expected Result
• Related Verifications Points e.g Business Rule, Functional Requirement, Constraint, Dependency etc
• Actual Result

The test case document runs with the combination of FVM document that defines the equivalence classes (valid and invalid data) and boundary conditions of all type of fields. FVM just not only covers the valid and invalid test data it also generate standard and consistent error message for each invalid data.

Test case Statistics

Test case document compute the test case complexity and statistics, given for each category that helps the manager to plan test execution duration. Test Complexity Index also compute the test coverage ratio between number of test cases and number of use case scenarios, that helps the user to understand the test coverage of the use case.

 
Test Coverage = Number of Test Case / Number of Use case Scenarios

 

Future Work

Second stage will cover the integration test cases and load test cases.

References:

• http://www.lsi.us.es/~javierj/investigacion_ficheros/sv10.pdf
• http://www.satisfice.com/tools/satisfice-tsm-4p.pdf
• Generating Test Cases From Use Cases
• Basis Path Testing for Structural and Integration Testing
• Automated Field Validation Matrix Using inteGREAT Tool Set

Dr Kaner talks about the requirement analysis of the Test documentation. According to Dr Kaner IEEE 829 is an paradigmatic example of standard that supports heavy weight software development process. You don’t have to generate all the documents listed in 829 to be IEEE 829 compliant. Time spent in filling boiler plate information could be spent in documenting testing strategies and other useful information. The biggest problem with modern heavyweight projects is that they have a lot of inertia and resist the necessary change.

Requirement Analysis for Test Documentation - Part II

In this part Dr Kaner explains that using ‘Prescriptive Standards’ and templates will yield inappropriate products. Questioning should be used to gather documentation requirements. There are different types of stakeholders and each one is dealt differently. Dr Kaner answers some of the questions about Test Document Requirements. Needs of the organisation are more important than the prescriptive standards.

Function Testing - Part VII

In this video Dr Kaner explains about functional testing. He talks about the functional testing tasks and the risks present in this type of testing

Dr. Kaner in this wonderful lecture explains the concept of specification based  software testing. He explains what is specification based software testing. Importance of the specifications in the places where it is served as a contractual agreement is also discussed in this lecture. It also explains why specification might not be relevant if it served as vision document to guide the development initially and now it is not up to date. He also explains concept related to Active Reading can be applied to Specification documents.

Specification Based Software Testing - Part 2

In the second part of tutorial on specification based software testing, Dr. Kaner explains why questioning is very important in analyzing specification document. He explains different types of questions like hypothetical, behavioural, factual, historical, open/closed, context dependent and context free questions. He also gives many context free questions which can be used in any testing projects.

Specification Based Software Testing - Part 3

In this lecture Dr. Kaner explains what should you look for in specification document. He explains the concept of ambiguity, adequacy and completeness. He gives a list of missing facts which can help you in identifying ambiguity in specifications. Technique of identifying ambiguity is also discussed in this lecture.

Specification Based Software Testing - Part 4

Dr. Kaner starts this lecture with suggestion on how as a tester you can contribute to specification review meeting. How coverage is important in specification based testing to make sure that every claim made in the specification is tested reasonably. Traceability Matrix is also discussed in this lecture.

Errors:

These are human mistakes, and their quantification often depends on an understanding of the programmer’s intentions. In the case of typographical or syntactic errors their causes are generally clear, but the nature and cause of design errors is much harder to establish precisely, particularly after the fact.

Defects:

These are improper program conditions that are generally the result of an error. Not all errors produce program defects, as with incorrent comments or some documentation errors. Conversely, a defect could result from such nonprogrammer causes a improper program packaging or handling.

Bugs:

A bug (or fault) is a program defect that is encountered in operation, either under test or in use. Bugs result from defects, but all defects do not cause bugs (some are latent and never found). With widely used software, the defects may be found many times, resulting in duplicates or multiple bugs per defect.

Failures:

A failure is a malfunction of a user’s installation. It may result from a bug, incorrect installation, a communication line hit, a hardware failure, and so forth.

Problems:

Problems are user-encountered difficulties. They may result from failures, misuse, or misunderstanding. Problems are human events as opposed to failures, which are system events.

The verification process provides objective evidence whether the software and its associated products and processes

• Conform to requirements (e.g., for correctness, completeness, consistency, accuracy) for all life cycle activities during each life cycle process (acquisition, supply, development, operation, and maintenance)
• Satisfy standards, practices, and conventions during life cycle processes
• Successfully complete each life cycle activity and satisfy all the criteria for initiating succeeding life cycle activities (e.g., building the software correctly)

The validation process provides evidence whether the software and its associated products and processes

• Satisfy system requirements allocated to software at the end of each life cycle activity
• Solve the right problem (e.g., correctly model physical laws, implement business rules, use the proper system assumptions)
• Satisfy intended use and user needs

Quality Control (QC):

• QC relates to a specific product or service.
• QC verifies whether particular attributes exist, or do not exist, in a specific product or service.
• QC identifies defects for the primary purpose of correcting defects.
• QC is the responsibility of the worker.

Quality Assurance (QA):

• QA helps establish processes.
• QA sets up measurement programs to evaluate processes.
• QA identifies weaknesses in processes and improves them.
• QA is a management responsibility, frequently performed by a staff function.
• QA evaluates whether or not quality control is working for the primary purpose of determining whether or not there is a weakness in the process.
• QA is concerned with all of the products that will ever be produced by a process.
• QA is sometimes called quality control over quality control because it evaluates whether quality control is working.
• QA personnel should not ever perform quality control unless doing it to validate quality control is working.

View Demo in Full Screen