2

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 ?

Improve this question
1
  • 3
    How did your friend answer?
    – Joe Strazzere
    Oct 9, 2013 at 10:46

6 Answers 6

Reset to default
8

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:

  1. 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.
  2. 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".
  3. 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.

Improve this answer
4
  • what is the difference between High risk area and Steel thread?
    – gpuguy
    Oct 9, 2013 at 12:25
  • Steel thread is what must be done for the program to meet user requirements. High risk is anything outside that list that is high risk for any reason.
    – Kate Paulk ♦
    Oct 9, 2013 at 16:50
  • Is not Steel thread sufficient to analyze? Because if it is tested with success then it will must meet the user requirement.
    – gpuguy
    Oct 10, 2013 at 4:15
  • 2
    Not necessarily - let's say your application sells event tickets online. If your project is to add the ability to reserve a specific seat, then steel thread might not cover selling tickets without seat reservations. (This is a very simplistic example, but I've seen very similar things happen).
    – Kate Paulk ♦
    Oct 10, 2013 at 11:21
3

Testing is an information service. The goal is to inform some set of people about the product.

So:

Who are you trying to inform with your testing? What information do those people most need about the product?

Test the things that yield that information.

Improve this answer
1

As there is no time to automate the test scripts.It is better to perform risk based manual testing so that the critical defects can be found and fixed.Hence making the system stable under such pressure and then try to find the bugs in the interfaces among the modules and make them fixed.

Improve this answer
0
1

If the risks are known then you can test them at first, after that worth to organize a exploratory testing focusing on the risky areas.

Improve this answer
4
  • any example of risk? sorry I am not-testing guy. Though I did some manual bound checking of data fields in a project
    – gpuguy
    Oct 9, 2013 at 7:14
  • 2
    Ohh, generally risk is based on a built up consensus between the different involved areas. For example, from business side could be marketing, SEO, etc. From technical area, domain experts, performance experts, etc. Generally, risk is a moving target. A general example for risk could be that, if you are responsible for testing a webshop which selling travels than the basket and payment functionality represent high risk.
    – AndrasCsanyi
    Oct 9, 2013 at 8:16
  • So you mean "risk" means something which if not implemented properly means a devastation?
    – gpuguy
    Oct 9, 2013 at 9:09
  • Yes. To put in another form. Risk is that something which is important for the customer (who pays you to do something) and he/she wants to get it. If he/she do not get it then the product is not usable (see the validation/verification thinking in testing area mentioned in CTFL study material) and it does not represent business value. You can read a lot about risk based approach in the CTAL study materials.
    – AndrasCsanyi
    Oct 9, 2013 at 11:20
0

First, I would suggest to go with Exploratory testing. In case if you are pretty much aware of requirements then please go with Functional testing as it is considered as Black Box technique.

Improve this answer
0
  • Read a Functional requirments provided by client carefully
  • Point out the areas which are to be tested and specially risk areas
  • Make test cases for it from low to hogh risk covering all the fucntionalites
  • Execute in the ordered manner.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.