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


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

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


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


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


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

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


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

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

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.


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

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

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


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


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

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

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

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.


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



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