In my company, we use a separate test environment where we copy production data daily. This environment is periodically used to detect issues like the ones you have encountered.
The vast majority of our testing is carried out with synthesized, non-production data. Some of this is produced by hand, but most is produced by scripts we build. We periodically ...
Assuming you exclude the systems used to execute the application-under-test (Operating System, Browser, etc) there are no tools a tester cannot live without. There are many tools that make testing stronger, more thorough, easier, faster, and/or more efficient.
We use bug tracking tools, text reading/editing/printing tools, document storage and retrieval ...
I like using modern.ie (by Microsoft) because they carry all IE browsers from IE6 to IE11 and it's free.
You basically choose which version of IE you want and it comes prepackaged with its own virtual machine so you don't have to install anything. Just run and test. The downside is the virtual machines are time limited and expire after a certain amount of ...
Some additional tools to the others (+1 to Phil and Joe, great suggestions) mentioned:
Mind Mapping tool (e.g. XMind)
Database Querying/Scripting tool (e.g. SQL Server Management Studio)
Screenshot Capturing tool (e.g. PicPick, windows problem step recorder)
Data Generation tool (e.g. www.generatedata.com)
Browser specific dev tool bars (e.g. ...
No. The items you mention scale very differently and there are far too many factors and resources that will get used.
For instance if I time requests on a local server using an application I'll find things like
1 user = 2 second response average (time per request)
10 users = 2.5 second average
100 users = 2.5 second average
1000 users = 20 second average
Does this actually catch, before production, many of the "surprise"
problems we might anticipate? Or is there a more fundamental flaw in
the approach that will cause deleterious changes to pass testing and
You are wise to have a test system that you can use for catching performance issues, but your "scaling" approach is flawed.
Jing (Screens capturing tools)
Small little tool that let's you record a short video of the screen. I personally use this when taking screenshots or attempting to explain an issue becomes difficult. The next best thing is to record the problem. It also saves the clip on the cloud so you don't have to worry about finding a location to host the video.
This depends on what kind of limitations you are experiencing. You can come up with virtualization. This will let you run several environments in a single host.You can also approach with containerization where you use the same host but isolate your instances with effective segregation of computational resources. Both of these options require some non-trivial ...
I'll try not to repeat any of the tools already listed. Some that I use extensively that I don't see in other answers are:
Fiddler - http debugging proxy
Beyond Compare - diffing tool for files or folders
Perfmon, Filemon, Processmon - monitoring different parts of the SUT.
Snipping Tool - screenshots
I haven't heard of a standardized term for this technique, but it is commonly used. We do this pretty regularly at my current company, but avoided it almost completely when I worked at Microsoft, even though there were a number of cases where it could have greatly improved our ability to troubleshoot issues. At Microsoft, they considered the risk of ...
If your current Agile practices and approaches are:
Some projects are Agile where continuous feedback from client will be coming, and the developers need to work on the existing item if it's in testing phase too because the deadline of a project will be too short and the client won't extend the deadline.
Then you are not agile
Although Agile does ...
There are several ways you can work with this situation.
No-work - let the tests for the new feature fail until the feature is migrated to the staging environments. This can be an option if the tests don't block builds or aren't reporting directly to management.
"smart" detection - as Dale suggested, use some coding to detect whether the feature is ...
One more important thing people forget communication tools, a tester should always ask questions, so we need some communication tools like Hipchat, Skype, slack, whatsapp...etc or any client email tool.
Clipboard Manager is very useful tool for multiple copy history.
Let’s consider the following situation:
In this case, some ...
Some tools for test data generation - online and standalone:
Datagenerator - free tool, DB data / tables generation.
GenerateData.com - free online script-based data gen, different output formats, including CSV, Excel and SQL.
Spawner Data Generator - sample/test data for databases.
More links may be found here, but the above 3 I use more often and they're ...
Generally you should think of tests as doing
Given X, When Y happens, Then expect Z
This actually occurs at two (or more) levels:
Entire test suite
Certain files, constants, database commands, etc. need to be run before the entire test suite. Often there is no 'tear-down' in this area.
Each test should also have the ...
Presumably the database is just a piece of your overall system, and your goal is to determine whether database changes break things or slow the system down.
Using a downsized database is a reasonable way to check whether database changes break things.
I'm not sure it makes sense to use a downsized database for load testing. Whether this makes sense ...
The only difference I have found in practical terms is colour replication. It's not Bad, just not exact (in my experience).
On the whole, it's not a problem, but if you are making a site meet AAA standard for accessibility, it can be irritating at the times.
A few suggestions:
If you can mock or fake the responses of the integrated apps, you could avoid the need to test live. It does require more work to set this up, but you then have a non-production environment you can use and you will not find yourself inadvertently load testing the integrated apps.
If you must test in production, make sure you know the ...
One of the most important tools I use all the time is virtual machines. I have a library of different test environments saved and if I need to test something in any one of those environments I just fire up that VM. The ability to snapshot the virtual machine means that I can corrupt the environment and very easily come back to a pristine state.
I would hate ...
Test data generators are especially useful when the data format is likely to change.
Here is a common problem I've encountered with test data: it isn't always clear which parts of the data are intentional and which are optional. For example, suppose you want to test a CSV file of names and addresses, where each record contains a first name, last name, ...
below is my addition to the list - tools I use very often during testing and preparations:
Firebug addon for Firefox - for me it's a true *must-have* for web testing
CRC/MD5 checksum creation / verification utility (I use QuickSFV, it's free and really quick)
SQLDeveloper (for Oracle)
SQL Server Management Studio (for MSSQL, was mentioned above)...
It really depends on the type of company you are, or the products you are testing. It also goes to your testing approach. Are you basing your tests on the data available, or are you creating data required by your tests.
IMHO, the most effective way is to get a copy of production data, and perform analysis on it.
De-duplicate the data.
Perform "equivalence ...
I've done this in many places myself, where we copied over production data because it was so very useful in troubleshooting issues that were only apparent in Customer data and it also provided additional test scenarios and data structures that we did not then need to always recreate. It's extremely useful, and if your Development Team is balking at this you ...
Microsoft has sample databases for exactly this purpose:
There are tons of samples, tutorials and training online that all use these sample databases. It sounds like everything you want from above could be done with these and ...
white box testing can vary from what helping hands mentioned above, to functional or non-functional testing done at the code level.
Usually (but not always) white box testing allows you better flexibility than testing through external interfaces (UI or other) enabling more test coverage.
I am not sure about the official definition but the way ...