Modularity-driven testing: Difference between revisions

Revision as of 11:55, 9 March 2012

Latest revision as of 05:21, 8 July 2023

(23 intermediate revisions by 17 users not shown)

Line 1:

'''Modularity-driven testing''' is a term used in the testing of [[software]]. The test [[Script (computer programming)|script]] modularity [[Software framework|framework]] requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case.<ref>{{Cite book |last1=DESAI |first1=SANDEEP |url=https://books.google.com/books?id=B4sQDAAAQBAJ&dq=Modularity-driven+testing+framework&pg=PA157 |title=SOFTWARE TESTING : A Practical Approach |last2=SRIVASTAVA |first2=ABHISHEK |date=2016-01-30 |publisher=PHI Learning Pvt. Ltd. |isbn=978-81-203-5226-1 |language=ar}}</ref>

{{Unreferenced|date=March 2007}}

{{Portal|Software Testing}}

==Background==

'''Modularity-driven testing''' is a term used in the testing of [[software]].

Of all the frameworks, this one should be the simplest to grasp and master. It is a well-known [[Computer programming|programming]] strategy to build an abstraction layer in front of a component to hide the component from the rest of the application. This insulates the application from modifications in the component and provides modularity in the application design. The test script modularity framework applies this principle of abstraction or [[encapsulation (computer programming)|encapsulation]] in order to improve the maintainability and scalability of automated test suites.<ref>{{cite web|last=Kelly|first=Michael|title=Choosing a test automation framework|website=[[IBM]] |url=http://www.ibm.com/developerworks/rational/library/591.html|accessdate=2013-02-22}}</ref>

==References==

==Test Script Modularity Framework==

The test script modularity framework requires the creation of small, independent scripts that represent modules, sections, and functions of the application-under-test. These small scripts are then used in a hierarchical fashion to construct larger tests, realizing a particular test case.

{{Reflist}}

Of all the frameworks, this one should be the simplest to grasp and master. It is a well-known programming strategy to build an abstraction layer in front of a component to hide the component from the rest of the application. This insulates the application from modifications in the component and provides modularity in the application design. The test script modularity framework applies this principle of abstraction or encapsulation in order to improve the maintainability and scalability of automated test suites.

Let us discuss the modular framework architecture…

The core is the Master driver---This only consists of the calling business cases like—

login

Create user

Define attribute

Logout

The login module is again summation of 3-4 generic functions….like--

Open Application

Set user id

set Password

Click on Ok/submit

The data for this will come from Data table

The Module(business specific) might call an function which is not generic for other module but can have some functions which are generic in nature

say…

Write Customer Name in the text box is a generic function..where this is a type of setting a textbox with a specific value…this is generic across the application.

But if the test case is …

give 5% discount if the customer ___location is from Kolkata but 10% if he is from Hyderabad

This type of function is still generic but specific to that module only.

This way the Modular specific function is build.all this is called in the business level and sequentially called in Script level.

so the structure is…

Driver Script-consists of high level business level statements…

Business Module-Consists of generic functions from generic function library or business specific functions from Business function library.

Common Functions:-Consists of all level of common functions.

Business Specific Functions: A library where all business specific functions resides.

Recovery Functions: A Function library where all types of recovery functions resides.

Data Table: Set of data for the testing.

{{DEFAULTSORT:Modularity-Driven Testing}}

[[Category:Software testing]]

{{comp-sci-stub}}