What manual testing should be done when no time for automating it?
In a recent interview a friend of mine was asked: If you do not have time to write test scripts, so as quick way what are the things exactly you will test manually in the order of preference ?
It would depend on how well I knew the product or project - if I was familiar with it, I'd have a good idea of where the risks were so I'd focus my testing this way: Steel thread or happy path - the things that have to be working for the product to be accepted by the customer. This is usually in requirements or use cases and typically defines what the system should do in specific circumstances. Highest risk areas - once I was satisfied that the core functionality was stable, I'd look at the other parts of the system I know are one or more of the following: bug-prone, places where failure is catastrophic to customers (getting financial data wrong in something that manages sales and products, for instance), anything that's subject to legal requirements (such as rules for storing patient information in the USA), and so forth. This would include things like "does not corrupt data in the event of a crash". Lower risk but high visibility areas - this includes things like avoiding showing raw error code on something that faces the public (which may also be a security issue, depending on the application - in which case it's a higher priority item), potentially embarrassing or misleading wording, and general usability. If I don't know the system before I start testing, the first thing I'd do is a combination of exploratory testing and research to find out as much as I can about the steel thread, the requirements, and the risk areas. Finally, I'd make sure to communicate my assessment of the risks involved in releasing the product. Whether it releases or not is a business decision based on factors I can't control (which could include contractual obligations), but I can make sure that the risks I see are clearly stated so that the people who make the decision aren't working with inadequate information.