Hot answers tagged

9

I've read that if a requirement can't be verified by black-box testing or inspection, then it's not a requirement, but a design specification. I don't think that's true. There are plenty of requirements which are difficult-to-impossible to test with black-box techniques; for example, a client-server application might have a requirement that all ...


8

Do your functional requirements indicate what types of files are permitted to be uploaded, and what types are not? Do you have formal security requirements? Or is it just your sense that uploading executables or batch files is a bad thing to allow? Your BA approved this. Did she say why it should be permitted? What happens in your portal when an ...


7

"Playing around" and documentation like user manuals can definitely provide a start to developing tests, but they should just be a beginning. Properly testing that an application is doing what it is supposed to requires more domain knowledge. End users who have been using the application and know what it is supposed to do can be a good source for creating ...


6

A strategy that I commonly use is that I will put my "end user" hat on and then test the system like it was an application that has been deployed to the general public. I will make a number of assumptions as to why things are the way they are, and document them. I will then take those assumptions and have them checked by whoever I can, ideally subject ...


6

Approaching the application methodically and with intent can yield a significant amount of the information that you need. Start with simple questions - any application should/ almost certainly will have the most commonly used functions on obvious display - follow every option in the menus for a while. Start to map what features you know the application has. ...


6

System requirements are the translations of user requirements in a much more technical language. They are basically the things that a software must perform. Not exactly. The system usually consists of hardware and software. In some situations, it could even include humans performing well defined processes (for instance, changing depleted batteries). The ...


5

If we agree in principle that validation is regarded as "building the right software," and verification is "building the software right," and QC is quality control helps identify defects in the product via testing, and QA is quality assurance intended to help prevent defects in the product through process management then, one position is that both ...


4

In my opinion, there is incorrect use of terms: User's requirements in plain language should be called user's stories or etc. Requirements for the hardware are often called system requirements. Functional requirements cover what your Application need to do and in which way (i.e. its functions) P.S. Also, you can read about requirements from the wiki: http:/...


4

First, look for general requirements and work to document them. Some of these requirements come from previous versions of the application, some come from generally accepted usage. For example: Must run on platforms x,y,z (perhaps because those platforms have always been supported) Must use abc database Must be able to process n records in m seconds Must be ...


4

What you need is to improve your Requirements Engineering processes. There are commercial tools that help in this area (I have worked with Doors some years ago), but I don't know of any open-source alternative I could recommend. The problem is that these tools and processes are very "heavy weight", and in my opinion, achieving requirements traceability ...


4

In short: A user story describes desired behaviour of the system focussing on results and written in plain understandable language. More formally: A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. A bug is something wrong in the system. Either a violation of ...


3

Context is everything... what is the nature of the site (public/private, and purpose) and the definition of "executable" is quite broad, and should extend beyond the obvious bat, exe and com. For example, most vulnerabilities in many common web-applications (e.g. WordPress, osCommerce, Joomla) are/were because folders were left write-enabled and/or file-...


3

Our team started dealing w/ this issue by having testers either create a wiki page online or create a Q&A section on the existing wiki spec that the developers created. All questions about vague areas in the spec are asked there, and all answers are documented there. If you get an answer "offline", you would document it there, then email the person who ...


3

I performed some BA in addition to QA w/my previous employer & there is no doubt in my mind I tested much more thoroughly as a result. One thing I did not expect was this: the developers were plumb crazy about the requirements documents that I wrote because I integrated the technical details with the customer's "wants" in a way they could relate to. ...


3

It's part of a tester's job to ask questions about the product that nobody else has even thought of yet. Waiting until after significant programming time has been spent to even start asking those questions - well, does that sound sensible to you? Some of my best defects (except we called them review comments) have been raised before a single line of code ...


3

This is an extremely common problem in software development. There are many testing resources in an organization: support team, end users, documentation writers, and the bug database. Utilize these resources to help determine potential problem areas and common use cases to focus your testing.


3

No, this is not a common practice. QAs are and should be kept in light and every communication involved related to the requirements. The sole purpose of the documentation created during the requirement gathering phase is to keep it updated and validate the application according to that document, so this document serves as the single point of information for ...


3

White-box Testing White box testing is a testing technique, that examines the program structure and derives test data from the program logic/code. The other names of glass box testing are clear box testing, open box testing, logic driven testing or path driven testing or structural testing. White-box Testing related requirement UNDERSTAND THE SOURCE CODE ...


2

In my shop Testers (and Developers as well) formally review Requirements. We read the documents ahead of time, then get together with the entire project team and go through them. We find that Testers with their domain knowledge and differing viewpoint can provide insight in several areas checking the Requirements for testability checking for clarity, ...


2

The proper ways are, Do a Exploratory testing, understand the business needs and the impacts, interact with programmers, clients, use your own knowledge to get the things right. Eg. for a shopping cart website you could check how amazon.com works for various commonly accepted functions like product search, display etc.


2

"we keep forgetting to handle all the numerous features which were implemented in last few years" If things are being forgotten on a regular basis, this isn't a tool problem - it's a process problem. Your process seemingly doesn't require that these things are tracked in an accessible place, and that the feature list be kept up-to-date. We use ...


2

As a tester part of your job is to provide information and to advise others (BAs, Developers, Managers etc.) about the state of the system and any potential risks. With this in mind, what I'd do in your situation is to research examples of this problem and the potential effects. To appear more credible you could outline best case scenarios (e.g. distribution ...


2

It really depends on your project. I'll try to give you some hints, but it can't be comprehensive. Localization First thing to take into account is the localization. If your fields can be used by a customer from any country, you must consider allowing non alphanumeric characters, and therefore test it. This can lead to some issues, depending on the type of ...


1

I've seen this kind of specifications in companies where their users are provided with specific devices, as for example, doctors inside a hospital to access to the patients clinical registers... because they know that the app (or web) will be used only for a reduced set of devices. Another example, is when you are focusing on a specific market (China, US, ...


1

One approach is to check the absolute value against a threshold, something like: =ABS(ROUND(AJ4,6)-ROUND(T4/100,6)) < 0.001 The threshold value has to be chosen knowing the magnitude of values being compared. You might compute the threshold based on the actual values, something like: =(ROUND(AJ4,6)+ROUND(T4/100,6))/(2000) This gives one-thousandth ...


1

For me, the baseline is always a comparison to some other system. The other system need not be software. It might be implemented by, say, people wielding pencils and paper forms. If that exists, you can measure its response time, availability, reliability, error rate, and so on. The other system need not exist. I can always posit an imaginary people/...


1

There are plenty of ways to keep track of the requirements.The very important thing to be considered is to keep track of requirements and changes from the Inception of thoughts/Requirement analysis, without which it might become a costly affair. Requirement Analysis Aiding Tools- An Excel sheet could sometimes be the simplest way to keep track of ...


1

I approach that problem by maintaining written test cases in a wiki. Each test case is a declarative statement. (I have worked places where test cases were documented in step-by-step detail, but I found it was too hard to maintain the details when features changed, as they often did.) If you search SQA or Google, you will find other structures for written ...


1

The definition of ‘functional requirement’ is that it essentially specifies something the system should do. The definition for a non-functional requirement is that it essentially specifies how the system should behave and that it is a constraint upon the systems behaviour. One could also think of non-functional requirements as quality attributes for of a ...


1

In some shape or form, traceability can be found in (mostly) every organization. Each method has some manual aspects to it, though it really depends on how much effort the team is willing to put into it, how much of the end result will be used, what development methodology/practices are being followed, and how granular each linkage needs to be. In ...



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