Tag Info

Hot answers tagged

10

For me it's a non-functional requirement, even if the key users have some requests regarding the instalation folder location (for better integration with other software packages). UPDATE: The tests for the available features detection are still placed in the functional requirements area, given that: the software can be bin-deployed in some cases, and ...


9

I would agree with alexandrul's answer, with a few small caveats. First of all, it depends on what the installer does. If it's just a plain normal install, it would fall under non-functional. If there are options in the installer that greatly affect the functionality of the application (ie: add/don't add specific features), I would normally put it in my ...


7

In my opinion, testers should absolutely be testing non-functional attributes (performance, usability, privacy, security, reliability, compatability, supportability, etc.). In general, I think testing should have less emphasis on functional requirements and more emphasis on non-functional requirements, but I don't want to side track your question. If you're ...


5

Lyndon makes some good points, it does depend on what your installer does. When I have worked with them in the past, mostly I deal with SaaS and not so much with client apps anymore, but there were a few in my past jobs and we mostly had functional tests for them. The rationale was we were not just dealing with installs, although that was there, but we ...


4

As I indicated in this reply Accessibility Testing - Should it be considered functional testing or non functional testing? I like the following definitions from http://www.lessons-from-history.com/node/83 "a functional requirement specifies what the system should do" "a non-functional requirement specifies how the system should behave" We have always ...


4

I recently hired on with a new company and wondered about this as well. After speaking with my former and current supervisors, I got the following advice and followed it. Know what you're talking about. Assuming the person interviewing you is a Test Manager or experienced tester, they know what they are looking for. They're ears will be open for key ...


3

We categorize things because we believe we need to treat the categories differently. It is hard to express an opinion about why separating functional and non-functional tests is important without knowing how one would use the answer. Important for what purpose? Sometimes people ask such questions in these forums because they did not have an answer in a ...


3

Some points would include, Battery back time. Screen resolution. Its weight. Its dimensions. What accessories come along with it. ... And you can keep on going with your list of expectations.


3

First, you're going to have to understand the Project Managers and Developers that you work with. Not knowing them it is hard to understand what sort of arguments might persuade them. Think back on arguments you've had with them, what kinds of arguments did they use to try to persuade you. In all likelihood a similar form of argument will likely hold ...


3

Personally, I think yes, but no. Yes in the sense that you need to make sure it's "good" in a common sense way. But once you've identified where it's not "good" you need to break down why into a functional requirement. Consider the categories: Usability is not something that can be tested. How can you put into a specification "Must be easy to use" or ...


2

You need to connect the dots. There are at least three messages to convey: your production system has problems that are worth worrying about; those problems result from your shortcomings in your organization's current practices; and the best way to address those shortcomings is to introduce new tests, i.e. to use your terminology, additional UAT-level tests ...


2

Why seperating functional/non-functional aspects of a system is important for me as an tester I make such an distinction at the very begining of a project (either during drafting the strategy or implementing it). It helps in making non-functional or 'implicit' (another word for overlooked,forgotten or ignored completely) requirements sufficiently 'explict' ...


2

The best way to do this is practice functional testing and master the art. Once you do that you won't need to find back door answers to such stuff. Never try to pose yourself in an interview that you are not, because sooner or later you will get caught and that will affect your job. Learn the art and practice it so well that any question thrown at you on the ...


1

Often in interviews, I'm asked "how would you test x, y, z?" and while I didn't plan it, I found myself giving a pretty stock answer each time. I'll start off saying something like this: "It depends - on the features, the requirements, the timeline, and any other relevant factors." And then I'll start laying out specific examples. A web page that changes ...


1

Any time you group tests into a suite of tests you are likely grouping along some category. For example, we have several suites of functional tests that get ran against every daily build. We also have other tests for security, battery, reliability (non-functional categories). Some of these suites get ran less frequently. Although we don't necessarily ...


1

I'd see it as more of a tracking issue, I haven't done much non-functional testing (at least I wouldn't call it that) although I could look back and probably say we covered that in some other kind of testing. Mostly when working on a project I look at the Functional Requirements and start basing tasks/tests/checks off that, anything not in the requirements ...


1

I lost you somewhere along the question... Anyway, upper management are usually convinced by showing them the ROI, for example if you can show problems that could have been detected and solved during a non functional testing phase.


1

Yes. This was part of process for major releases at a former company and was done in an ad-hoc way in other companies I was part of. Yes. Apart from the reasons Joe states above, having people with different knowledge of the software combined with a different business view often resulted in issues/scenarios the development team hadn't thought of. The amount ...


1

Yes, we've done something like this in the past. Yes. For many reasons - performance issues, functional issues, team spirit, etc. It's wasn't very time-consuming for us. QA, Dev, Customer Support were involved Didn't really run into any problems In addition to inviting others to participate, we used a load-testing tool to apply background load which ...


1

This is a pretty common practice. At Microsoft we called it a bug bash I have also heard it called a bug hunt, I'm not sure if the industry has a standard term for it. Yes, I and many other teams have done something similar. Yes, we nearly always got some good data out of it. As many people as we could get, usually for a few hours (1-4). We normally got ...



Only top voted, non community-wiki answers of a minimum length are eligible