What is a checklist when testing software

archive

A solid and efficient test plan needs one thing above all: lots of information. Experience has shown that these can only be obtained if everyone involved in the project is spoken to before the first test runs. Companies should therefore let programmers and testers work in a team, as companies that make a living from software development do successfully today. If this is not possible, at least one tester should be present at every meeting of the developer and the project manager (application sponsor). In this way, the testers can gain a better understanding of the application and the ideas of the sponsor beyond the pure specifications as well as develop a closer relationship with the other project members. This helps to select the appropriate test cases even before test scripts are written.

General information:

• When does the web application go live and should it take place gradually?

• What is the URL / IP address of the site to be tested?

• When is a test considered to have failed? (Which server load and response times are still permitted?)

• How many web pages does an average user visit when logged in or just browsing the website?

• Are the dynamic pages changing very quickly?

• Is the website modified on a daily basis?

• How often are pages added or changed?

• Are there already users?

• Will the site also be needed outside of working hours?

• If the site is already live, when is there a lot or little traffic?

Test types

• Have functional tests been carried out with the website?

• Are email accounts involved in the test? If so, do you want notifications to be sent during the test and are there test accounts for this?

Capacity planning

• What bandwidth is available for testing the website?

• How much bandwidth does a user need on average?

• Are there many static elements (images)?

• What throughput is expected?

• How many "accesses per second" should be possible?

• How many simultaneous users are planned?

• What is the likely percentage of logged-in and non-logged-in clients on the site?

Login information

• Can many users use the same login data and still bring the site under load as if each had their own login data?

• Are there usernames and passwords for stress tests?

• Can problems arise in the transactions if many users use the same login information?

• Are there any shopping functions and is there a credit card number available for testing?

• Can several users have one IP address and still log in at the same time?

User behavior

• How fast does a real user click through the website?

• Are users getting a lot of content or are they only visiting the site briefly?

• Which pages are viewed most frequently when users are logged in / not logged in?

• Do transactions cause dynamic pages to change for other users when they log on with the same information?

• Are there any other characteristics that define a real user?

• How many scenarios need to be tested at the same time to realistically simulate the site?

• Which scenarios are these?

• Can the user use the browser cache?

Technical details

• Does the site call Java applets, Java on the client, streaming media or special plugins?

• Which is the media server and what do the clients support (Javascript, VB Script, Active X etc.)?

• How do you deal with the state between page changes (session state).

www.computerwoche.de/go/

* 78619: Requirements Management;

* 72680: Make software development more productive.

Do not let go

Testers should also use these meetings to ask their specific questions (see the "You need to ask" box). If a meeting of all parties is not possible, it is advisable to arrange individual appointments with the developers and the sponsor. In addition to the details of the application, the typical user behavior, including logging in, and the estimated system load must be discussed on these occasions.

The next step is to plan the resources. It should be considered whether the required hardware and software such as test tools can also be leased and whether relevant products already exist in-house. The quantity structure for a load test is ultimately determined by the number of users who are to access the web application at a certain point in time.

Precise resource planning

So the first task is to find out how many users your existing hardware supports. The values ​​for clients and servers can be determined with test tools for web applications. If you come to the conclusion that it is better to carry out the tests separately in a data center, allow sufficient time for the configuration of the test environment. This effort belongs as the resulting additional costs are noted in the test plan. In addition, the testers need the support of the IT manager in the data center to quickly resolve technical problems during the tests.

The test team should also use the knowledge of the people in IT and in the business area who have to do with the web applications. For example, there may be experienced employees who help with the profiling of the visitors to the website. Others could monitor the servers, network (bandwidth), and database during the tests. You should be contacted if the website's systems crash during the tests. A copy of the network diagram must also be requested, which must represent all devices, operating systems, web, application and database servers, load balancers, routers, etc. It must also be clarified what happens to the data that is generated during the test runs. Can the tester delete them or a specific person in the company?

Accurate and realistic time management is part of the test plan, as employees, for example, have vacation or are not available for other reasons. Communication in the team is also important. Regular meetings, telephone conferences, instant messaging and chat rooms are ideal for this. Visual tools that show the project status and roadmap are also helpful for everyone involved. After all, the testers need management support. If they have a clear idea of ​​the tests from the start, the chances are good that they will support the project as it progresses. It is therefore important to tell the company management exactly what help is needed, what project flow is planned and what those involved are doing. Later you should inform them regularly about the current status, share the team's successes with them, but also let them share in the risks. If this succeeds, tests and the quality management of applications can play a leading role in corporate strategy. (as)