![The Un-Managed Process ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (7)
Similaire à Load Stress Performance Testing Software Services
Similaire à Load Stress Performance Testing Software Services (20)
Load Stress Performance Testing Software Services
- 1. TEST IT Limited Load, Stress & Performance Testing
Notes de l'éditeur
- ‘Adequately’ what does this mean? You have done all the testing you could, but for some reason it gets out to the client/customer and its not performing as they expect! DID YOU HAVE THE TIME TO DO MORE TESTING OR DID YOU RUN OUT? DUE TO PROJECT CONSTRAINTS? IT WAS A NEW FEATURE WE DID NOT EXPECT ANYONE TO USE IT
- ‘ Someone’ Can one person run a load test? Maybe if you are thinking of ONLY one person using the s/w at a time! It’s never going to work! Depends on what we mean by load testing, applications require different criteria to run load tests. E.g. Batch Runs, multiple user runs, Combination of both! Parallel runs of multiple batch stream.
- ‘ Remember to’ – Testing s/w should NOT rely on someone having to remember what needs testing in the next release planning is key to a successful project.
- Agree requirements, scripts and resources. Participation both Test IT and client resources. Demonstration of agreed script functionality. Participation both Test IT and client resources. Capture and engineering of scripts. Just Test IT Sighter tests. Just Test IT Formal tests. Both Test IT and client resources. Report preparation. Test IT Debrief. Both Test IT and client resources. ---------------------- ------- ---------------------------- --------- ---------------------------- Sighter tests comes from "letting us get site of the thing before users start asking stupid questions". Basically as we start running the scripts immediately after capture we are just as likely to find issues with the script (like tipos in directives or test data being incorrectly extracted ) as we are to see problems with the system being tested (like the user after a Day asks for its password to be changed or the additional users - beyond the few we used to capture the scripts - don't work). Also the local DBA may have not created enough space in the database. You can make him your enemy if you expose that to his boss. Better work with him to sort minor errors out. Having people around asking stupid questions while you sort these issues out is a pain in the arse. It's like developing a program. You write it. You know it is likely to have little problems so you do unit testing. Only when you are happy it does something sensible do you demonstrate it to a user.