Tag Info

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 ...


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

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

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

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 ...


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

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 consist of hardware and software. In some situations, it could even include humans performing well defined processes (for instance, changing deployed batteries). ...


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: ...


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

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 ...


3

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 ...


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

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 ...


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

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. ...


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

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 (eg) WordPress, osCommerce, Joomla (etc) are/were because folders were left right-enabled and/or ...


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

Communication and exploration. I have begun working on each of my project with no or negligible documentation. My approach has been the following: Figure out (explore and initial training with someone in the team) what the product is supposed to do - the happy path Figure out the critical sections of the product Frequently talk to developers, product ...


1

It depends on how your brain is wired. Personally, I start by drawing pictures. After reading the documentation and playing around with the site, I like to diagram what I understand about the product. I grab the biggest sheet of paper I can find and draw a graph of entities managed by the product, relationships between entities, user roles, actions ...


1

I've always found immense benefit to requirements being tested before being handed to the developer. In many cases, I prefer the developer to be testing with me. Not only do we get to learn about the application before we develop it, but, we usually end up cutting down time lost by sending back requirements after it's already been partially developed. ...


1

You might like to read the book Effective Methods for Software Testing. It has some checklists for checking things like requirements. While the book is big enough to be a door stop, it also has lots of checklists for every stage of testing and QA.



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