Bidirectional traceability

Bidirectional traceability is the ability to trace both forward and backward (i.e., from requirements to end products and from end product back to requirements).

It means tracing the code from requirements and vice-versa throughout a Software Development Life Cycle (SDLC). When you are in the course of your project, your fundamental aim would be to ensure that each and every requirement is translated into code. Tracing right from the requirements through the architecture and design, to the code, to ensure that the objectives or more precisely requirements have been met is referred to as the process of establishing Forward Traceability.

When you think about maintenance, invariably, due to economic and technical considerations your client will come back to you. At this juncture, you will debug; or rather you will hunt for various types of bugs. You should be in a position to go back to the requirements of corresponding code or architectural components. To achieve this you ought to trace back your code and design to their corresponding requirements. This process is called Backward Traceability.

ISTQB Exam Paper

21 Given the following types of tool, which tools would typically be used by developers and which by an independent test team?

i. static analysis

ii. Performance testing

iii. Test management

iv. Dynamic analysis

v. test running

vi. Test data preparation

a) Developers would typically use i, iv and vi; test team ii, iii and v

b) Developers would typically use i and iv; test team ii, iii, v and vi

c) Developers would typically use i, ii, iii and iv; test team v and vi

d) Developers would typically use ii, iv and vi; test team I, ii and v

e) Developers would typically use i, iii, iv and v; test team ii and vi

22 The main focus of acceptance testing is:

a) Finding faults in the system

b) Ensuring that the system is acceptable to all users

c) Testing the system with other systems

d) Testing for a business perspective

e) Testing by an independent test team

23 Which of the following statements about the component testing standard is false?

a) Black box design techniques all have an associated measurement technique

b) White box design techniques all have an associated measurement technique

c) Cyclomatic complexity is not a test measurement technique

d) Black box measurement techniques all have an associated test design technique

e) White box measurement techniques all have an associated test design technique

24 Which of the following statements is NOT true?

a) Inspection is the most formal review process

b) Inspections should be led by a trained leader

c) Managers can perform inspections on management documents

d) Inspection is appropriate even when there are no written documents

e) Inspection compares documents with predecessor (source) documents

25 A typical commercial test execution tool would be able to perform all of the following EXCEPT:

a) Generating expected outputs

b) Replaying inputs according to a programmed script

c) Comparison of expected outcomes with actual outcomes

d) Recording test inputs

e) Reading test values from a data file

26 The difference between re-testing and regression testing is

a) Re-testing is running a test again; regression testing looks for unexpected side effects

b) Re-testing looks for unexpected side effects; regression testing is repeating those tests

c) Re-testing is done after faults are fixed; regression testing is done earlier

d) Re-testing uses different environments, regression testing uses the same environment

e) Re-testing is done by developers; regression testing is done by independent testers

27 Expected results are:

a) Only important in system testing

b) Only used in component testing

c) Never specified in advance

d) Most useful when specified in advance

e) Derived from the code

28 Test managers should not:

a) Report on deviations from the project plan

b) Sign the system off for release

c) Re-allocate resource to meet original plans

d) Raise incidents on faults that they have found

e) Provide information for risk analysis and quality improvement

29 Unreachable codes would best be found using:

a) Code reviews

b) Code inspections

c) A coverage tool

d) A test management tool

e) A static analysis tool

30 A tool that supports traceability, recording of incidents or scheduling of tests is called:

a) A dynamic analysis tool

b) A test execution tool

c) A debugging tool

d) A test management tool

e) A configuration management tool

31 What information need not be included in a test incident report?

a) How to fix the fault

b) How to reproduce the fault

c) Test environment details

d) Severity, priority

e) The actual and expected outcomes

32 Which expression best matches the following characteristics or review processes:

1. Led by author

2. Undocumented

3. No management participation

4. Led by a trained moderator or leader

5. Uses entry exit criteria

s) Inspection

t) Peer review

u) Informal review

v) Walkthrough

a) s = 4, t = 3, u = 2 and 5, v = 1

b) s = 4 and 5, t = 3, u = 2, v = 1

c) s = 1 and 5, t = 3, u = 2, v = 4

d) s = 5, t = 4, u = 3, v = 1 and 2

e) s = 4 and 5, t = 1, u = 2, v = 3

33 Which of the following is NOT part of system testing?

a) Business process-based testing

b) Performance, load and stress testing

c) requirements-based testing

d) Usability testing

e) top-down integration testing

34 What statement about expected outcomes is FALSE?

a) Expected outcomes are defined by the software’s behavior

b) Expected outcomes are derived from a specification, not from the code

c) Expected outcomes include outputs to a screen and changes to files and databases

d) Expected outcomes should be predicted before a test is run

e) Expected outcomes may include timing constraints such as response times

35 The standard that gives definitions of testing terms is:

a) ISO/IEC 12207

b) BS7925-1

c) BS7925-2

d) ANSI/IEEE 829

e) ANSI/IEEE 729

36 The cost of fixing a fault:

a) Is not important

b) Increases as we move the product towards live use

c) Decreases as we move the product towards live use

d) Is more expensive if found in requirements than functional design?

e) Can never be determined

37 Which of the following is NOT included in the Test Plan document of the Test Documentation Standard?

a) Test items (i.e. software versions)

b) What is not to be tested?

c) Test environments

d) Quality plans

e) Schedules and deadlines

38 Could reviews or inspections be considered part of testing:

a) No, because they apply to development documentation

b) No, because they are normally applied before testing

c) No, because they do not apply to the test documentation

d) Yes, because both help detect faults and improve quality

e) Yes, because testing includes all non-constructive activities

39 Which of the following is not part of performance testing:

a) Measuring response time

b) Measuring transaction rates

c) Recovery testing

d) Simulating many users

e) Generating many transactions

40 Error guessing is best used

a) As the first approach to deriving test cases

b) After more formal techniques have been applied

c) By inexperienced testers

d) After the system has gone live

e) Only by end users

Answers

21 B

22 D

23 A

24 D

25 A

26 A

27 D

28 C

29 A

30 E

31 E

32 B

33 E

34 A

35 B

36 B

37 D

38 D

39 C

40 B

Database Testing

Database systems play an important role in nearly every modern organization. The ultimate objective of database analysis, design, and implementation is to establish an electronic data store corresponding to a user’s conceptual world.

Functionality of the database is a very critical aspect of application’s quality; problems with the database could lead to data loss or security violation, and may put a company at legal risk
depending on the type of data being stored. Applications consist of a database and improving quality of data in an organization is often a daunting task. A database should be evaluated throughout the database development life cycle to prepare a quality database application.
Data in a database may be input from and displayed on a number of different types of Systems. Each of these types of systems has unique system limitations, which may dictate how data should be formatted in your database. A database should be evaluated based on the factors
such as data integrity, consistency, normalization, performance, security and very important - the expectations of its end users.

                                 The database design process is decided by finding the requirements and needs of the end user. Uncertainty about understanding the requirements can be reduced only after significant analysis and discussions with users. Once the user requirements are clear, the
process of behavior implementation consists of the design and construction of a solution domain following the problem domain. Because of the difficulties associated with the changing
requirements, the database developer must attempt to develop a database model which closely matches the perception of the user, and deliver a design that can be implemented, maintained and modified in a cost-effective way. Diagrammatic representation using entity relationship
diagrams, object models, data flow diagrams, allows the information described in a visual format in a meaningful way.

Database testing is one of the most challenging tasks to be done by software testing team.
A Database Tester, by understanding the referential integrity and database security, and by having a good grasp on the various technologies and data formats used to transfer and retrieving the data from the database, can test database to avoid problems. Testing should be included in various phases of database development life cycle. The cycle typically consists of several stages from planning to designing, testing and deployment. In the first phase of database development process, requirements are gathered; checklists can be used as part of the evaluation process for the database specification. After gathering requirement and understanding the need for the database, a preliminary list of the fields of data to be
included in the database should be prepared. We should have complete information about what information is required by the client and what type of fields are required to produce that information. Next determine if the logical data model is complete and correct. Confirm the design with the business community in a design review process. Create a logical Entity Relationship Diagram (ERD) to graphically represent the data store. Determine if the data model is fully documented (entities, attributes, relationships) Attributes have correct data type, length, NULL status, default values. General discussion of business rules to be enforced by database level constraints should be carried out e.g.
• Not null constraints
• Check constraints
• Unique constraints
• Primary key constraints
• Foreign key constraints
Business rules to be enforced by triggers and procedures should be discussed along with the business rules to be enforced by application code. After this the normal forms should be tested with the help of test data. Testing physical database design includes testing table definitions,constraints, triggers and procedures. Black Box testing techniques like Boundary value analysis can be used. We can test the table definition by testing the column definitions and constraints that have been imposed:Database constraints can be checked as follows:
1. Primary Key- Write Test Case to insert duplicate value in Primary Key column.
2. Insert record to violate Referential Integrity Constraint.
3. Delete record to violate Referential Integrity Constraint.
4. Insert NULL value in NOT NULL column.
5. Insert values to violate check constraints by inserting values outside input domains.                    
For relational databases queries are written using SQL. We can test database queries by identifying different situations and data values. SQL conditions can be tested using Decision Condition Coverage:
a. Select statements use conditions in Where Clause and Having Clause for Group By columns.
I. Conditions written using AND logical operator requires (T, T), (T, F), (F, T) outcomes for two operands to be tested.
ii. Conditions written using OR logical operator requires (F, F), (T,
F), (F, T) outcomes to be tested.
Testing requires that every condition affecting the result takes all possible outcomes at least once.
b. Testing SQL statements involving NULL values.
I. Requires Testing conditions with each operand in the condition taking NULL value.
ii. For a Group By Clause, NULL values have to be considered.
c. For sub queries, include test cases to return zero and more rows.
d. SQL statements like Update, Insert, and Delete also need to be tested for conditions.
Apart from testing the table definitions and SQL statements a database tester should test the triggers, procedures and functions. These objects can be unit tested by finding various paths of
execution in the code and functionality can be tested by executing the code - providing required inputs and checking the output generated.

Let’s see how can we design test cases to test table definition i.e. column definitions and constraints. Refer to ‘Item’ table storing details of items in stock. Details of sales orders placed for various items are stored in another table ‘Sales’. The table definitions are as follows:
Table Definitions
To test the constraints, we can design test cases as follows:
ITEM Table
Test Case ID: TCcheck _itemcodePK
Objective: To evaluate Primary key constraint on Item code in item table.
Description: Insert two records with I001 as Item code.
Expected Result: second record should not be saved in database.
Test Case ID: TCcheck _itemcode1
Objective: To evaluate check constraint on Item code in item table.
Description: Insert a record with I001 as Item code.
Expected Result: record should be saved in database.
Test Case ID: TCcheck _itemcode2
Objective: To evaluate check constraint on Item code in item table.
Description: Insert a record with I555 as Item code.
Expected Result: record should be saved in database.
Test Case ID: TCcheck _itemcode3
Objective: To evaluate check constraint on Item code in item table.
Description: Insert a record with invalid Item code as I000.
Expected Result: error message should be displayed.
Test Case ID: TCcheck _itemcode4
Objective: To evaluate check constraint on Item code in item table.
Description: Insert a record with I556 as Item code.
Expected Result: error message should be displayed.
Test Case ID: TCcheck _Description1
Objective: To evaluate NOT NULL constraint on description column in item table.
Description: Insert a record with no value for description column.
Expected Result: error message should be displayed.
Test Case ID: TCcheck _price
Objective: To evaluate check constraint on price column in item table.
Description: Insert a record with price=-10.
Expected Result: error message should be displayed.
Test Case ID: TCcheck _delete
Objective: To evaluate referential integrity constraint on item code column in item table.
Description: insert a record in sales table with item code I001.
Delete record from item table where item code=I001.
Expected Result: error message should be displayed. SALES Table
Test Case ID: TCcheck _itemcode
Objective: To evaluate references constraint on item code column in sales table.
Description: Insert a record with item code not existing in item table.
Expected Result: error message should be displayed.
Test Case ID: TCcheck _orderID
Objective: To evaluate check constraint on Order_ID column in sales table.
Description: Insert a record with Order_ID as 1001.
Expected Result: error message should be displayed. 

Now consider a requirement for displaying details of all the items for which qty ordered is>10. We can find the required details by writing

SQL query:
Select item_code from sales where qty>10
To test this query we can prepare a test sales table having records with qty>10. When executed, this query should return all the matching records. Similarly we can check the query by preparing a table not having any matching records.