This in turn tempts:
??? Developers to shed their unit testing responsibilities onto testers.
??? Testers and developers to duplicate each others??™ work.
??? Testers to become distracted from the task of system-testing a site.
These issues need to be clarified in the test plan and the web test process beginning with a search (repeated
regularly) for baseline-relevant data. Here are some approaches to the tests:
???
Transaction link tests.
These are baselined on single end-to-end transactions. Having identified
these from some requirements specification, determine all the browser elements, components,
applications, and scripts needed to get it to work, and build a pseudo-site capable of undertaking
it. This way you will answer the following questions:
??“ Can we undertake this transaction?
??“ How fast can we get it to run?
??“ What are the interfaces?
??“ How many of these transactions can the system support at once?
??“ Does the system successfully add, delete, and update records?
??“ How much of the system did we have to stub to get this to work?
??“ Did this leave the database as it should be?
??“ Do our automated tests work?
This is nothing more than the ???threaded??? integration strategy. This approach may be opposed on
the grounds that ???
it??™s too early for this sort of thing
???: which means ???
I think you??™re about to show
that my code doesn??™t work
.??? As indeed you probably will.
???
All links test
.
Pages:
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216