Testit Process
- 1. TEST IT Limited Load, Stress & Performance Testing
- 2. The Un-Managed Process How often have you come across a situation where the developed software has not been tested ‘adequately’ for the required number of users, before putting into production use?
- 3. The Un-Managed Process How often have you heard it said ‘we should have got someone to test that!’? How do we test for 1000’s of users? Surely all we need do is get a few people together and test it. That should be enough to check it works before we go live! Shouldn’t it?.
- 4. The Un-Managed Process How many times have you heard, We should have tested that. We’ll send a patch and ‘remember’ to test it in the next release!
- 5. Performance Testing Test end to end : network and servers Test from multiple WAN nodes concurrently (even globally) without leaving the centre. Test varying workloads to either determine possible SLAs or to test against known SLAs. All efficiently, effectively and at low cost .
- 6. Load / Stress Testing This type of testing checks to see that the server will perform as specified at peak con-current loads or transaction throughput. Includes stress testing servers, networks and databases.
- 7. The TEST IT Process Meet & agree client requirements Demonstration of agreed script functionality Capture & engineer test script scenarios Perform sighter tests to iron out any issues pre-actual test execution Perform formal test executions Prepare report Debrief client representative(s) on test results
- 11. Think Positive Think TEST IT You want to run a Load & Performance Tests for hundreds or thousands of users but do not have the capability or think it will cost too much? Your existing arsenal of tools have the capability but no one remembers how to use them? You are worried about the Load & Performance your application will be subjected to when your software goes live? If your thoughts are ‘YES’ to any one or all of the above then Test IT can help. Please visit our website at www.testit.org.uk or email us : info@testit.org.uk
Editor's Notes
- #3: ‘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
- #4: ‘ 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.
- #5: ‘ 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.
- #8: 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.