68
You are about to embark on a journey without end, so it is the means, not the ends, that are important.
Deciding where to start
Business first: As Laura said, make sure that your work directly improves areas important to the business
Metrics: It is critical to get good metrics both before you start and as you progress. Keep your metrics current, preferably ...
7
There's no problem being BA+QA, but it looks that you're also an Architect in your project.
I see a direct evil in combining Architect and QA roles.
You have noticed for yourself every concern: the natural role of Architect is to stand up for idea that "the program is working". The natural role of QA is a direct opposite: to prove that "the program is not ...
6
Yes. I call them Contract Tests. One easy way to understand them:
Start with tests for a specific implementation of the interface. For example, consider ArrayList implements List. You write tests for ArrayList. One test could be this:
testEmptyIffZeroSize:
list = new ArrayList()
assert list.isEmpty()
assert_equals 0, list.size()
Notice that ...
6
Data:
Use each of the following payment methods: X, Y, Z, ...
Procedure:
....
....
....
I don't see how any professional tester won't understand that you want to validate with each payment method.
If for any reason the tester to whom you are writing this documentation gets confused, a 30-seconds conversation with you probably will solve any ...
4
First of all, it is understandable that a former developer might approach testing in terms of individually testable layers or sub-components. However, as a tester, if you do nothing else, you must verify that the finished product behaves correctly when exercised using whatever interfaces the end-user will use. Everything else is secondary to that -- ...
3
Yes. You provide values for the parameters in the test cases where the shared steps are used.
You don’t have to provide values in the shared steps definition. However, you can provide one default row of values, which is used when you create an action recording of a standalone shared step.
3
The idea of risk based testing is that your context defines what the risks might be. What is important to me is not necessarily important to you. So there won't be a checklist that will work for everybody.
Having said that: you might find this HTSM explanation useful. To guide your thinking about what could be risky in your situation and what area would ...
3
stacky-bit, maybe Model-based testing approach is what you are looking for?
Using this approach, you can generate all possible "abstract tests" that are based on the model. Such approach can be used on, for instance, military projects with a lot of people (such case is described in Experiences of Test Automation Dorothy Graham & Mark Fewster)
The pros ...
3
This is surely the low bar, but there are ways to test Java beans automatically; see for example http://macbeantechnology.co.uk/blog/automate-testing-javabeans/.
I think the academic literature has a lot to say about about generating tests from specifications. A Google search of "generate tests from formal specification" will turn up lots of results; see ...
3
There are tools that will generate a set of tests that cover every combination at least once without hitting all possible combinations (these work on the principle that most bugs will be surfaced by exercising pairs of settings).
Since the feature hasn't gone live, your business analyst is probably your best reference for the combinations that are most ...
3
You should aim to create the data yourself
although whether you are doing manual or automated testing is a key factor and the following mostly applies to automated testing.
One of the principles you should be looking to follow when performing automated testing is
setup - execute - teardown
Basically you want the system and most notably the data store to ...
3
If I were in your shoes, I would thing about adding another person to test, in addition to yourself. It sounds like you are already doing a good job with accepting the story/feature, but have a little "author blindness" which leads to missing some minor issues. Adding another set of eyes will benefit the quality, while not losing your expertise.
2
Additionally to Tangurena approach I suggest writing several tests at the highest level possible. Essentially this will be a test that your software works as intended. If most sub-systems are involved in the test, then any error in any of the systems will show a malfunction in that test. It will not pinpoint your problem but will show if some refactoring ...
2
In general, a test case is a pair of an input and an expected output
(or as many books say, it mostly has just a single step: do sth and
check it).
A test case or a simply "a test" is an experiment we run in order to reveal some information about a product or service.
one often has to follow certain actions/steps
Only if you are taking the ...
2
+1 for it depends
If the upload operation in your example can only be done through the mentioned failed menu than it is difficult to not fail it.
OTOH maybe you are part of the "upload team" and all you want to do is verify this small operation and not end to end integration, so failing the test is out of the question
Another approach (I use it with ...
2
My answer is going to be very opinion-based (as is your question) but, that is the approach we use. We manage our test via Excel (which completely sucks) and, if test steps are shared between tests we basically say "repeat these steps...". We use this same approach for both manual and automated test cases.
2
It really has nothing to do with whether someone could alter the input file or not; it's a matter of what the code is documented/expected to do, and expected to deal with. You also need to know what level of testing you're doing. Are you testing the individual pieces (unit/function testing), or testing the end-to-end functionality (integration testing)?
...
2
Your test case seems fine, if that is truly the requirement. Before going further, I would check with the Product Manager or someone if that functionality is intended (and just not documented in the FSD).
If the FSD is truly "the bible", I would phrase the test case "System must not expose functionality that is not documented in the FSD", but this is just ...
2
I don't know how much my answer will be useful for you; but Yes, we do use the same for testing parts of our applications that work in back-end e.g. we use it for testing webservices response, Database testing and currently we are using it for ETL testing too.
For example:
Given: CSV file to be imported is located at xyz location
When: ETL process A ...
2
I would consider:
test low bandwidth as well as none. Chrome has an option to emulate slower connections.
testing posting empty comments and large comments.
test posting comments with special characters including letters with inflections
test posting comments as a sql injection attack
check if a comment can be posted twice or if it considered a dupe
test ...
2
I don't think there's any real benefit from being thorough when writing test cases. For two main reasons:
you want other testers to use their imagination as well, which rarely happens when people follow written instructions
it would take you so much time that you could spend better, e.g. exploring the system
Sure, there might be some exceptions, but I ...
1
Some of the scenarios like below can be considered
Checking the language representation - Multilingual
Multiple Location
Auto location
Enable Manual location selection
Checking the fonts and Themes
1
You can use some of the below-mentioned test cases for your question that helps in validating the functional testing requirement in software testing services company.
Ensure weather widget ask to enable auto location if it was disabled.
Ensure weather forecast is correctly locate your place automatically if auto location is enabled
Ensure forecast should be ...
1
Types of non functional testing are:
Performance Testing
Load Testing
Failover Testing
Security Testing
Compatibility Testing
Usability Testing
Stress Testing
Maintainability Testing
Scalability Testing
Volume Testing
Security Testing
Disaster Recovery Testing
Compliance Testing
Usability Testing
Portability Testing
Efficiency Testing
Reliability Testing
...
1
This would be your test precondition, of which if successful would mean Step 1 you are ready to go with the test. For example, precondition "query database to find X order, navigate to order". Step1 - Using order from precondition, press button Y
If the precondition can be achieved then the test case can be run. If the precondition cannot be achieved ...
1
Different testers have different ideas about test cases. Sometimes, a test itself is called a test case
A test case is one particular instance or variation of a test or test
idea
A test procedure is a way of performing a test.
A test activity is a line of investigation that fulfils some part of
the test strategy. It can encompass many test cases.
There is ...
1
Generally speaking these concepts are mostly misunderstood and the standards, if any, are not followed by the companies in most cases. I would, at least, from my experience can tell software are so versatile to put them in such categories/boundaries. Additionally, as a Senior Q.A I have been practicing testing the scenarios/test cases out of box with having ...
1
The answer is no.
Equivalence partitioning is used for input or output values of a software component, so that you can derive test cases using representative values of the partitions.
Example:
If you want to test a function which determines the winner of a game after it has ended, and there are two input parameters pointsPlayer1 and pointsPlayer2, the ...
1
This sounds like you might need to build some custom code, I haven't heard of anything that does this off the shelf, for any language. However, here's an approach I think might work;
Assuming your using well structured objects, create a facade object that wraps the behaviour of the class under test, and present the facade to your normal application. ...
1
Additionally to the great answers seen here, I'd like to add the following:
Have different test sets, one small "smoke" test set containing only a few tests to run on each CI build, and a more thorough one running over night.
Avoid Sleep statements in your tests. Those are almost always a sign for bad test code, as they make your tests slow and/or ...
Only top voted, non community-wiki answers of a minimum length are eligible
