Fibonacci series is just one example for estimation efforts. Some teams also use series as below:
1, 2, 5, 8, 20, 40, 100, ....
1, 2, 4, 8, 16, 32, 64, ....
The idea is to use an exponential scale for estimating efforts.
The reason is the larger the story point, the more uncertainty there is around it and the less accurate the estimate will be.
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 - ...
They reflect that the degree of uncertainty grows as you look further out and at bigger tasks with more dependencies.
For example, today you can be reasonably confident about how much effort is needed for a small task. You may be highly confident that you can finish it within a day, and, critically there is little uncertainty about the factors involved. So ...
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 ...
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, ...
How do you know when to stop testing?
There are a number of factors. They are not exclusive and the degree to which they apply will vary for each situation for each organization.
Time - This is clearly a common constraint for most organizations. It can also be a guide for testing efficiently and finding and fixing the most critical errors first.
Good question. Here I am going to explain some steps from my experience.
1) We need good teamwork for that.
2) Here I just want to clarify that "Execute All Test Case/Suite" term. We need to prioritize test cases in four quadrants like below.
3) Do a good amount of Exploratory Testing instead of totally scripted approach.
4) Try to cover all business-...
First of all, your question is way too vague and board, we can not help you without knowing specifics.
Having said that, in general, from a function point of view, there are two categories of tests we can perform.
Functional: this is perhaps what those scripts are for and as you described, you are not planning to test functional features.
Non functional: ...
I don't see CI/CD as something different than non CI/CD process, tests are simply being run by a non human entity.
Do you need a test plan (or plan your tests) ? of course you do, you need to think what goes into automation and whether something should be done manually or tested in production (A/B tested, telemetry), analyze risks related to testing this ...
20% of the features deliver 80% of the value. If you deliver in small chunks hopefully people can start using the most valuable features after the first 2-3 months already. Now you might get a paradigm-shift, probably you will not need the two years of imagined features. Let's say the business owners get new insights and make a small shift in functionality, ...
What are the most important components/parts of a well-written test plan document for a testing project. Consider you are testing a Financial web app.
As per IEEE 829 standards, the components of a Test Plan document should be :
Test Plan identifier
Items to be tested
Features excluded for testing
Do you still need a Test Plan when using CI/CD?
YES you do. Because a test plan will tell you at least the thing that you did not specify in your question: how often do you plan to run the tests? Which tests will run with which periodicity?
Maybe there is a common practice to do it every night. Is it feasible for your project? Which alternatives do you ...
Basically you never have enough time and resources to test everything, your test cases are already a subset of this infinite "everything".
What should you do then ? prioritize. A common heuristic is RCRCRC:
Recent: new features
Core: essential functionality of your product
Risk: risk is defined as the Probability of occurrence (how likely is it to ...
Given a simple application diagram how would you test it or what will
be your test plan or test strategy.
The only answer to a question like this is: "There is no such thing as 'go there and test'". Testing is performing a risk investigation activity. Any investigation has goals and questions to be answered.
So, what type of testing one usually do ...
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.
Let's say that the database schema is such that some queries will be ...
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 ...
So is there any perfect test plan template which I can use for one
website and I am only tester.
No. There is no such thing as a "perfect test plan template". Instead of perfection, strive for "good enough for your needs".
Since you are the sole tester, start out with something simple. Note what you are testing, when you are testing, the environment you ...
Here are some test-specific activities for the startup phase of an Agile project.
Think about managing the test efforts and results in the Agile process. Will you write many test cases (in detail) - which might demand a lot of effort to maintain as requirements are changed during the project. Personally I would recommend something like ...
Below are the components of a test plan, which should be included.
1.1. Introduction - Provide an overview of this document in this section
1.2. Scope of testing - The scope of testing needs to be clearly defined. The plan should define items / features that are in scope or out of scope for the testing phase.
- 1.2.1. **Features To be tested** ...
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 ...
It depends on your company's preferred methodologies. You should keep a record of the test cases you performed to verify the fix, but most likely won't need anything as formal as a test plan for that.
Depending on how the fixes are implemented, especially when testing old code, you may want to execute other test plans of the product where the bugs were ...
Feedback also from my side what I learned from projects.
1. Prioritize the test cases
In my past projects we prioritized the test cases. We used HP ALM and there we had also couple of test cases and it was impossible to execute the all. So what we did is just to prioritize the test cases e.g. Critical, Very High, High, Medium, Low - same as you would do it ...
Common estimating methods include numeric sizing as well like 1 to 10 or sizes like XS, S, M, L, XL, XXL, XXXL or Fibonacci sequence 1, 2, 3, 5, 8, 13, 21, 34, etc.
The reason for using the Fibonacci sequence is to reflect the uncertainty in estimating larger items. A high estimate usually means that the story is not well understood in detail or should be ...
Firstly, I would be careful when communicating this type of relationship between test cases and your testing, because, test cases are not testing. Promoting otherwise may cause issues both for the stakeholders who won't understand what is happening and for the tester who will have less leverage to promote deep testing.
Testing is the process of evaluating a ...
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 ...
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 a ...
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 moderately-...
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 ...
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 ...
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