Static Testing In Details

Why Static instead of Dynamic and why teams do static testing? What’s the secret behind?

Yes, we have answer!!!!

Static Testing helps you build the Product Right, Yes a process of Verification.

Static testing is an analysis of a program carried out without executing the program. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization.

Why is static testing more effective?

Static testing gives you wide-ranging diagnostics for your code and warns you about:

Syntax errors

Code that will be hard to maintain

Code that will be hard to test

Code that does not conform to your coding standards

Non-portable usage

ANSI violations

All this takes place before compilation. It takes roughly as long as compilation and checks every statement you have written.

Since static testing is faster and achieves 100% coverage, the unit cost of detecting these bugs by static testing is many times lower than by dynamic testing

If you are using neither static nor dynamic test tools, static tools offer greater insignificant benefits.

If company can afford only one tool, remember: Static testing is up to 100 times more effective. Even in selective testing, static testing may be up to 10 times more effective.

Dynamic testing detects fewer errors than static testing, but it does detect some that static testing misses.

Cost-Effectiveness of Static vs. Dynamic Analysis:

Static Testing Techniques :

Here are some of the more popular and effective techniques used

• Inspection

• Walkthrough

• Review

Inspection - Main purpose: Find defects

• Formal individual and group checking, using sources and standards, According to detailed and specific rules

• Inspection is a well-defined process

Inspection: An inspection is a formal, rigorous, in-depth group review designed to identify problems as close to their point of origin as possible. Inspection is a recognized industry best practice to improve the quality of a product and to improve productivity, Inspections is a formal review and generally need is predefined at the start of the product planning,

The objectives of the inspection process are to

• Find problems at the earliest possible point in the software development process

• Verify that the work product meets its requirement

• Ensure that work product has been presented according to predefined standards

• Provide data on product quality and process effectiveness

• Inspection advantages are to build technical knowledge and skill among team members by reviewing the output of other people

• Increase the effectiveness of software testing.

IEEE 1028 recommends three following roles in an Inspection:

Inspector Leader: The inspection leader shall be responsible for administrative tasks pertaining to the inspection, shall be responsible for planning and preparation, shall ensure that the inspection is conducted in an orderly manner and meets its objectives, should be responsible for collecting inspection data

Recorder: The recorder should record inspection data required for process analysis. The inspection leader may be the recorder.

Reader: The reader shall lead the inspection team through the software product in a comprehensive and logical fashion, interpreting sections of the work product and highlighting important aspects

Author: The author shall be responsible for the software product meeting its inspection entry criteria, for contributing to the inspection based on special understanding of the software product, and for performing any rework required to make the software product meet its inspection exit criteria.

Inspector: Inspectors shall identify and describe anomalies in the software product. Inspectors shall be chosen to represent different viewpoints at the meeting (for example, sponsor, requirements, design, code, safety, test, independent test, project management, quality management, and hardware engineering). Only those viewpoints pertinent to the inspection of the product should be present. Some inspectors should be assigned specific review topics to ensure effective coverage. For example, one inspector may focus on conformance with a specific standard or standards, another on syntax, and another for overall coherence. These roles should be assigned by the inspection leader when planning the inspection.

All participants in the review are inspectors. The author shall not act as inspection leader and should not act as reader or recorder. Other roles may be shared among the team members. Individual participants may act in more than one role. Individuals holding management positions over any member of the inspection team shall not participate in the inspection

Walkthrough - Main purpose: Understanding

• Author guides the group through a document, so all understand the same thing, consensus on changes to make

Walkthrough: Method of conducting informal group/individual review is called walkthrough, in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems or may suggest improvement on the article, walkthrough can be pre planned or can be conducted at need basis and generally people working on the work product are involved in the walkthrough process.

The Purpose of walkthrough is to

• Find problems

• Discuss alternative solutions

Focusing on demonstrating how work product meets all requirements. IEEE 1028 recommends three specialist roles in a walkthrough:

Leader: who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author)

Recorder: who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meeting, normally generate minutes of meeting at the end of walkthrough session.

Author: who presents the software product in step-by-step manner at the walk-through meeting, and is probably responsible for completing most action items.

Walkthrough Process: Author describes the artifact to be reviewed to reviewers during the meeting. Reviewers present comments, possible defects, and improvement suggestions to the author. Recorder records all defect, suggestion during walkthrough meeting. Based on reviewer comments, author performs any necessary rework of the work product if required. Recorder prepares minutes of meeting and sends the relevant stakeholders and leader is normally to monitor overall walkthrough meeting activities as per the defined company process or responsibilities for conducting the reviews, generally performs monitoring activities, commitment against action items etc.

Review - Main purpose: Decision making

• Group discusses document and makes a decision about the content, e.g. how something should be done, go or no-go decision

Review is "A process or meeting during which artifacts of software product are examined by project stockholders, user representatives, or other interested parties for feedback or approval”.Software Review can be on Technical specifications, designs, source code, user documentation, support and maintenance documentation, test plans, test specifications, standards, and any other type of specific to work product, it can be conducted at any stage of the software development life cycle.

Purpose of conducting review is to minimize the defect ratio as early as possible in Software Development life cycle. As a general principle, the earlier a document is reviewed, the greater will be the impact of its defects on any downstream activities and their work products. Magnitude cost of defect fixing after the release of the product is around 60-100x. Review can be formal or informal. Informal reviews are referred as walkthrough and formal as Inspection.

· Formal individual and group checking, using sources and standards, According to detailed and specific rules

· Inspection is a well-defined process

Conclusion:

Static testing finds bugs before you compile.

Many bugs found by dynamic testing can be found earlier by static testing.

The earlier you detect bugs the cheaper they are to fix.

Static testing is more cost effective than dynamic testing.

Source:

Software testing: testing across the entire software development life cycle By Gerald D. Everett, Raymond McLeod

Traceability Matrix in Details

It sounds complicated. Why do teams do it? It sounds like a lot of work. Is it really worth the effort? Good questions. The short answer: Yes. And, here’s why it’s so important: Change happens.

Traceability Helps You Stay Connected, Manage Change & Improve Quality. Yes!

If managed poorly, change will wreak havoc on even the most talented and experienced development teams. If managed skilfully, using tools like traceability, teams are better equipped to assess the impact of changes, track the full history, keep everyone in sync and (deep breath) consistently improve the quality of the products being built– every project, every release. Sign me up

Traceability ensures completeness, that all lower level requirements come from higher level requirements, and that all higher-level requirements are allocated to lower level requirements. Traceability is also used to manage change and provides the basis for test planning.

Requirements tracing is the process of documenting the links between the user requirements for the system you’re building and the work products developed to the implement and verify those requirements

Requirements tracing helps the project team to understand which parts of the design and code implement the user’s requirements, and which tests are necessary to Verify that the user’s requirements have been implemented correctly.

The Five Tips for Mastering Traceability

1. Create relationships to connect everyone and everything together with Trace Relationships

2. Ensure you have proper coverage using a Traceability Matrix

3. Assess the impact of a change before it occurs with Impact Analysis

4. Document changes for complete visibility and a detailed audit trail with Version History

5. Keep communication flowing and the team in sync with smarter, real-time Email Notifications

Types of Traceability Matrix

Forward Traceability Matrix

1. Tracing the requirements sources to their resulting product requirement(s) to ensure the completeness of the product requirement specification.

2. Tracing each unique product requirement forward into the design that implements that requirement, the code that implements that design and the tests that validate that requirement and so on.

3. The objective is to ensure that each requirement is implemented in the product and that each requirement is thoroughly tested.

Forward Traceability Matrix – Benefits

1. Assess the changes in the business environment by tracing from the requirement to the product

2. Forward traceability ensures proper direction of the evolving product and indicates the completeness of the subsequent implementation

Backward Traceability Matrix

1. Tracing each unique work product (e.g., design element, object/class, code unit, test) back to its associated requirement.

2. Tracing each requirement back to its source(s).

Backward Traceability Matrix – Benefits

1. Assess current status of the requirements and the project

i. Identify missing requirements

ii. Identify gold plating

2. Assess the root cause of the defect by tracing the defect from the Product to the requirement

Bi-Directional Traceability Matrix

The Combination of both forward & backward traceability is called as Bidirectional Traceability.

Bi-Directional Traceability Matrix – Benefits

1. Analyze the impact of a change

i. All work products affected by a changed requirement

ii. All requirements affected by a change or defect in a work product

2. Assess current status of the requirements and the project

iii. Identify missing requirements

iv. Identify gold plating

Why Traceability Matrix is important?

How can we ensure, for each life cycle phase, which I had correctly accounted for all customer needs?

How can I ensure that the final software product meets the customer needs? For example, I have a function that checks for invalid password I put in the password field of the application throws an error message "Invalid Password". We can only ensure that this requirement is included in the test case for the traceability matrix.

Test Metrics

Metrics	Formula
Effort Variation	(Actual Effort - Estimated Effort)/(Estimated Effort) *100
Schedule Variation	(Actual End Date - Planned End Date) / (Planned End Date- Planned Start) *100
Defect Density	Total no of defects/Effort                                                    or                                                                                   Total no of defects/Size
Load Factor	No of available resources / Total no of actual resources
Testing Efficiency	Total Valid Defects/Total Defects * 100
Productivity	<No. Of Test cases Executed or No. of Test Case Prepared>/Total effort in person days
Percentage Rejection	Total invalid Defects/Total Defects * 100
Percentatge Rework	(Total Rework Effort) / (Actual Effort expended for the project)*100
Build wise effort	(Build Actual Effort - Build Estimated Effort)/(Build Estimated Effort) *100
Build Rejection	No. of Builds Failed/Total No. of Builds
Regression Test Failure	No. of Regression Test Failed/Total Regression Test Cases
Build Wise Smoke Test	Pass Vs Fail
Buildwise Test Execution Metrics	No. of Test Cases passed/Total No. of Test cases

GUI Standards

Following are graphics user interface standards for an application

Alignment: -

• When you use a column heading with a sorting function, center the heading

       Left justify text fields

•  Right justify whole numbers in columns
• Set the tab order for all controls left-right, top-bottom
• When some column headings require multiple lines and

             Some do not; align the columns with one line across the bottom

Borders:-

• Add 3D lowered borders to entry fields. Do not use borders with protected fields (i.e., flat and transparent).
• Make storable column headings 3D raised.

Check Boxes: -

• If a check box is unavailable, disable the checkbox by

            Making it 2D

• Check boxes on list windows should be centered
• Do not put a group box around a single checkbox.
• The maximum number of check boxes you can put in a group box is three arranged horizontally, or six arranged vertically.
• Left justify vertical check boxes
• Do not put more than six check boxes in a group  Instead, use a multiple selection list or drag and drop
• A check box label can be between two and thirty characters

Color:-

• If the user has inquiry rights only make the background of the entry fields transparent Else make it white.
• When using colors, especially red and green, provide color blind users

            Another method of distinguish between colors

      

Standard window colors are

Window and Data Window Background

      Silver

Entry Field Background - Display Only

      Silver

Entry Field Background - Enterable

      White

Entry Field Text

      Black

Title Bar

      The color set by the client in Windows

Labels

      Black Bold

Command Buttons: -

• Place command buttons on the right or bottom of a window, but not both
• On summary windows (windows with lists), align push buttons horizontally along the bottom portion of the window
• On detail windows, align push buttons vertically along the right side of the window.
• Arrange push buttons by frequency of use, from positive actions to negative actions
• Always assign a default push button in response windows
• Always make the OK button, if available, the left-most or first push button on the dialog window
• Always make the Help button the right most, or last push button on a

      Dialog window graphic or Label or both. Capitalize the first letter of a word.

• Ensure that the Use of an accelerator key is unique within that setting.
• A window can have up to six push buttons
• The control menu on a primary window must include Move, Size, and Close.
• Add right mouse click menu for word wrap, and home/end

      If the grid contains a description column 

Control Bar & Menu

• Include the Control Bar in primary windows, dialog windows, and message boxes.
• The control menu on a primary window must include Move, Size, and Close.
• The control menu on a dialog window must include Move, Close.
• Provide what’s this help wherever possible.

 Data Window:-

• Add a 3D lowered box around the borders of select Data windows.
• Do not make the border of a header Data Window 3D lowered, but you

      Can add a box around it if necessary

• Add a group box around multi-line header data windows

Dialog Window: -

• Make the default size of the dialog window large enough to view all of

      The components on the screen without grouping

• Display all dialog windows in the center of the screen, by default
• Let the user move the dialog windows to view other parts of the screen.

Drop Down Data Window and Selection List: -

• A drop down list must contain at least three items
• A drop down list can contain up to fifty items. If you need more than

      50 items, use a response window

• Order the data in a list box in a manner the user recognizes, for

       Example, alphabetically

• A list can display between three and six items, but provide it with a

      Vertical scroll bar to view the remaining options if there are more than six.

• If the entire field does not appear in the space on the window, make it scrollable

Date:-

• Date fields should always contain an edit mask of mm/dd/yyyy regardless of whether they are updatable or not
• Fields that are not available for update should be disabled rather than hidden

Fonts, Capitalization & Punctuation: -

• The font for all “text” is MS Sans Serif 8 point
• OK is always all caps
• If the message or title is a full sentence, punctuate them normally
• Capitalize the first letter of each word, except for articles and prepositions

Group Boxes & frames: -

• The group box typically groups radio buttons or check boxes
• Do not use a group box to group push buttons or list boxes
• Use the smart pointer  wherever a right click pop up menu is available
• Design all frames/Windows  for 640 X 800 screen resolution

 Icons:-

• Make icons 3D so that they look like buttons
• Label all toolbar icons the name of the application or window that they represent
• Provide functions such as New, Open, Save, and Close with an icon on
• The tool bar and an option in the menu
• Make icons (such as the calendar icon) work on a single click

Key board Access: -

• Make the tabbing sequence in the window logical, and in either left to

      Right and/or top to bottom sequence

• Give every menu item and push button a mnemonic and/or shortcut key
• Make the mnemonic for an item the first consonant of the first word

Message Boxes: -

• Make the title of the message box the same as the title on the parent

      Window. Do not use punctuation in the titles

• A message box must contain the Title Bar and adequate push buttons
• Include the Stop graphic before the message in the error message box.
• Valid push buttons for an error message box are: OK and Help.
• Include the "I" graphic before the message in the information message box
• Do not make the message box resizable

Menu bar /Options and Pull Down menus: -

• Provide between two and fifteen items in the pull down menu
• Use a separator to separate destructive actions such as Exit from the

      Other menu items

• Make menu items fit on one line
• Provide mnemonic keys for menu items wherever possible
• Begin option names with a verb (Example: "Review Sample Details").
• The Window pull down menu displays a list of windows currently

     Open in the application. The list is sorted by use with the current

     Window listed first, the previous window used listed second and so on.

Radio Buttons: -

• Assign one radio button as the default. The default radio button is pre-

      Selected whenever the window is displayed

• Arrange radio buttons in rows or columns or both. Left justify vertical

      Radio buttons

• A group of radio buttons must contain at least two
• If a radio button is not available, disable it by displaying the label in gray.

Reports: -

• Create columnar reports wherever possible
• Left justify report labels
• Display page numbers
• Use common report headers

                     

Status Line:-

• Display help on the status line

Tab Folders: -

• Use a maximum of one tab folder per window
• Do not nest tab folders within tab folders
• Place tab page labels at the top of the tab folder