Testability - Building in Lower QA Costs

Currently working on developing a Test Framework for a third-party's website and it is an excellent example of how involving testers early in a project could result in long-term cost savings and/or higher quality.

The website has a Menu navigation component on most of the site's 130 pages. The menu provides the ability for users to select and browse to the required page. While familiarising myself with the website I noticed that some menu items were missing on some pages and some menu items linked to the wrong pages. At this point I realised that I'd need to fully test the Menu component - IE. Ensure all menu items (130) were there and they all worked correctly (IE. Clicking on each one takes user to the correct page) - on every page. Potentially, over 15,000 tests (about 130 x 130)!

The menu system had been designed so that it does not use common code - or a single component - for the menu, it appears the code had been copy/pasted and possibly edited; hence introducing the errors. If a (good technical) tester had been used early in the design phase he/she would have highlighted that by not using a common menu component referenced by the pages, they would all need to be tested. Rather than just 260-300ish tests, over 15,000 tests - with the resulting cost implications (especially if the test-automation tool being used doesn't scale well). If a common component had been used, then the full set of items and their functionality would only have to have been tested on a single page and then just its presence and item-count on the other pages tested. As the menu component had separate code on every page that code has to be excersized fully and hence the high number of tests.

Luckily the test tool I'm using scales well, and going from the 130+ tests on the first page to 15K+ is relatively quick. However, with most tools this would be prohibitively expensive & time consuming (and not cost effective considering the low impact of defects the tests would find), which would mean that functionality would simply not be regression tested......

To view or add a comment, sign in

More articles by Mathieu Walker

  • Remembering Fred Brooks

    I have just found out that Fred Brooks passed away in November last year. Very ashamed I didn't know.

  • Where is the Abort test result?

    In nearly most results presentation/reporting tools there are only two states for a test; Pass and Fail. This is not…

  • Test Automation in Agile

    I have never ever seen Functional Regression Test Automation work well in Agile. Now there is an opening statement! But…

    2 Comments
  • Test Automation - Get Real!

    I warn you, this is a rant. An unashamed rant.

    8 Comments
  • Test Tool Review sites

    Recently I was directed to a Software Test Tool review site; https://www.softwaretestinghelp.

    2 Comments
  • Test Automation - What is Test Data?

    When discussing Test Automation (Automation of the integrated regression suite of tests) with folk outside the Test…

    1 Comment
  • Analogy of Software and Hardware testing

    It is often difficult to explain to non software-test folk why there is a need to test at the varying stages of…

  • Test Pyramid and focus of testing

    I was recently asked if there is value in following the [Agile] testing pyramid (ie. focus on unit & integration tests…

    3 Comments
  • Automation of UI Tests - Economical?

    Very recently, I had lunch with an old colleague who is a highly respected business analyst and architect. During lunch…

    5 Comments
  • Test Automation tools and scaleability

    Choosing the right test automation tool is always an uphill task, that is quite often frustrating. The primary reason…

Others also viewed

Explore content categories