Hot answers tagged

11

You could setup personas which are designed around real world of users. We have found this quite useful and it really helps to provide a fresh perspective e.g. Today I'm going to be Andy, the super user of the system. Andy is very sharp with numbers and is the user that is responsible for the administration of the system. He enjoys watching sports on ...


10

Being QA Manager with about 3 years of experience, I just give my team mates testing tasks, which are NOT related to software, e.g.: Compose test cases for blender / vacuum cleaner / etc. - any kind of familiar device / equipment. This results in brain refreshing, and for the cost of 2-4 hours I get team "reloaded")) The same is applicable for testing such ...


8

First, your product probably has some kind of security-related provisions: e.g. authentication, authorization, password recovery, prevent one user from seeing another user's data, and so on. There will be positive and negative test cases for those. Beyond that is the more complicated stuff. There are tools available for scanning websites for security ...


8

It's really no different than any other test case. Set up conditions: Check actual result against the expected result So you'll need a list of all the error messages in the system and the conditions that make these errors appear If you want to really test them out then use the FAILURE mnemonic as detailed here.


8

To know how to write a test plan one must first learn to plan a test. Planning test is a real thinker task. You should be asking a hell lot of question to learn about the domain of the project. You should learn about the stakeholders of the project. One part of planning consists of test estimation. Here is something that might get you started with it - ...


7

I think the simple answer is, do something else for a while. Our jobs require a lot of repetition, and we automatically develop habits in response to repetition. That behavior is a deeply ingrained survival technique; habits allow us to do things quickly without thinking them through. Sometimes those habits allow us to discover new things, but other times ...


7

You could try the 'tours' concept and try out different tours of the software. I'd also disagree somewhat with your premise - the more you use a program the more you notice any slight changes. You also understand more how all the parts interact which in turn gives more ideas. I think at the start you may notice more but they are shallower than ones you find ...


6

allquixotic, How important is it that you get these string correct in all situations? For example, if this is a life-critical application that depends intrinsically on the correctness of your strings (the difference between "Send police to the Town Hall" and "Send fire equipment to the Town Hall" for example), then you must do a deeper dive. Consider ...


6

Tracebility matrix is a tool. It doesn't have any inheritent value, but it might be easiest way of mapping certain kind of relations between tests and requirements. As with any other tool, if it seems to work well, use it. If something else fits better, use that. If the tool nearly fits your need, modify it to give what information you need. If testing is ...


6

If the system needs to scale to many concurrent users or work with lots of data, I would say load testing should be started as early as possible. This way possible problems in the application architecture can be found in a phase where it is still possible to fix them. Couple examples: Let's say that the database schema is such that some queries will be ...


6

As well as "what Joe said, in bulldozer-sized loads", I have a few pointers to add from experience with localization/translation. To test internationalization - which will need to happen first - you'll want something that's really obvious so that in a test environment your team can go through every interaction in the system to check that everything that ...


6

Let me give some advice I got from James Bach. He likes to make the distinction between a test plan and the test plan document. A test plan document is the written form of the test plan. This can vary quite a bit depending on the company you work for and in my experience can range from lean or minimal to bloated (I’ve seen so many bloated test plan ...


5

The above answers are correct, and depending on the importance of the security, you are probably best advised to get some security experts in. Other than that, in order for you to have a go yourself, some useful resources I use to dabble in security testing / ethical hacking are : https://www.owasp.org/index.php/Main_Page http://google-gruyere.appspot.com/ ...


5

Caveat: I've discussed and thought about testing playbooks a little - I'm not convinced that I necessarily have the same interpretation as others, partly because there hasn't been enough discussion of the idea (that I'm aware of, would love references if people have them) for a consensus to develop. This is my best attempt at this point in time, it will ...


5

I'm afraid I don't know the origin of this way of phrasing and I've not seen it before, however I was surprised to see that the answers here consider 'fails if' equivalent to 'passes if', as I quite strongly consider the two to be very different from each-other and also my opinion is that 'fails if' is slightly superior to 'passes if' for manual tests anyway ...


5

Maybe an indirect answer, but one way would be to get actual fresh minds. This is the idea behind usability testing, bug bashes, alphas, private and public betas, etc. Another idea would be to rotate from a staffing perspective to different products/features.


5

I agree with milinpatel17' above answer about Test Plan. Test Plan is a detailed layout and strategy to test a product or application. Before you start writing a test plan, consider these points first: Why to test -- objective What to test -- scope How to achieve objective -- required time and money (with number of resources) What approach -- Automation, ...


5

The question asks whether other test cases can cite smoke testing as a dependency. The answer depends on the purpose of the dependency. If the purpose is to narrow down what your test cases need to cover, that's fine. If the purpose is to exploit a side-effect of the smoke test, e.g. to take advantage of configuring the software in a certain way, or ...


4

A test plan is worth creating if there is something that needs documented testing. It may be frustrating to see a test plan with only a few steps, but if you realize the purpose of the necessity of documentation, it doesn't matter how small the test plan is. You should include whatever it is that needs testing. Whether it's an anticipated UI response to ...


4

As always, it depends. If the system is already sufficiently internationalized, and other localizations have already been performed, then future localizations may be well-defined, documented efforts and their scope may be easily estimated based on past efforts. On the other hand, if the system isn't internationalized at all, then you may need to incur the ...


4

You have been developing this system for 2 years and have never performed any load testing at all? Preparing for expected load is usually part of the design. At this point, you are 2 years in, and may not have any evidence that your design is capable of supporting the required load. You do have performance and load requirements, right? With any ...


4

A few thoughts to add to the excellent suggestions others have made: Yes, full end-to-end load tests should ideally happen after code is stable. These will be used to find bottlenecks in the interfaces between different components of your code. This kind of load test is probably what your QA people are thinking of when you say "load test" - and I'd hazard ...


4

Yes, you can do that. For this you need to save your common/shared test steps in a new test case and then change it to a template using 'Mark as Template Test'. Then where ever you need these shared steps, open that test case and in the test step section of that case select the option 'Call to Test' and then select the shared test case template which you ...


3

One approach is to actively recruit team members and other stakeholders for testing of the product. I have found that it is useful to try different approaches and use whatever works best with each person, which can include: Paired testing with a code developer (emphasize the thrill of having a function work on the first build :) ) Asking a content ...


3

I have never seen such a matrix and never heard of it before :-(. Your goal: Which requirements is almost never tested, and which is tested extremely often? can be achived by agile/technical means: Using Behavior driven development bdd as automated test for a userstory to verify that it is complete and still working. There are code coverage tools ...


3

I'm going to skip answering the parts of the question that do not make sense or are primarily opinion based. So, which plan should actually contain Risk Management, or it should be completely a separate document? Most software organizations don't do this at all or are not formal about it, so you can probably do whatever you want. If you think it ...


3

The short answer is that you can never be 100% sure. The longer answer is that this is also true for every other part of the product- you test it but can never test it for every possible scenario. The even longer answer is risk management and mitigation- your developers and architects need to asses the risk in solutions A and B (feature flags vs. ...


3

I am a BIG fan of feature toggles. It doesn't take too much work to mitigate the risks, and the benefits are well worth it. So my question is toggling unused feature enough to release untested code? No. Feature toggles are not enough to mitigate the risks posed by releasing completely untested code. However, when you test around that code, feature ...


3

This looks fine. BDD feature files is meant to be at a level to give useful information to product folks. In each step you can call lower level steps if you want to give more specific information (or more reusable actions) For this one for example Given I am signed in It might just call within it // enter the username GivenIEnterInTheField(string ...


3

I would recommend doing both approaches, for different purposes. Given / When / Then is good for testing communication. This format brings assurance that what you are testing is what the business owner / requirements writer intended. The bugs mainly caught by these tests, IME, are ones where the business owner intended X and the dev did Y. Often, these ...



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