The contents of the Internet become more and more active. Ideally the functional capabilities of many different Web sites are integrated without any seams. This way, the Internet is going to change from a media space for documents and simple transactions to a comprehensive infrastructure for services that can become extremely complex.
The technological foundation of this vision are the so called Web services.
Web services are program modules or black box functions that are provided on the Internet via protocols and can be compiled to from complex Web applications or portals. Companies can snap Web services for accounting, inventory, logistics, marketing and much more into their B2B Web systems to create dynamic, customised business Webs, or B2B Web marketplaces. Web services can also serve as ideal basis for application service providing (ASP), a phrase which denotes the offering of dynamic on the Internet in exchange for payment.
QA for Internet Applications
Quality objectives or requirements for Internet applications go beyond those for “classical” or conventional software development. Although comparable requirements for functional accurateness still hold true, special requirements or challenges result from the potential usage of an Internet application by any user. Especially high demands are placed on the user-friendliness (usability) as well as the performance and reliability of the applications.
Many Internet applications are targeted towards a very heterogeneous group of users. The intention of a bookseller with his shop application is to be open and accessible to every user able and willing to spend money. This also means that only few general statements can be made with any certainity about the user’s expectations, his education, his computer knowledge and many other factors relevant for the design of screens and business processes. The result of this is the quality requirement that the look and feel of the Internet application be as intuitive and generally understandable as possible. In contrast to cassical application development, it cannot be assumed for Internet applications that idiosyncratic or otherwise unusual features in the functionality or the interface can be compensated by user training, manuals or help texts. The importance of this quality requirement therefore becomes corespondingly greater.
Performance and reliability
Due to the heterogeneous user community and the influence of unpredictable events such as current media reports, predictions of the expected number of users that might concurrently use an Internet application become especially difficult. The press or announcements in the Internet can unleash a stampede of users on certain websites or web applications. Quality requirements with respect to performance and reliability must therefore be given greater emphasis so that Internet applications can handle an assumed number of concurrent users and can also react in an acceptable manner to a much greater number.
The provision of an application in the Internet for different system platforms is made easier by the use of standardised protocols. At the same time though, there are new challanges in the software area (e.g. operating system, browser, user settings). The hardware and software configurations of users in the Internet can only be controlled in exceptional cases. The spectrum ranges from computer “amateurs” who use a pre-configured browser with standard settings on their PC to computer “experts” who use an uncommon, perhaps even self-developed, browser with many user defined settings. A quality objective is therefore the operability of the application in all pre-defined target environments of potential users. Installation controll tests must therefore carried out in the different system configurations. Representative of this type of application are banking applications in which the user prepares his transactions offline and only goes in online modus in order to transmit his transaction data. Experience has shown that specifics of the user environment often lead to unexpected system behaviour. When such system reactions occur, the user always places the blame on the software supplier.
The type of user access to the Internet is also diverse. A firewall is usually integrated into the system architecture of users who access the Internet from their workplace. Private users often use a dial-up access via modem and a local provider. Altogether this results in quality requirements concerning user access to an application. Every potential user of the Internet application should be able to use his preferred type of access.
The danger exists that unauthorised users access information and Internet applications in an improper manner. The quality objective here is to provide all products and services only to the authorised user. At the same time, all unauthorised users must be denied access.
The quality objective of up-to-dateness can be seen from both a contextual and a technical point of view. In the Internet, the user expects up-to-date content of an application and a modern and at all times up-to-date presentation of that content. Due to the short innovation cycles for technology and content – one speaks of seven Internet years per calendar year – a continual update of Internet applications is necessary. Links which today lead to user to associated companies or complementary products might be a dead end tomorrow. User interfaces which today appear “dynamic” and “cosmopolitan” might look “frumpy” tomorrow.
Each of these aspects can entail different activities and objectives for QA in Internet projects. As a result of the extremely short development cycles in the Internet area, these tasks and activities must be solved in a pragmatic way. Even though in general the functional scope of Internet applications is less than in conventional development projects, this is essentially more than compensated by the multitude of technical chalenges in the automation of testing.
Usability se refera la capacitatea unui produs de a indeplini obiectivele utilizatorului care il foloseste. De exemplu, o telecomanda este sau utilizabila, daca scopul pentru care a fost ea construita este usor identificat de catre utilizatorul ei, iar folosirea propriu-zisa este facila, intuitiva si il satisface pe utilizator.
In informatica si design web, termenul se foloseste pentru a descrie calitatea unui site web sau a unui program de calculator de a fi usor de folosit, intuitiv. Cel mai frecvent, utilizabilitatea este definita de trei factori. Acestia sunt:
- Eficacitatea – cat de bine poate fi indeplinita o sarcina sau o actiune pe un site;
- Eficienta – cat de usor si cat de repede poate fi dusa la indeplinire sarcina data;
- Satisfactia utilizatorului – Perceptia asupra facilitatii cu care s-a realizat sarcina respectiva.
Ce scop au testele de usability?
Scopul acestor teste de usability au ca scop evaluarea acestor trei elemente in vederea inbunatatirii site-ului sau programului testat si a il face mai accesibil si ma usor de folosit.
In trecut, testele de usability erau adesea folosite doar de companiile mari, care isi permiteau sa aloce bugete importante acestei activitati. Pentru efectuarea testelor era nevoie de un laborator de testare prevazut cu o camera de observare dotata cu un geam uni-directional, multiple camere video care sa inregistreze atat actiunile utilizatorului cat si modul in care acesta foloseste obiectul testat. Era necesara recrutarea mai multor persoane pentru a testa produsul, iar costurile, cel mai frecvent se cifrau la mai multe zeci de mii de dolari.
Retineti urmatoarele subpuncte:
- Daca iti doresti un site web perfect functional, testele de usability sunt obligatorii. Dupa ce ai lucrat asiduu sa construiesti unui site, chiar daca proiectul a fost de scurta durata, nu mai esti capabil de o opinie obiectiva despre facilitatea utilizarii acestuia.
- Daca testezi un site folosind o singura persoana, este mult mai bine decat daca nu-l testezi deloc. Chiar si cel mai prost organizat si implementat test de usability iti va dezvalui elemente pe care le poti inbunatatii la site-ul tau.
- Testand un site folosind o singura persoana, in fazele de inceput ale proiectului este mai indicat decat sa testezi cu 5 persoane in faza finala a acestuia. Teste frecvente, pe parcursul dezvoltarii proiectului iti vor permite sa implementezi rapid comentariile obtinute, si sa reduci cheltuielile ulterioare de optimizare.
- Importanta data recrutarii persoanelor care sa testeze este mult supraevaluata. Da, este indicat sa faci testele cu persoane cu profile similare cu cele ale utilizatorilor finali ai site-ului tau, dar testarea frecventa si facuta in fazele initiale ale proiectului iti vor aduce mult mai multe avantaje.
- Scopul testarii nu este de a demonstra ca o teorie este adevarata sau falsa sau un design este bun sau nu, ci este acela de a iti da informatii. Informatiile obtinute in urma acestui proces, corelate cu experienta ta profesionala si strategia pe care o ai te vor ajuta sa alegi cea mai buna varianta.
- Testare este un proces repetitiv. Nu este o activitate punctuala, pe care o faci o singura data inainte de lansare. Realizezi un site, testezi, implementezi optimizarile si testezi din nou.
- Nimic nu este mai presus decat reactiile unei audiente reale. Spre finalul proiectului, cand rezultatele testarilor nu mai dezvaluie elemente majore pe care sa le poti inbunatatii, poate fi util sa lansezi noul site in paralel cu cel existent si sa iti inviti vizitatorii sa comenteze noile functionalitati sau noul design.
Differences in Functional Testing
The task of testing the accurateness of functions is explained by additional influencing factors such as diverse browsers and browsers settings. The heterogeneous hardware configurations as well as the different possibilities of Internet access and consequently application use must already be taken into account when testing the individual user functions. These additional factors place increased demands on the methodical approach and qualifications of testers. In addition, individual tests should be repeated in diverse environments in order to discover differing behaviour, for example in different browsers. Further relevant factors are the cache behaviour of the browsers, security settings and the activation of functionality such as Java Script or the support of ActiveX components. This is an important area in practice because many environment properties which actually should not influence the application do indeed have an effect. Examples are the inadequate representation of objects using a certain screen resolution, failure of the application when using a certain browser and problems executing Java scripts on certain operating systems, just to name a few.
A decision matrix can help when analyzing the factors to tested. The parameters in the matrix are the values to be converted in testing (browsers X, Y and Z; operating systems A, B and C; and further influencing factors) and the estimated risk for combination of values. In essence, the risk for any combination of values can be calculated as the product of the probability that a failure will occur and the costs associated with that failure. The result is a matrix with weighted pairs of values which can be used as a basis for decisions on test case specification and the repeated execution of tests.
Functional test cases, for example, are repeatedly executed on different platforms of the Internet application with different browsers. This places increased demands on test automation.
Flexible test tools lend a helping hand here. Many capture-playback tools now allow a test to be recorded using one browser (e.g. Internet Explorer) and replayed in other browsers (e.g. various versions of Netscape Navigator).
Testing with Google Optimizer
Google Optimizer!? Are there any issues present? Google has an Website Optimizer tool for website testing and optimization. This tool allows you to increase the value of the websites and of course the traffic. As it stands, the experiment URL we conduct the experiment on splits traffic between the original page, the a page and the b page. This is great when directing people to the page they want to be in the experiment.
However, if they have a link on a website that points to the URL where the experiment URL is, there is no way for users to go only to the control page. So for example, someone clicks on a link, and sees page B. But what if the original page has crucial information and navigational content? Users will just be frustrated and leave.
Is there any way to specify whether we forward them or not? Or is it
all or nothing, basically?
To solve this, one must create a mirror page of the original page they are testing. The problem is that adjusting PPC campaigns to this new URL lowers their quality score. If they point a PPC Campaign to a test page, will the Quality Score be for the original page, Page A or Page B?
My guess is the original…
With other words, there might be an issue present…
Let’s say we’ve got two landing pages being tested: index.html and index2.html
Index.html is obviously our regular home page and serves as the control. index2.html is a copy of that homepage with some changes. The most significant change is that the number of links and access to the entire site is limited when you’re on index2.html. So, in essence, index2.html is the homepage of a little mini-site that keeps new visitors quarantined unless they take the desired conversion action.
The problem arises when they take the conversion action and are redirected to the main site. The whole site works for them as long as they don’t click the home button. But as soon as they click the home button the GWO script intervenes and sends them back to the index2.html instead of permitting them to go to the real home index.html.
Is there any way to stop this from happening? It’s basically interfering with our preferred traffic flow and is no doubt frustrating our visitors.
Hmm not easy, but how about create an index3 page which is a clone of your normal homepage but doesn’t have the GWO tags on it. Then after the use converts, you redirect him to index3 page.
So…running an AB test but for certain people, always having them go to A (and essentially not partipcate in the experiment), you can add some custom webserver code that only add the GWO tags if the visitors meet certain conditions (e.g. if they come from such and such a referrer, don’t add the tags).
Read more here: Software QA
Classical Test Levels
Classical Test Levels
In software quality assurance the principle of “divide and conquer” has asserted itself just as in software development. In a software development there is the differentiation between the development of individual classes or modules, the integration of the classes and modules into an application with neightbouring applications, for example via interfaces or common data.
Each of the different development and integration phases necessitates appropriate quality objectives or a different perspective. As an appropriate response to the different objectives in a process as a whole, the entire QA process is divided into different test levels. The different QA objectives, responsabilities, methods, and tools are asigned to these test levels. The figure shows one possible partitioning of the test objectives into test levels as practised in many enterprises today.
In the first level, the documentation test, the accurateness of specifications and design decisions are examined. The focus is on functional and technical design documentation, for example the results of an object-oriented analysis or design. The design documentation is subjected to a test in the form of a review with the participation of developers and domain experts.
In the developer test the developer or a tester from the development team tests the correct implementation (coding) of the specifications. During functional testing the acurateness of the implemented functions are tested from a user’s point of view.
Functional testing can be further divided into functional system testing, which focuses on the individual functions of an application, and functional integration testing (application testing or integration testing in the small), which tests the correct integration of the individual functions within an application. Sometimes an overall integration test (integration test in the large) is also carried out in which the correct integration of the application with other complete systems is verified.
Non-functional testing takes place in parallel to these levels, concentrating on non-functional quality characteristics such as performance, fault tolerance, reliability, usability and instability.
You can read more here: QA for Internet Applications