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


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

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

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

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

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

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

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

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

Welcome to the evil realm of nonfunctional requirements. The core information your teacher gave you is, in other words, "No idea, go figure something out, and I will decide if I agree with it." And this is what happens most of the time in real world projects. Focusing on your information: one user, local environment, we already have some valuable ...


3

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


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

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

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


2

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

Undocumented features are BUGS It doesn't matter whether the undocumented functionality appears harmful or not, it is still a bug for the following reasons: Because the functionality isn't documented, there is no traceability. Lack of documentation means that harmful consequences are much less likely to be found (if testers don't know it's there, they can'...


2

First reaction should be, buy some time to investigate the issue and co-ordinate to fix the issue. Then let them know "we would investigate why the issue has been leaked from our testing". then, 1.Analyse why the bug has been missed, could be variety of reasons * Business use case wouldn't have been properly defined or not captured properly 2. Bug ...


2

Production defects are always the metric of a tester's performance (or some other variations like ratio of prod issues to the ones detected on testing phase weighted by their severity for example). So what you can do is being aware of how the metric is defined try to manipulate that metric using the factors you have the impact to. Here are the couple of ...


2

Since you don't have guidelines, you would have trouble justifying the behavior of the password field as a bug. That said, I'd suggest you raise a bug and classify it as a security flaw. You can cite the OWASP security standards password section to justify your case, even if the application isn't a web app: any software that needs a password by definition ...


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