a user acceptance test laboratory - an attempt..effective user acceptance testing of their...
TRANSCRIPT
P R E S E N T A T I O N
International Conference On
Software Testing, Analysis & ReviewNOV 8-12, 1999 • BARCELONA, SPAIN
Presentation
Bio
Presentation
Bio's
Return to Main Menu F3
Friday, Nov 12, 1999
A User Acceptance TestLaboratory - An Attempt..
Ulla Hard & Elsmari Gottfrisson
Paper
A User Acceptance TestLaboratory
by
Ulla Hård af Segerstad
Elsmari Gottfridsson
1999-07-12
Organization of the National TaxBoard
TaxationControl
Legal Units
Tax Division
EnforcementLegal Unit
EnforcementDivision
ElectionsPopulationRegistration
Public ServicesDivision
StrategySystems
ProductionUser Support
Secretariat
IT Division
Board Management
1999-07-12
Organization of the ”concern”
ExecutiveOffices
>80
Regional ExecutiveAuthorities
10
Tax Offices(Population Registration)
>120
Regional Tax Authorities5
National Tax Board
1999-07-12
Systems
!Taxation ~ 10 major systems - yearlychanges
!Enforcement 3 systems
!Election 1 system - changes at least every 4years
!Public Registration 1 system
!Diary 2 systems
!Time report 2 systems
1999-07-12
What we lacked
!Common testing method
!Common terminology
!A practical guide
!Test documentation
!Test environement (system)
!Coordination
1999-07-12
What we wanted
!Common acceptance testing environementfor all systems
!Use of standard testing method
!Support for all acceptance tests– method
– administration
– technical support
!Competence centre for end users
1999-07-12
Means to get it
!Localities for– testing
– meetings
!Teaching the test method
!Equipment equal to what exists or will existin the administration
!Personnel to administrate the lab andsupport users
1999-07-12
2000 projektet
����������������
����������������
PC
UnixApplikationer Unix
ApplikationerAdressuppslag
Tidgivare
Cisco router
������������������
PC
���������������
PC
2000-projektetarbetsplatser
RSV produktionsLAN/WAN
NT servrar förskatten
NT servrarför KFM
UnisysApplikationer
Windows NTSNA server
Cisco router
Cisco router
Till SEMAIBM applikationer
Brandvägg
Unixutveckling
Windows NT 4.0Applikationer
Acceptance test system
1999-07-12
Problems encountered
!Resources
!Method acceptance– We have no time to try new methods...
– Understanding acceptance tests
!Organization
!Test data
!I’ve found a great place for testing my code
!There’s a lot of empty rooms here...
1999-07-12
The Road to Success
!A Real Enthusiast
!Management committment
!Established testing method
!Clear responsibilities
!Powers to match the responsibilities
!Resources - Your best friends will be
– testers who gets good support in testing
– project leaders who gets good status reports
1999-07-12
We learned
!To get resources - surf with an importantproject
!Be a bulldog - don’t give up– Repeat Your message everywhere all the time
!Even with inadequate resources you canmake a difference...
1
A User Acceptance Test Laboratory - An Attempt to Organize andCoordinate Testing Resources
by
Ulla Hård af Segerstad Elsmari Gottfridsson
Riksskatteverket Riksskatteverket171 94 Solna 171 94 SolnaSweden Sweden
[email protected] [email protected]
+46 8 7648968 +46 8 7648221
Abstract:A description of how the Swedish National Tax Board went about trying to establisheffective user acceptance testing of their diversified collecion of computer systemsundergoing continuous changes.Our experiences of the problems and threats to this endeavour as well as our opinionon what it takes to succeed in organizing an ΑAcceptance Test Laboratory≅ as wellas an effective user testing are also presented.
2
1. Introduction - presentation
In connection with testing there is much talk about all kinds of testing - except useracceptance test. We, Ulla Hård af Segerstad and Elsmari Gottfridsson, therefore wantto describe how we in a large organisation with diversified tasks and several dedicatedsystems try to establish an effective acceptance testing operation as well as theproblems and threats to that work we have met and still meet.
I, Ulla Hård af Segerstad, studied law and was for a time a tax administrator, butchanged my profession and worked for several years with systems developement priorto about five years ago beginning making reports on quality assurance ant testing.Today I am responsible for quality assurance in a large project, which is supposed toend in the year 2001. I belong to the Swedish National Tax Board=s IT Division.
I, Elsmari Gottfridsson, am an end user, who in 1987 was lent to the National TaxBoard from a Tax Office for six months to help in finding a good way to do acceptancetesting. After twelve years I am still there on the same mission. As the years goes by, Ihave come to realize that it is a lifetimes work to try to create and change the ways todo acceptance tests. I belong to the Developement Office in the Tax Division=sTaxation Unit of the Swedish National Tax Board.
By acceptance testing we refer to the testing done by end users to validate if an IT-system has the required functionality and will be an appropriate tool for the user=swork.
2.The organisation and work of the National Tax Board
The Swedish National Tax Board is a central authority with the responsibility for thepopulation registration, tax administration, enforcement and general elections. Thework is done by a number of regional authorities, who are under the National TaxBoard. Each regional authority in its turn has a number of offices in different places.When talking about the organization of authorities, we sometimes refer to it as Αtheconcern≅ .
The National Tax Board is developing and maintaining a large number of dedicatedsystems for population registration, tax administration, enforcement and generalelections. Certain general systems, like for instance systems for personneladministration and salaries are standard systems bougt from external suppliers.
Some of the tax systems are especially liable to frequent changes, at least once everyyear. Almost every system change must be put into production at a certain date inconnection with a law taking effect. Besides that, the National Tax Board ismodernizing its systems by leaving the batchoriented mainframe systems with differentkind of databases and text-based user interfaces and transferring them to a 3-trierclient/server environment with only one kind of relational databases (Oracle) and agraphic user interface (Windows).
The National Tax Board has since some years adapted a customer-supplier relationshipbetween the different expert divisions (the customers) and the division that providessystems developement, maintenance and IT production (the supplier). The term expertin this report refers to an expert on any of the in different lines of the Tax Board=s
3
work except those in the IT Division. A developed system is to be tested by thesupplier, who after an approved delivery test with a following decision to deliver,delivers it to the Customer for acceptance testing. After an approved acceptance test,the Customer will decide on putting the systems into production.
The 1st of January 1998 a number of changes in the tax legislation, having bearence onseveral systems, was to take effect. The work on the system changes started in 1996 inabout a dozen projects under the joint name of the 98-projects. The intention was toboth adjust the systems to the legal changes and to convert them to the National TaxBoards new technical platform. Elsmari Gottfridsson was given the task to support andcoordinate the acceptance tests of the 98-projects and I was to give her the neededresources from the IT Division.
3. How acceptance testing was done earlier
Shortly before, but independent of the beginning of the extensive 98-projects, there wasan inspection of how the acceptance testing was done in the concern. The intention wasto find a common way to do acceptance tests. Both good and bad examples of testingwere found. This speech will foremost discuss the shortcomings and weaknesses wefound. The effort to amend those were the foundations for our new acceptance testingconcept.
Even though the acceptance testing functioned well in some quarters, it was apparentthat we had no common way to handle the testing. However well a single tester hadworked out tests for his or hers own needs, it must be regarded as more effective fromthe concerns point of view with one common standard and one method of working.
The found shortcomings were all related to the lack of
- testing method- common terminology- practical guide on methods, techniques and means of assistance- description of documentation- identifieng of testing roles- relevant test data- testenvironment- coordination
3.1 Testing method
There were no formal requirements of how to do acceptance testing. This meant thateverybody could test to the best of his or hers ability and previous experiences. Therewas a great variety in how the testing was done from no real testing at all to ambitioustries to have a common way to work in a project. Some testers borrowed the developersPC:s and tested in the system test=s environment, other had created their own acceptance test=s environments which they could reach from their own PCs.
There was no pedagogic description of tests in the concern. Because of that there was nogeneral understanding of or common view on the scope of acceptance testing. Thenotion of what had been tested in earlier tests was vague.
There was frequently a lack of time because people did not understand that the workwith acceptance testing had to start early and go on parallelly with all other activities
4
during the development.
There was not enough understanding of the necessity to plan acceptance tests and writetest cases in good time. Sometimes test cases where not constructed until the beginningof the test.
It could happen that there was not time for acceptance testing at all. The acceptancetesting started with the production. It is true that end users have when questioned saidthat they are relatively contented with the National Tax Board:s systems, but with theexception of the first period after the start of the production. The systems has beenconsidered as not been enough tested.
3.2 A common terminology
Cooperation and communication during developement of a system implies that you usethe same language. Unnecessary misunderstandings, delays and errors arouse becauseof the lack of a common terminology.
3.3 A practical guide
There was no practical guide which described acceptance testning from the Customerspoint of view or gave guidance in methods, testing techniques and means of assitancefor the tester as well as describing the role of acceptance testing and high-lighting itsimportance for the systems= quality.
3.4 Documentation
There was no description of what documents should be produced in support of planning,execution and the following up of acceptance testnings. There was a vivid flora of ownproduced solutions. Some were good and functioned well when used, but there wasnone used by everybody.
3.4.1 OrderA well documented and easy to control order with the Customer=s system requirementsis paramount for a successful acceptance testning. There did not exist an outline forconstructing an order with system requirements. The variations in this respect wereplentiful. There were all kinds from creating systems after verbal personal conferenceswith developers to written detailed system requirements almost in the form ofprogramming descriptions. Not one easy to control system requirements constructed tosimplify the writing of test cases was found in the investigation.
3.4.2 Time planThe lack of documented and well thought-out time plans for acceptance testning has ledto a lot of problems. Among other things we have on numerous occassions overlookedto plan in order to have the acceptance testningen finished and approved in good timebefore the training of end users instead of before the start of production. It is generallydifficult to produce good quality traning in a system which is not ready when you haveto create the training material or even when the training shall take place.
3.4.3 Catalogues of test casesFor the systems which had to be changed every year, testers had created test casesduring the period of maintenance, reusing and modifying them every year. There was nocommon way to document the testcases or establish catalogues of test cases. That meantthat the test cases were not easy to access to other testers in the same testing group.
5
Testers, who were resposible for testing system part in the end of a chain of systemevents sometimes had to create their own test cases to prepare their test data instead ofreusing the testcases that had already been created.
3.4.4 ApprovalWritten documentation to testify that an acceptance test had been accomplished andapproved did not exist. Systems were put into production after a verbal permission orpermission by e-mail.
3.4.5 Following-upThe following-up which is to be done regularily by system owners and those responsiblefor system maintenance during developement and maintenance respectively, wasdifficult or not possible because of lack of documentation of the acceptance testing.
3.4.6 Error reportingTo have control over a systems status, you must have control over how errors found intesting are managed. Usually testers reported directly to a developer. There was nopossibility to overview the errors or their status.
3.5 Roles and responsibilities
There was no document on roles or responsibilities in connection with testing. One hadonly a rather obscure notion of those conditions.
3.6 Test data
One of the weak points of our acceptance testing was the condition of our common testdata base. The National Tax Board has a test data base with about 2000 fictitious testpersons, which practically all systems had to use for testing together with a data basespecific for the tested system . The information in the common data base wasincomplete, the persons ages, the population of different kinds of taxpayers did notmatch the reality, the maintenance of the data base was neglected and the data base hadbeen used in so many tests that its consistence was dubious. The National Tax Boards complex combination of systems with dependencies betweendifferent systems and information transfers to/from external systems had resulted in thatit would be combined with extensive efforts to keep the data base up to date. How tosolve that problem with a reasonable amount of work has been the subject of frequentdiscussions, especially at the prospect of large project. Unfortunately many ambitiousconstructions of test cases failed due to the of lack of apropriate test data.
3.7 Test environment
The test environment has been another problem of acceptance testing. For every systemthere were special routines for setting up a test environment. Agreements were madebetween developers and Customer to create an environment for acceptance tests in theown area of responsibility. There was a risk of leaving interfaces to other systemsuntested.
There was no organization for the coordination of acceptance test at a higher level. Thetotal combination of systems were not really tested until they were in production.
Acceptance testing was as a rule carried through from the tester=s own PC byconnecting to a test database. Sometimes that could not be done. The testers then usedthe developers Pcs when those were unoccupied and did their testing in the system
6
testing environment.
The acceptance testers in he National Tax Board are representatives of the customers butare usually not really end users. It has a long time been the ambition of the Tax board toregularily use end users from the local tax and executions offices at acceptance testingparallelly to The National Tax Boards testers. The test database has in most cases onlybeen accessible from The National Tax Board. End users have therefore been borrowedfrom the local offices to The National Tax Board.
One problem was that there were no PC:s for the borrowed testers. This was solved on aprovisionary basis in that one at the start of testing investigated the absence of theNational Tax Board=s permanent personnel hoping that enough PCs would beunoccupied that day. Sometimes more than one tester had to use the same PC. The timewas not used efficiently and one refrained from using end users as testers because of thepractical problems.
There was no possibility to do acceptance tests of the systems on all kinds of hardwareequipement that existed in the production environment. Acceptance tests were done onthe equipement the tester happened to use. We had no way to know how end users withanother kind of equipement would experience the system.
3.8 Coordination
In spite of our systems becoming more and more dependent on each other, theacceptance testings were mostly organized witin a single system/project. There was alack of coordination between the expert departments. There was no person in the IT-Division with knowledge of the total assembly of test environments.
4 Steps to enhance testing - what we wanted and what we got
4.1 A common room for testing - An Acceptance test laboratory
We wanted a large testing room for several testers to get a better communicationbetween testers, but got a number of rooms with two workplaces in each. Besides, wealso got a conference room, which served as sorting room, archive and storage room.Later a couple of the smaller testing rooms where exchanged for a larger room with sixworkplaces.
4.2 Support for the testing
4.2.1 Method supportThe investigation on how acceptance testing was done within the concern led to aknowledge of the need of a common acceptance testing concept and of commonstandards in the concern. A guide for acceptance testing was produced and confirmed byour General Director in 1996. The new way of working described in the guide was inprinciple in effect from the same day for the whole concern. A smaller informationeffort was initiated where the organization was informed of the content of the guide. Adecision was made that the guide was to be used by the 98-projects and the efforts wereconcentrated on that. All others were to successively change their way of testing on avolontary basis. Main features in the new way of working is to plan tests, write testcases with notating of the expected results, logg the tests and write error reports. Whenthe acceptance test has been approved, the customer shall give a written approval.
7
4.2.2 User supportThe experts= departments have an agreement with the IT department on user support.That agreement was not good enough for testing, where you from time to time havemore specific requirements concerning quick support. A special agreement on supportfor user acceptance test was therefore needed and written.
4.2.3 Tool for the administration of testsThe National Tax Board had no IT-support for test administration. A program, made inSweden, supporting the writing of test cases, test planning, test logging and errorreporting was therefore bought. It was important that the user interface language wasswedish. The program was not really adapted to the method that was to be used. Theadaption continues as we speak. The tool has therefore been of little use. Instead of thetool, document patterns in MSExcel and Word Perfect has been used.
4.2.4 A new test databaseThe National Tax Board:s common test database for the tax systems was old, and as hasbeen said before, in a bad condition. There was a strong demand from everybody in theacceptance testingen to get a new test databas. That was not to be. The connectionbetween different data bases in The National Tax Board:s systems are very complicatedand the construction of a new data base would take too long, there was no time for thatduring the 98-project and there has not been time later either.
4.3 Equipment
The new systems demanded new equipement like PCs, monitors, writers and scannerswhich we of course had to have in the testing laboratory, but we also wanted arepresentative selection of the kind of equipement used by the authorities all over thecountry to test if changes in existing systems would have consequences for the use ofthis older equipment.
4.4 Test environment
An environment very much like the one in production, was set up. According to the factthat many systems were changed and the resources of the test environment were limited,it was not identical with the production environment. We also had some program for thetesting, that did not exist in the production environment. We tried to carefully monitorwhat software was installed in the test environment. We did not always succeed.
4.5 Organization
4.5.1 Test officeA test office was erected to keep order in the laboratory and help testers. It has fourpersons more or less on full time plus a test leader for every project.
< SupervisorA person who had held different managing posts at the The National TaxBoard was appointed as a supervisor. He had a good reputation among allpersonnel, which was essential to obtain necessary support from other units.
< Personnel for1. General officework
keep minutes at meetings, get material to the tests, keep order in the test
8
laboratory, supply testers with access permission, follow up tests2. Test leader
In every project there was an person from the appropriate expert unit as aacceptance test leader. For the group of end user testers of the 98-projects,who were borrowed from local offices, we -Elsmari and Ulla - alternated astest leader.
3. User supportto help the testers with technical problems
4. Contacts with the production unitorder program execution from the IT-productions unit
4.5.2 TestersMainly people from different units of The National Tax Board, were used as testersrepresenting the customer. In addition to them, a selected group of end users fromdifferent local offices were called in to do planned tests for a couple of days at a time ondifferent occasions.
4.6 Usability test
We dreamt of getting the possibility to do usability tests in the test laboratory. We arestill dreaming.
4.7 Alternative use
We realized that the working places in the test laboratory might not be used for testingall the time and thought that it could be used in enhancing the competence by users whowanted to try new equipment or software. For some programs and systems we hadinteractive educational programs on a server or on CD-rom. CD-rom readers, which wehad in the laboratory were at that time not common in the ordinary workingplaces. Wealso had plans to have an Internet connection. Today most personnel have this on theirworkingplaces.
5 Experiences of testing in the acceptance test laboratory
5.1 Surf on a larger project
There were advantages in surfing on the 98-projects. In a project there is a largerinclination for changes and better economic conditions than during the maintenanceperiod. It is easier to get resources for efforts which in fact may be necessary during aperiod of maintenances, but often are pushed forward into the future to save resourcesand sometimes are never realized. This is a real problem in our organization. Concernfor the success of a project failing to reach intended goals and the pressure of timemakes people more open to new solutions and quick decisions.
Large projects, as ours sometimes are, have been critizised for consuming large amountsof resources. They create however lasting values which can be used during maintenance.Experiences of new methods and tools, the creative effort of a large project cancontribute to the developement of the whole organization in a way that is not otherwisepossible. This of course applies to acceptance testing as well as any other work.
9
5.2 Insufficient personnel resources
We got resources thanks to the ongoing mass of projects, but found them insufficient.We had to solve urgent problems for many during a short period of time. There was notenough time to develope our own work. The resources were not enough to give supportto all the testers in their tests. We were often engaged all day in ordinary end usersupport. Planning and progressive work were put aside.
5.3 Method
It is easier to win proselytes for new methods in project, but we did not quite manage toget full acceptance for the new method of testing. The foremost reasons for this were
- the 98-projects consisted of many, partly independent projects which increased innumber during the period
- the acceptance test office could not give enough support owing to the lack of resources
- the projects had not planned their acceptance test in good enough time
- the projects did not have enough resources for acceptance tests
- there were not any good enough tools to aid the administration of tests, which meantthat they were more recource-consuming than otherwise had been necessary
One part of the new method won general approval. This was the routines for managingerror reports. In spite of giving some extra work because of the lack of IT-support, theadvantages of having such a routine was generally recognized.
Several end users from taxoffices from all over the country were borrowed for testingthe results from the 98-projects together in a encompassing way. In this group theintroduction of the new method met with no problems. It functioned extremely well.The reasons for this were that they had no previous experience of testing and thus hadnot been locked in old patterns of work and also that they got full support from thetesting office.
5.4 To test the right things
We could see that not everybody had fully understood the importance of acceptancetesting. In some quarters one was contended with supplementing the system tests withsome single test cases not realizing the importance of testing a whole workflow. In anacceptance test you are supposed not only to test the various functions of the system butalso the whole systems quality as a tool in the daily work.
5.5 Obscure organization
There was no formal organization of the test laboratory with a clear description of rolesand responsibilities. There were no directives or previous experiences to build the workon. One did not try to penetrate which roles were needed. The tasks were performed asthey came up. The organization changed during the course of work. There is still nowritten description - to other people in the concern the organization is still obscure.
5.6 Test data
The bad quality of the data in the common test data base gave us a lot of problems
10
which impeded the testing. We were forced to manipulate the information directly in thedata base to make some testing possible. This gave us problems with other testing andgenerally the problems were worsened by this. The availability of test data controlledwhich test cases could be used. We could not always execute the testcases needed tovalidate the system.
5.7 Reactions from the surroundings
The testers, who had earlier been able to test from their ordinary working placesexperienced a constriction of their freedom. They had then been able to use theirworking time in another way switching between testing and other tasks. The notion ofhaving to change workingplaces for testing and having to plan tests in advance in orderto book a place in the test laboratory was not well recieved. Those who not yet had usedthe test laboratory were especially negative.
In the test laboratory the PCs and the working places are not always used in the sameobvious manner as in an ordinary work room. There are a number of activities going onwhich can not be observed by the occasional bypasser. Test environments are set up, theexecution and termination of batch programs have to be awaited. We have also hadreactions on having unused equipment and rooms in the laboratory. Computers,furniture and rooms are requested by others. We constantly have to repel attacks aimingat emptying the test laboratory in favor for other tasks.
5.8 Keeping the test environment ΑΑΑΑclean≅≅≅≅Developers in need of a better testing environment than the system testing environmentcould provide, tried in different ways to gain access to the acceptance test laboratory toexecute their own tests. We tried to hinder them as they often wanted to install programswe had no control over. Because of the obscurity of roles, responsibilities and powers ofthe test office, we had some difficulty in warding off such attempts.
5.9 Testing laboratory
To collect the acceptance testing in a test laboratory was a new experience for theNational Tax Board. It demanded more resources tha we had foreseen. In spite of thedeficiencies we think it is possible to certify several advantages in coordinating andbringing the tests together.
Advantages:
- having access to a collection of technical equipement with a respresentative selectionof the equipement used in the production environment
- having the possibility to test and easily communicate with other testers
- having the possibility to test commonly different systems or parts of a system andbeing able to immediately follow up transactions between the systems
- enhanced effectiveness of the testing
- to have work places available for testers from other offices
- the creation of a test office where test leaders from different units in the organizationcan meet and discuss questions concerning testing and make decisions together
11
- to be able to offer a variety of support for the testers in the test laboratory
- to be able to coordinate test time plans in the test office
- to get a better control of acceptance testing in general and testing status of a system inparticular
- to have common localities for testing meetings, archive and storage of testing material
-to have built a unique insight in the complex dependencies between the differentsystems in the organization
- augmented security of testing due to better control of the test platform
Some of the disadvantages of the test laboratory may be more specific to ourorganisation:
- that testers are reluctant to leave their ordinary workplace to go to the laboratory fortesting
- the demand of more detailed planning of the tests in good time in order to be able tobook workplaces in the laboratory
- that the organization has to dedicate equipement to testing that can not be used forother work
Our experience was not very surprising. The astonishing thing was that the advantagesprojected so vividly in spite of the defiencies, that is the lack of resources and theunsatisfactory degree of acceptance of the testing method, in the introduction andcarrying through of the work.
6. Deductions - the road to success
Summarizing our experiences from the testing in the acceptance test laboratory, werealise that you need a whole lot of different contributions to create good conditions forsuccessful acceptance testing.
6.1 A dedicated person
As in many cases of braking new ground you have to have a dedicated person, who willinspire others and not easily tire when met with resistance. It is more natural fordevelopers to think testing than it is for the customers end users. Becase of that it ismore importand than in most other cases to have a dedicated person who can push forand sell the notion and concept of acceptance testing.
6.2 The management====s commitment
Without the commitment and explicit support of the management any attempt tointroduce new ways of working which need new resources will fail.
12
6.3 Distinct responsibilities
A distinct description of roles and a matix of responsibilities erected with clearagreements on the interfaces between differens areas of responsibilities both betweenthe persons responsible for tests and the personnel in the test office.
6.4 Authorities to match the responsibilities
Those given the task of introducting new methods and ways of working, must have theauthority to impose them and mould the work to make the transition easier. They mustalso have the authority to protect the testing environment and fend off others who wantto use it for other purposes than originally intended.
6.5 Resources
You have to surveil the projects' and manitenance plans in order to ensure that resourcesare allocated for acceptance testing. Detailed planning of who shall participate and whenhave to be made in good time to let the user lending units take that into considerationwhen planning their work. There must also be enough personnel resources to givesupport to the testers.
6.6 Decided common method
There must be a decided common test method to be used by all persons working in thetest laboratory, otherwise it is difficult to give sufficient support to everybody.
6.7 Rules for the testing laboratory
From the beginning a set of rules concerning the work and environment in the testinglaboratory must be decided on in order to avoid unnecessary conflicts. There should berules for booking the workplaces, for installing hardware and software, giving accesspermissions to testers and making decisions in case of conflict with coordination,booking priorities and so on.
7. The future
We hope that the fact that we have been able to participate in the EuroStar99 will high-light the acceptance testing in our organization. The future of the testing laboratorydepends on the interest from projects and those responsible for maintenance to use thelaboratory. So far there is such an interest.
Ulla Hard & Elsmari Gottfidsson
Ulla Hård af Segerstad is employed at the IT Department of the NationalSwedish Tax Board. She has been the leader of a system development'sgroup for many years. She has done some inquiries concerning qualityassurance and testing for the IT-department and has a period of timeworked together with Elsmari Gottfridsson at the construction of theacceptance test laboratory. She has also had assignments as a testmethod consultant. She is now responsible for the quality assurance in alarge project at the National Tax Board and for a network for qualityassurance and testing.
Elsmari Gottfridsson is a senior administrative officer at the NationalSwedish Tax Board. She has been responsible for the producing of acommon concept for acceptance testing. Her interest in testing begunwhen she as an end user at a local tax office became aware of the factthat she spent a lot of her time in testing systems after the start ofproduktion. From this point of view she set about the task to find newways to work with acceptance testing in order to obtain a better systemquality and consequently better working conditions for the end users. Thelast years Elsmari has been engaged in introducing the new method ofacceptance testing and the construction of a acceptance test laboratory.