12

If the product is at the MVP stage and your QA is just getting started, there's a problem. As a BA I saw this time and time again with dev vs QA where the dev team only got the BA to do testing when they felt the product was "ready to deliver to QA" which is a notion all developers should aim to dispel. Most developers went to university and took some ...


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


9

Are you aware that “Most of the bugs in software are due to incomplete or inaccurate functional requirements?” What would be the best use of QA engineer's time while the project is in an early stage? Test the requirements itself, not the product... by asking the right questions to uncover & challenge implicit assumptions in the requirements....


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

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


7

I have been telling them that 100% tested and bug free product is a myth. It might be the way you are telling it. Probably it is true, but having an attitude "it is not my problem" is not the right one. As a business I would like to see someone who cares. Your reaction should be something like: "Damn! Let me figure out how we can prevent this the next ...


7

The terms “performance requirement” or “performance attribute” are preferred over “non functional requirement” according to the most recent update of The IEEE Standard for Software Quality Assurance Processes 730-2014 Definitions. The IEEE Standard for Software Quality Assurance Processes 730-2014 defines Performance requirement as the measurable criterion ...


6

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


6

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


6

Although all observations are valid, from a project point of view, I am missing the motivational and learning point of view. Starting some automation now can also be part of the learning of that engineer, and the team. He will be motivated as he can do something he wants to do. Yes, the product will change. But he can also grow along with the development of ...


5

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


5

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 behavior. One could also think of non-functional requirements as quality attributes for of a ...


5

Introduce high-level testing methods may help, such as behavior-driven development (BDD) Direct quote from Wikipedia: BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes. It may require some additional ...


5

As others have said, communicate the way the BA is most comfortable with. Some other suggestions: Start by confirming your understanding of the functional spec/feature behavior - I can't stress this enough. If you and the BA have a different idea about what the new feature is supposed to do, you will never be able to communicate effectively. This will ...


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


4

But, there are ALWAYS requirements - even if they are not formally documented. They may take some time to discover and list, but they exist. 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. Then, interview the project manager ...


4

If you don't have specific requirements you should design test cases based on best practices, best user experience and security. It's not a bug, because it does not behave differently from expectations (you don't have any) but allowing to create password that is weak may lead to account hijacking and information leakage which is an issue. You have to think ...


4

I agree that it may be too early for much automation. But there is still a lot QA can bring to the project to help it be successful at this stage. If it were me on the project, along with learning everything I could about the requirements, I would be looking at what the customer(s) really do & what their workflow is, what our competitors might offer ...


4

It's not an easy question and I am not sure it belongs in SQA, but have you tried to set up meetings and ask the questions face to face ? Many times a small demo or a few minutes of screen time can resolve misunderstandings.


3

How do I test when I have incomplete requirements? Like you normally would. You'll never have complete requirements, there will always be some information missing or things you don't know ahead of time. That's one of the reasons why we test. How should I go about designing tests for the client, and how should I test their product? Requirements ...


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

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

Consider adjusting your development workflow to include and promote some of the following practices: QA can tag a ticket for a developer to talk to qa before they start writing code QA reviews tickets for what sort of testing should be used (unit, integrated, performance, etc.) QA writes high level tests that are initially failing as the code is yet to be ...


3

It is not answerable. Answer is: "QA should devote as much time as needed to find out all inconsistencies in requirements, but don't waste anything beyond that". So you are back on square one. To avoid mistakes, good judgement is necessary Good judgement is based on experience Experience is based on learning from past mistakes


3

It sounds like you're on the right lines already but, in addition to going through the requirements and getting familiarised with the roadmap, it's definitely worth getting him to exploratory test the MVP and get a feel of the product as early as possible. Also, static testing the requirement document would be beneficial as it allows for early feedback and ...


3

note: I assume you are CTO or similar role or the "boss" for QA stuff In order to clarify my "idea" of QA during project/product development, I've write down following workflow as example: requirements: formalize them, update them, take track on every release, as use case or user story. define tests: define how user story are tested, with edge cases should ...


3

See if you can get some time with the BA to walk through questions. Maybe they comprehend better by seeing than by written description. If you aren't in the same office a quick skype (or what ever tool you are using) might be enough. Or if you have numerous questions save them & book 30 - 45 minutes to cover them all at once (more respectful of the ...


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


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

You could try using oldweb.today for example here is IE4 rejecting https://google.com since it is HTTPS.


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