2

Today I was in an interview and they asked these questions:

  1. What test methodologies are applicable for web-based software but not for desktop?
  2. Can Severity or Priority change during bug life cycle?
  • 1
    Re 2: od course severity, priority etc can change, after understanding problem more deeply. In war, first casualty is the plan. – Peter M. - stands for Monica Jul 1 '15 at 16:50
2

To start with, there is no formally defined list of standard test methodologies. That said, there are a number of test methods that are better suited to web applications than desktop applications:

  • HTML validation - even if a desktop uses HTML display in some or all of its screens, it's not going to be as accessible as right-click - view source in any browser.
  • 'headless' testing - with some web applications it's possible to define the request, send to the server, and parse the response without involving the user interface at all. This is typically not possible in a desktop application.
  • Load testing - Load testing is almost exclusively web-based. Every load test tool I've seen is designed to send HTML requests to a web server. Even if a desktop application uses N-tier architecture, it's unlikely to use HTML to handle communication between the server and the clients.
  • Penetration testing - unless a desktop application client communicates to a server behind a firewall, it's unlikely to be targeted by penetration testing: most of the tools available focus on web applications, as does most of the penetration testing I've been involved with.

For your second question, yes, absolutely a bug's severity and priority can change during its lifecycle. Some reasons for changes:

  • the bug causes more/fewer problems than it appeared to when reported. That will cause the severity to change accordingly. For instance, a bug that appears initially to be a simple display error might turn out to be the only visible indicator of internal data corruption (I've seen this happen).
  • the business focus changes, or time shifts: a bug that allows non-admin users unlimited access to the system might be medium priority at the start of a release cycle, but if not fixed it will be a much higher priority at the end of the release cycle (I've seen this, too).
  • Great answer. But we also do Pentration testing for Desktop applications. SQL Injections are very possible and as most desktop applications are hosted on terminal/citrix servers you also might want to check that you cannot upload and or execute exploits on the remote servers tru your application. – Niels van Reijmersdal Jul 2 '15 at 12:01
  • 1
    @NielsvanReijmersdal - I've never run into a desktop application hosted as you describe. The applications I've worked with have run off a database hosted in a central server with multiple client installations run on machines in the company intranet. – Kate Paulk Jul 2 '15 at 14:58
1

I am assuming that the first question you ask is: what are test methodologies for web based and for desktop based applications? because it doesn't make sense when I read it.

  1. Test methodologies differ greatly between web and desktop applications, that is a wide topic to get into. I can put a few topics on the items listed but there are many good internet resources to lay that out.

Web - relies solely on a browser to test, requires multiple browser testing for valid testing data, need to be mindful of network outages and it's behaviors, etc...

Desktop - relies solely on a users computer to test, requires multiple OS testing for valid testing data, need to be mindful of computer limitations to run the software, etc...

(Those again, are just a few, I could go on with differences for days between these two categories.)

  1. Severity, priority can definitely change during the life cycle; even though it isn't considered 'best practice'. Information coming in might change the aspect of the work that is taking place. So for instance:

You begin work in a sprint where a 'login' page is being reworked to better suite the customers, this isn't a very high priority because it will be a new page that will replace an existing one that works. During the sprint lifecycle something happens to the existing page that is preventing users from logging in, priority is upgraded on the item by business decision; instead of patching the existing page they would like to roll out the new login page at the end of the sprints work to adequately fix the problem at hand.

0

Test Methodologies for the web based applications describes about the different types of testing methods, which should be used for ensuring the quality of the product. Testing Methodologies include Unit Testing, Functional Testing, Integration Testing, System Testing and Acceptance Testing etc. These methodologies are part of the Test Plan and one has to define the same before starting the actual testing. Yes, one can always come back and update the test plan for any new method which is required for quality of the product.

Remember Testing Methodologies are very different from Testing Approach, as some people mix both the terms and practices, though both can be part of same Test Plan.

For the second query, yes you can change Severity and Priority of Bug during Bug life cycle, even during Bug Triage meetings Priority and Severity of bugs are discussed and then updated if required. As the name 'Priority' itself suggest 'Importance of Bug' so it is Testing stage dependent.

  • This is decent basic information, but doesn't really answer the original question about methodologies applicable to the web and not desktop applications. Could you update your answer to clarify that? – Kate Paulk Jul 2 '15 at 11:15
  • I think, I miss understood the question for the first part and replied in general about the web based testing methodologies. – Dhiman Jul 23 '15 at 14:27

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.