Web quality

1. Web quality Luciano Baresi Politecnico di Milano – Dipartimento di Elettronica e Informazione Piazza L. da Vinci, 32 – 20133, Milano (Italy) baresi@elet.polimi.it

2. Who am I? • Research positions • Associate professor at Politecnico di Milano (Italy) • Visiting positions at • University of Oregon (USA) • University of Paderborn (Germany) • Professional Activities • Co-chair of GT-VMT 01, ICECCS 02, UMICS 03 • PC member of several conferences (ICWE 04) • Co-founder and senior partner of INQuaS www.elet.polimi.it/~baresi Web Quality - Buenos Aires (Argentina) July 21-25

3. Politecnico di Milano • The oldest technical university in Italy • One of the oldest in Europe • 5 schools • 1000 faculties • 25,000 students Web Quality - Buenos Aires (Argentina) July 21-25

4. Quality

5. A definition • A methodological approach to the analysis and management of all company processes • This activity aims at • Reducing wastes • Improving products and services • Improving processes We all know what quality is Web Quality - Buenos Aires (Argentina) July 21-25

6. Different perspectives • Quality is quality but different roles have different views. For example • Stakeholders • They “see” the business • Users • They want to “use” the system • Developers • They must develop and maintain the system Web Quality - Buenos Aires (Argentina) July 21-25

7. Process quality We aim at introducing special-purpose characteristics to control Costs Time-to-delivery Quality Competitiveness Product quality We aim at products with particular quality indicators no matter of the process behind them They must be able to match explicit and implicit requests from customers Process quality vs. product quality Web Quality - Buenos Aires (Argentina) July 21-25

8. Quality & development process RUP Web Quality - Buenos Aires (Argentina) July 21-25

9. Quality dimensions • Usability • Dependability/Reliability • Correctness • Robustness • Scalability • Performability • Security internal vs. external properties Web Quality - Buenos Aires (Argentina) July 21-25

10. Web applications (at least their architectures)

11. Web applications vs. Web sites Web Quality - Buenos Aires (Argentina) July 21-25

12. Client internal users Firewall Internet Internal network SMTP server DB server Web server Why Web applications? N-tier architecture • The Web is heterogeneous by definition • Too many technologies (Applet, Servlet, JSP, ASP, XML, …) • Much more importance to presentation and communication • Distribution • … Web Quality - Buenos Aires (Argentina) July 21-25

13. Heterogeneity • Components • HTML • Scripting languages • Databases • Multimedia contents • Expertise • System designers • DB administrators • Designers • Programmers • Testers • Development and maintenance are complex (more complex?) Web Quality - Buenos Aires (Argentina) July 21-25

14. Client/Server • Entities that are logically distinct, but linked by a network, that work together to obtain a given task Requests Services Web Quality - Buenos Aires (Argentina) July 21-25

15. Logical components • Presentation • User interactions • Data management • Access, persistency, queries • Application logic • Business oriented computations • In some cases some of these elements can be absent • Embedded systems have no presentation layers Applicationlogic Data management Presentation Web Quality - Buenos Aires (Argentina) July 21-25

16. Data management Logic Presentation Logic Logic Presentation Presentation Client and server responsibilities Data management Data management Data management Data management Data management Server Logic Logic Logic Presentation Network Client Presentation Presentation B C D E A Web Quality - Buenos Aires (Argentina) July 21-25

17. Client and server responsibilities • Distributed presentation • The server owns all the knowledge • The client only interacts with the server • Example: HTML form (no control on the quality of data) • Remote presentation • Presentation is fully in charge of the client • Distributed logic • The logic is partly on the server and partly on the client • Remote data access • Presentation and logic are on the client that interacts with a server to access data (SQL interface) • Distributed database • The functionality to manage data are partially on the client and partially on the server (e.g., Distributed Relational Database Architecture di IBM) Web Quality - Buenos Aires (Argentina) July 21-25

18. Fat client vs. Fat server • Clients are fat if the implement part of the application logic (C, D, E) • Why fat clients • The system can handle user inputs more quickly • The system interacts with the user with a finer granularity • Different clients can implement interfaces that are specific to different users • The system is more scalable Web Quality - Buenos Aires (Argentina) July 21-25

19. Fat client vs. Fat server • Why not fat clients • Interactions with the server can become too frequent during complex computations • Servers could better control data access if they control the computation • We loose data encapsulation • The client must know in detail how data are organized on the server • System management and maintenance become more complex • Clients and server must be both updated • It would be easier if we could update only the server Web Quality - Buenos Aires (Argentina) July 21-25

20. Three-tier architectures Intermediate component Server • In the ideal model the mid component contains all the application logic • In many real cases the logic is also spread on client and server • This way we can distinguish between presentation and application logic • Different distributed data sources • Different client types Client Application logic Data management Presentation Web Quality - Buenos Aires (Argentina) July 21-25

21. Client Another example Order Entry Customer Service Scheduling Shared Application Services Credit Check Customer Information Distribution Service Inventory Manager Data Sources Credit Service Customers Distribution Inventory Web Quality - Buenos Aires (Argentina) July 21-25

22. Server Client From two-tier to n-tier 2-tier Application logic Data management Presentation Server Client Intermediate component Intermediate component Intermediate component n-tier Web Quality - Buenos Aires (Argentina) July 21-25

23. Computational models Computational model Host/terminal model Models based on Distributed computation Models based on file transfer Client/server Peer-to-Peer Models based on events Object-Oriented Web Quality - Buenos Aires (Argentina) July 21-25

24. What can we do?

25. Basically, we can • Measure • We “understand” the quality of our applications by measuring it • Several different measures • Analyze • We “understand” the quality by studying the artifacts we have • Interesting, but complex • Test • We can “understand” the quality by trying with some special executions No magic solutions !!! Web Quality - Buenos Aires (Argentina) July 21-25

26. Design for testability

27. proc foo ( ) x: integer; y: char; begin xxlskd ; xxl; Testability Interesting properties Direct control over source code (usually not feasible) ? P Implication Definition of analysis models Model property Algorithm control ofproperty P’ ? P´ Web Quality - Buenos Aires (Argentina) July 21-25

28. Important factors • Systems can be tested more easily if they: • Work decently (operability) • Can be controlled (controllability) • Can be observed (observability) • Do not add useless complexity (simplicity) • Are documented consistently and completely (understandability) • Are well-known (suitability) • Are stable (stability) Web Quality - Buenos Aires (Argentina) July 21-25

29. Five dimensions • Requirements • We must consider the way we represent them • Design • We should anticipate as many constraints as we can • Implementation • Test oracles should be “added” during the implementation • Test • We should identify test cases as soon as we can • Documentation • Better testability if we have good documentation Web Quality - Buenos Aires (Argentina) July 21-25

30. Some very preliminary comments • Design projects as simple as possible • No added (useless) complexity • Use/add contracts (assertions) to our components • Maximize the visibility of all products • Consider comments and documentation • Write “standard” code • Privilege formal (semi-formal) notations instead of informal models • Is this true with the Web? Web Quality - Buenos Aires (Argentina) July 21-25

31. noweb Web Quality - Buenos Aires (Argentina) July 21-25

32. Test and analysis

33. Why test and analysis • Software is never correct • No matter of the domain • No matter of the techniques we use • Any software must be verified/validated • Test and analysis are • Important to control and assess the quality of products • But impact on the process • Usually expensive • Difficult, but interesting • Good compromises Web Quality - Buenos Aires (Argentina) July 21-25

34. IEEE terminology • Error • What causes the problem (deviation) between the product and the ideal program • Errors and faults are not consistent • For example, typos, cut&paste, wrong requirements • Fault • Program elements that do not correspond to the expectations • Faults do not respect locality and are not consistent with failures • For example, the program has a multiply operator instead of a sum operator • Failure • Behavior not consistent with system specification • For example, 4 + 3 = 12 Web Quality - Buenos Aires (Argentina) July 21-25

35. Properties • Process oriented (internal) properties • Reusability • Maintainability • Modularity • External properties that can be verified • Interoperability • Timeliness • External properties that cannot be verified • User-friendliness • Usability • Dependability properties • Correctness • Robustness • Safety • Reliability Web Quality - Buenos Aires (Argentina) July 21-25

36. Dependability Robust but not safe: we can have catastrophic errors Safe, but not correct: We can have “light” failures Robust Reliable Safe Correct Reliable, but not correct: We can seldom have failures Correct, but not safe or robust: the specification is not enough Web Quality - Buenos Aires (Argentina) July 21-25

37. Validation and verification Formal description Requirements system validation verification Include usability test, user feedback Includes test,inspection, staticanalysis building the right system building the system right Web Quality - Buenos Aires (Argentina) July 21-25

38. Validation vs. Verification • If we say that the page must display quickly, we cannot verify the property, but we can validate it • If we say that the page must display in 30 seconds, we can verify it. Web Quality - Buenos Aires (Argentina) July 21-25

39. The real problem property Decision procedure yes/no program Correctness properties are undecidable Web Quality - Buenos Aires (Argentina) July 21-25

40. We must settle for some kind of inaccuracy to be able to deal with the problem What do they offer? Optimistic approximation (testing) Sample theinput space Pessimistic approximation (analysis, proof) Perfect verification Simplified properties Web Quality - Buenos Aires (Argentina) July 21-25

41. Impact of the software type • The software type and its characteristics impact test and analysis activities in different ways • Different emphasis on the same property • Timeliness • “Correctness” • Different properties • Usability • User-friendliness • New techniques • Presentation • Navigation Web Quality - Buenos Aires (Argentina) July 21-25

42. Principles • The basic principles are • Sensitivity: it is better to fail every time than sometime • Redundancy: we should make our intentions explicit • Partitioning: divide et impera • Restriction: we should try to reduce the scope • Feedback: we should use the experience to improve the process Web Quality - Buenos Aires (Argentina) July 21-25

43. Sensitivity • Better to fail every time than sometimes • Consistency helps: • A test selection criterion is better if any selected test gives the same results, that is, if the program fails with a given test, it should fail with all tests selected with that criterion • For example, deadlock analysis at run-time is better if it does not depend on the machine, that is, if the program fails on a machine within a given execution, then it should fail on all machines within that execution Web Quality - Buenos Aires (Argentina) July 21-25

44. Redundancy • Make decisions explicit • Redundant control can increase the capability of capturing errors in advance or more efficiently • Static type check is redundant with respect to testing, but it can solve many problems in advance • The validation of requirements is redundant with respect to the validation of the final product, but it can solve several problems in advance and more efficiently • Test and model checking are redundant, but they are used together in some cases to increase the confidence on the right behavior of the product Web Quality - Buenos Aires (Argentina) July 21-25

45. Partition • Divide et impera • Difficult problems can be treated by partitioning the input space • Criteria for both functional and structural test selection identify meaningful partitions of the input space • Verification techniques partition the input space by grouping data that are homogeneous with respect to the properties that we want to prove Web Quality - Buenos Aires (Argentina) July 21-25

46. Restriction • Simplify the problem • Clever restrictions can make problems that are difficult (and undecidable) simple and tractable • In some cases a weaker property can be easier to verify • For example, we cannot demonstrate that pointers are used in the right way, but if we use Java we can impose it easily • In other cases, an heavier property can be easier to verify • For example, in general we cannot demonstrate that we do not have type errors with languages that have a dynamic type system, but we can demonstrate it if the language is statically typed. Web Quality - Buenos Aires (Argentina) July 21-25

47. Feedback • Fine tune the development process • Learn from the experience: • Checklists are built on errors discovered in the past • The way errors are classified can help define meaningful criteria to select test cases • The mechanisms to revise the process are based on the fact that we must improve the process to improve the product Web Quality - Buenos Aires (Argentina) July 21-25

48. Test and analysis in a development process • Activities related to quality control and types of development processes • Degrees of freedom and compromises • How to balance budget, risks, and quality • Error analysis and feedback • Impact of the development process on test activities • Responsibilities of a test group Web Quality - Buenos Aires (Argentina) July 21-25

49. Course outline • Usability • Accessibility • Functional correctness • Testing and analysis techniques • Robustness and scalability • Performance • Security • Test process • Tools • Conclusions Web Quality - Buenos Aires (Argentina) July 21-25

50. Usability