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