If your business has critical components
served by your application (and if it does not, then why are you building the application?), you
must consider the costs of insufficient, rushed testing and communicate those potential costs to
the business users. The evaluation of the risks of incorrect data or unacceptably slow performance
must involve the business users. In turn, that may lead to an extended deadline to support proper
testing.
In many cases, the rushed testing cycle occurs because a testing standard was not in place at
the start of the project. If there is a consistent, thorough, and well-documented testing standard in
place at the enterprise level when the project starts, the testing cycle will be shorter when it is
finally executed. Testers will have known long in advance that repeatable data sets will be needed.
Templates for tests will be available. If there is an issue with any test result, or if the application
needs to be retested following a change, the test can be repeated. Also, the application users
will know that the testing is robust enough to simulate the production usage of the application.
In addition, the testing environment must support automation of tasks that will be automated
in production, especially if the developers used many manual processes in the development
environment. If the system fails the tests for performance reasons, the problem may be a design
issue (as described in the previous sections) or a problem with an individual query.
Pages:
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246