Quality Views

Industry is going through a revolution in what software quality means the success of software  products  [115].  Quality  is  incorporated  into  a  web  application  as  a  consequence  of  good  methodology,  design  and  implementation.  As  depicted  in  the  state‐of‐the‐art  section,  to  ensure the quality of a web application involves the assessment of the required functionality,  but  also  the  assessment  of  the  non‐functional  requirements  (quality  attributes).  The  most  important non‐functional requirements for web applications have been identified in [34] and  are summarized in Table 2 in section 2.4.3.  

Therefore, the quality dimensions for web applications to be ensured in this dissertation are:  functionality  (functional  requirements),  performance,  security,  compatibility,  usability,  and  accessibility (non‐functional requirements). Both automated testing and analysis can be used  to assess these quality attributes. The following sub‐sections identify the most suitable quality  control activities (testing and/or analysis) to assess each of the selected quality attributes. 

4.3.1. Functionality

The  functionality  is  evaluated  to  ensure  the  conformance  to  customer  requirements.  In  the  case  of  the  client‐side  of  web  applications,  the  key  aspect  to  ensure  the  functionality  is  the  web navigation.   Web navigation plays a key role in the overall web experience. The act of navigating from one  page to another by means of web links is known as browsing. To automate the web navigation,  that is, the web browsing, the structure of the web should be identified.   In web navigation, users typically interact with data forms. These forms are used to submit the  input data to the server for processing. Forms are composed by the following kind of fields:  ‐ Text fields. These elements allow the user to input of a single line of text.  ‐ Textarea fields. These elements allow the user to input a multiple rows of text data.  ‐ Checkbox buttons, multiple selection elements. These buttons are usually shown on screen  as square boxes that can contain a white space (for unselected) or a tick mark or square  (for selected). 

‐ Radio  buttons,  single  selection  elements.  These  buttons  are  usually  shown  on  screen  as  circular holes that can contain a white space (for unselected) or a dot (for selected). 

‐ Select fields. These elements allow the user to choose one or more values from a list.  ‐ File fields. These controls allow the user selecting a local file and uploading it to the web 

server. 

‐ Buttons. These controls provide a way to trigger events. Some special types of buttons in  web forms are the reset button  (used  to clear the form) and  the submit  button (used  to  take an action, typically send the form to the web server). 

The input data is processed by the server, and as a result, some output data is returned to the  client.  These  output  information  can  be  shown  to  the  user  using  forms  too,  although  this  option  is  not  very  common.  It  is  usually  displayed  using  the  HTML  capabilities  to  render  information using document body elements. 

In  the  communication  of  client  and  web  servers,  it  is  very  important  the  concept  of  web  session. HTTP is a stateless protocol, so the server does not retain information or status of the 

 

clients  during  multiple  requests.  HTTP  cookies  are  employed  to  implement  web  sessions.  A  cookie is an object created by a server‐side and stored at the client (typically, in the disk cache  of the browser) [127]. Cookies are used by the server‐side program to store and retrieve state  information associated with the client, i.e. to keep the web session.  All in all, the automation of the web navigation is carried out by exercising the SUT using real  web browsers, where input/output data and session is managed. Therefore, automated testing  will be carried out to assess the functionality of web application in this dissertation.  

4.3.2. Performance

Web performance is critical because users do not like to wait too long for a response to their  requests. Web performance testing should be considered as a continuous activity to be carried  out in order to tune the system adequately [34].   Effective performance testing cannot be carried out without using automated test processes.  There is no practical way to provide reliable, repeatable performance tests without using some  form of automation. Therefore, performance testing should be part of this dissertation.   The aim of automated performance testing is to simplify the performance testing process. This  is normally achieved by providing the ability to record end‐user activity and to render this data  as scripts. After that, these scripts are used to create load testing scenarios which perform the  actual  performance  tests.  Therefore,  the  testing  R&P  process  can  be  used  to  automate  the  performance testing process since record scripts can easily be rerun on demand (playback). 

4.3.3. Security

Web security assessment should provide evidences that a web application is protected against  hostile  attacks  and  malicious  inputs.  The  heterogeneous  web  nature  together  with  the  very  large number of possible users makes web applications more vulnerable than traditional ones  and  security  assessment  more  difficult  to  be  accomplished.  There  are  several  approaches  to  carry out security assessment: 

‐ Black‐box testing takes an external perspective of the tested object. Tester only knows the  inputs and outputs of the application. It is a good approach to anticipate attacks, because  it proves the application from the attacker's perspective. 

‐ White‐box  testing  is  a  more  exhaustive  approach  because  it  needs  to  look  into  the  application code to find security weaknesses. 

‐ Static  analysis  run  simple  text‐based  searches  for  vulnerability  patterns  in  source  code,  recursively analysing the code base for security defects and then generating a report.  This dissertation is focused in the client‐side of web applications. Therefore, the business logic  code is not available to assess, thus white‐box testing and static analysis are not suitable to be  automated.  Hence,  the  automation  of  black‐box  security  testing  will  be  the  technique  to  be  employed. 

4.3.4. Compatibility

As  depicted  in  the  state‐of‐the‐art  section,  compatibility  assessment  tries  to  find  uncovered  failures  due  to  the  usage  of  different  web  server  platforms  or  client  browsers.  Since  this  dissertation is focused in the client‐side of web applications, compatibility assessment will be  focused on client browsers.  

 

Web  compatibility  in  the  client‐side  is  achieved  writing  standard  HTML/CSS  which  can  be  rendered by in any browser. Therefore, the automation of compatibility in this dissertation will  be  achieved  by  evaluating  the  accomplishment  of  these  client‐side  elements  (HTML,  CSS)  by  means of automated static analysis. 

4.3.5. Usability

Usability  is  defined  as  the  degree  to  which  users  can  perform  a  set  of  required  tasks.  Web  applications  have become a standard and cross‐platform means  to communicate  people and  make businesses on Internet. Brink et al claims that “high usability is a key factor in achieving 

maximum return on information technology investments” [9].  

Therefore, web usability may determine the success of the application. As a consequence, the  application  front  end  and  the  way  users  interact  with  it  need  greater  attention  along  the  quality control process.  There are different ways to assess web usability:  

‐ Usability inspection involves a designer (or group of them) evaluating the user interface of  a web site based on general design principles or specific lists of guidelines. 

‐ Group  walkthroughs  involves  a  group  of  stakeholders  walking  through  common  tasks  on  the  web  site.  At  each  step  of  the  task,  the  group  identifies  any  issues  in  the  design  and  tracks fixes that need to be made. It is very similar to a usability inspection but it is task‐ oriented, and it often involves non‐designers. 

‐ User  testing  involves  observing  users  performing  specific  activities  with  the  web  site  to  identify  what  problems  they  have  as  they  use  the  site.  A  special  case  of  user  testing  is  “hallway testing”12, which uses a group of users to test the usability of a web application.  ‐ Static  analysis  employs  rules  for  good  design  and  heuristics  to  find  potential  usability 

issues. 

Inspections,  walkthroughs  and  user  testing  are  manual  processes  that  cannot  be  completely  automated by definition. Therefore, static analysis is selected to perform automated usability  assessment in the client‐side or web applications in this dissertation. 

4.3.6. Accessibility

Web accessibility assessment evaluates how well web applications can be used by people with  disabilities.  Web  accessibility  evaluation  combines  different  disciplines  and  skills.  There  are  several scopes of evaluation, from individual web pages, collections of web pages, whole web  sites, or just specific parts of web pages such as tables or images.  

Web accessibility assessment is closely related to the development process since it is carried  out with the purpose of improving or maintaining the web content. There are three main types  of web accessibility assessment techniques [102]:  

‐ Manual  testing,  which  is  carried  out  by  human  testers.  The  types  of  manual  testing  are  depicted as follows: 

o Non‐technical  evaluation  which  are  carried  out  by  non‐technical  evaluators  such  as  content  authors,  e.g.  to  determine  if  the  ALT‐attributes  describes  the  purpose  of  the  images appropriately or if the transcriptions for the multimedia content is correct.        

  o Technical checks which are usually carried out by web developers, evaluating markup  code and document structure as well as compatibility with specific technologies.   o Expert checks (walkthroughs) which are carried out by evaluators who have knowledge  of how people with disabilities use the web and who can identify issues that relate to  the user interaction. 

‐ User  testing,  which  is  carried  out  by  real  end‐users  in  informal  or  formal  settings.  In  general one there are two modes of user testing: 

o Informal  checks,  which  can  be  carried  out  by  non‐experts,  for  example  by  asking  individual persons like friends or colleagues for their opinions. 

o Formal  checks  which  are  usually  carried  out  by  professionals  who  follow  well‐ established usability procedures.  

‐ Automated  evaluation,  which  is  carried  out  without  the  need  for  human  intervention.  There are the following types of automated evaluation: 

o Syntactic  checks.  It  consists  in  the  analysis  of  the  web  application  ensuring  the  correctness of the web content such as checking the existence of ALT‐attributes in IMG  elements or LANG‐attributes in the root HTML elements, and others.  

o Heuristic  checks.  It  examines  some  of  the  semantics  in  the  web  content  such  as  the  layout and markup or the natural language of information.  

o Indicative  checks.  It  uses  statistical  metrics  and  profiling  techniques  to  estimate  performance of whole web sites or large collections of web content. These techniques  are useful for large‐scale surveys, for example to monitor the overall developments in  the public sector of a country. 

Similarly  as  usability,  there  are  accessibility  assessment  techniques  predominantly  manuals  (user and manual testing). Therefore, it is clear that automated accessibility evaluation based  on static analysis is the best choice to be included in this dissertation. 

4.4. Test Process

Once the quality dimensions are defined and following the objectives described in chapter 3,  this section establishes the generic process to automate the quality control activities for web  applications in the client‐side.   Following the guidelines described to asset the functional requirements (see section 4.3.1), the  proposed  process  is  based  on  the  automated  browsing  of  web  applications.  To  perform  this  automation, it is needed to model the navigation of a web site, and then divide that navigation  in independent paths. 

Automation  in  testing  and  analysis  demand  not  only  time  but  also  resources  in  terms  of  preparation and planning. Therefore, automated quality control should be an assisted process.  In order to automate these activities some human interaction is required [94]. Thus, the first  step in the generic process proposed in this dissertation is to establish the correct navigation  structure of the web under test. This step should be done by human the tester or developers  in charge of the quality control of the SUT. It will guide the automation process, since it must  be known forehand the right way of traversing a web application. Quality control activities are  primarily  based  in  comparisons.  As  depicted  in  Figure  16,  the  test  oracles  must  know  the  expected outcome prior to exercise the web system. This also applies to the proposed process 

 

to  automate  the  quality  control  of  web  application  based  on  the  navigation:  the  correct  navigation should be established in order to know what it is right and what it is not. I propose  the following types of modelling the navigation (these models will be described in detail in next  section):  ‐ UML models. UML is the de‐facto standard for modelling and design. Reusing such models  for quality control it is a way of saving time.  ‐ XML files. I will propose a self‐defined XSD schema to model the navigation. Such models  are  useful  in  analysis  and  design,  but  these  kinds  of  files  will  be  richer  than  UML  in  the  sense of these files can contain test data and oracles.  ‐ R&P scripts. This king of input will be useful for finished web applications, or at least when  the web application can be executed. Therefore, this kind of input is useful for operation  and maintenance stages in the SDLF.  Once the navigation structure is defined, I use graph theory to represent the defined web site  navigation. Graph theory is the study of graphs in mathematics and computer science. A graph  is the abstract representation of a set of vertices (vertex or nodes) connected by arcs (edges or  links). A graph is a pair G=(V,E) of sets such that E ⊆ [V]2; the elements of V are vertex/nodes  and the elements of E are the edges/links. The usual way to picture a graph is by drawing a dot  for each vertex and joining two of these dots by a line if the corresponding two vertices form  an  edge  [15].  The  following  table  shows  definitions  useful  to  understand  the  process  to  be  defined.  Table 6. Graph Types  Graph Type  Example  A graph in with the edges have no orientation is known as undirected graph.       In a mixed graph some edges may be directed and some may be undirected.    If the edges have orientation, the graph is known as directed graph (or  digraph) [9]. A digraph is acyclic if it has no cycle. A digraph is strongly  connected (or, just, strong) if every vertex is reachable from every other  vertex, i.e. there is a path from each vertex in the graph to every other  vertex.     In a weighted graph a number is assigned to each edge. This number  (weight) could represent costs, lengths and so on. A weighted digraph is  known as a network. A flow is a network where each node has a capacity  and each edge receives flow[20].   

  A multigraph is a graph in which is permitted having multiple edges (two or  more edges that are incident to the same two vertices) and/or loops (edge  that connects a vertex to itself). If the multigraph is directed, then is known  as multidigraph.    A path P=(V,E) is a graph of the form V={vo,v1,..,vk}, E={eo,e1,..,ek} where all 

the nodes ei are all distinct. If the start node is the same than the end node,  then the path is known as cycle. A walk is a path in which nodes or links may  be repeated. A circuit is closed walk. A trail is a path in which all the edges  are distinct. In a Hamiltonian path each node is visited exactly once. In an  Eulerian trail each edge is visited exactly once. An Eulerian circuit (or tour) is  an Eulerian trail which starts and ends on the same vertex [44]. A  Hamiltonian circuit (or tour) is a Hamiltonian path which starts and ends on  the same vertex.  A tree is a graph in which any two nodes are connected by exactly one path.  In other words, a tree is connected graph with no cycles. A forest is a graph  with no cycles. In other words, a forest is a disjoint union of trees.    All  in  all,  web  navigation  can  be  modelled  by  means  of  a  finite  multidigraph,  that  is,  a  finite  directed  graph (finite set  of web pages and  nodes)  in which  multiple edges and/or loops are  allowed. Any web page of the SUT will correspond to a single node within the graph.  

The  following  step  in  the  automation  process  is  to  define  the  structural  model  coverage  criteria. Due to the fact that a multidigraph is a transition‐based model, the following coverage  criteria can be applied [141]:  ‐ All‐paths: Every path must be traversed at least once.  ‐ All‐states: Every state of the model is visited at least once.  ‐ All‐configurations: Every configuration of a graph is visited at least once.   ‐ This coverage criterion applies for systems with parallel execution. If a snapshot is taken of  such a parallel system during its execution, two or more active states can be found. Each of  these  snapshots  is  called  a  configuration.  For  systems  that  contain  no  parallelism,  this  coverage criterion is the same as all‐states coverage. 

‐ All‐transitions: Every transition of the model must be traversed at least once.  

‐ All‐transition‐pairs: Every pair of adjacent transitions in model must be traversed at least  once.  

‐ All‐loop‐free‐paths: Every loop‐free path must be traversed at least once.  

‐ All‐one‐loop‐paths:  Every  path  containing  at  most  two  repetitions  of  one  (and  only  one)  configuration must be traversed at least once;  

‐ All‐round‐trips: Is similar to the all‐one‐loop‐paths  criterion because it requires a test for  each loop in the model, and that test only performs a single iteration around the loop.  The hierarchy of these criteria types is illustrated in the figure below: 

 

 

Figure 18. Transition‐based Coverage Criteria 

Due to the fact that the graph represents the web navigation of the SUT, the selected coverage  criteria  will  be  all‐paths  coverage,  and  concretely  the  all‐transition  type.  This  criterion  establishes that each edge (web transition) is traversed at least once. As Figure 18 shows, this  criteria  also  implies  that  each  vertex  is  visited  at  least  once  (all‐states).  Therefore,  given  a  multidigraph,  it  is  necessary  to  be  able  to  select  the  different  paths  within  it.  Once  the  independent paths are found, the automation  of the navigation will be performed. As travel  along these paths, testing and static analysis is carried out in each page in order to assess the  selected  quality  attributes  (functionality,  performance,  security,  compatibility,  usability  and  accessibility).  In  testing  terms,  the  model  of  a  web  application  using  a  multidigraph  is  the  system testing level. The evaluation of each independent path can be considered as integration  testing.  Finally,  the  assessment  of  each  single  page  is  the  lowest  level,  i.e.  unit  testing.  This  approach is illustrated in as follows:    Figure 19. Methodology Levels  Thus, the result of the automated assessment of the SUT will be the composition of the results  in quality control for such attributes:  (I) ∑ , , , , ,   Where:  ‐  : Quality control results. ‐ : Functionality results.  ‐ : Performance results.  ‐ : Security results.  ‐ : Compatibility results.  ‐ : Usability results.  ‐ : Accessibility results. 

4.5. Summary

This section has presented the methodological basis of this thesis, which is basically composed  by two parts: on the one  hand the  quality dimensions to  be covered; on the other  hand the 

 

generic  process  to  automate  the  quality  control  for  web  applications  in  the  client‐side.  The  quality goals to be covered are summarized in Figure 20. In this picture, the quality dimensions  to be assessed with software testing are illustrated with red colour background (functionality, 

In document Contribution to the automation of software quality control of web applications (Page 81-88)