So based this scenario if somebody conclude test engineers only tests the new scenario or 80% of the effort must go to the testing process of new feature and regression should based on sanity.Will that work???
No…the regression might produce some more bug.Or due to fix of a bug might discover the hiding bug.Remember the cost of bug…
|Cost of bug|
The factors affecting testing process
Inadequate time to test the whole UAT Challenges in Testing world:
This is an important factor for Challenges in Testing(Software Testing challenges).There could be several factors due to which project development may get delayed.in the followup there is often a tendency to cut short the post development activities. The first one to target is testing!!.Indeed, this is a mystery, I would state. The truth is different.
The testing process,be it is automation or be it is manual, constantly given least need as far as time distribution is concerned in a project planing.I have seen tasks getting postponed by development group because of poor coding,lots of bugs logged but toward the finish of the fault went to the testing group for not guaranteeing the assemble right time.
No tester can test an application start to finish in the present testing time allotment. Best practice says 40% time of the improvement time is dispensed to testing. Yet, that isn’t sufficient to test the total bit of Product.
40% standard time might be appropriate for little application however for long ventures with heaps of relapse may require more than or break even with time like advancement. However, till the time individuals comprehend this law, analyzers are troubled with the time factor.
Time factor is a crucial factor and lack of it adds Challenges in Testing(Software Testing challenges).
Why it is not possible to test whole bit of a product?
A full phased product has many modules,sub modules. Each module will contribute numerous amount of test conditions.To document all test conditions and execute manually is a tedious job. Automation also needs to develop all these flows. Which is a impossible task too. This contributes to Automated Testing challenges.
This prime factor prompts another testing disorder Priority issue.Test engineers get genuine perplexity which experiments to pick and what to run. The situation deteriorates when there is a ton of relapse.
The schedule is unrealistic.Sometimes the managers just gives the date to get the project or the task.(I understand their pain) again sometimes the technological difference between the resources and managers create this problem.During Cross functional working the problem goes high.The other manager does not understand the pain what other track’s resources is going through.
Problem with this approach
Then again, if test engineers are going to take additional time, it might defer the time to market of a product. The testing procedure goes for a hurl when it is said to test the total application inside a small time span. Additionally, many automation builds(like we do in CICD build pipeline) isn’t great. It frequently prompts a different input circumstance due to which the primary target of the testing is moved.
The new way to go is via Agile methodology or extreme programming. These give adaptability for an organization to dispatch it’s item quicker in the market. The drawback of this, testing turn out to be exorbitant and even a miss is costlier.
Quality takes a major hit during such planing.It puts immense pressure to the testing tea,. That results a poor quality testing or leads to risk based testing. This may lead to a situation to test some aspect and some aspect remains untested.
What to do when we have less time?
Since it’s once in a while conceivable to test every possible part of an application, every possible blend of events,each reliance, or everything that could turn out badly, risk examination is suitable to most programming advancement ventures. Use risk investigation to figure out where testing ought to be engaged. This requires judgment aptitudes, presence of mind and experience.
The risk based test cases should be chosen based on the following criteria:
- Which functionality is most essential to the proejct for the scope?
- And which functionality is most obvious to the client?
- Which functionality has the biggest well being impact?
- Also which functionality has the biggest money related effect on clients?
- Which parts of the application are most critical to the client?
- And which parts of the application can be tried right off the bat in the advancement cycle?
Which parts of the code are most intricate and subsequently most subject to error or defect?
- Also which parts of the application were created in surge or frenzy mode?
- Which parts of comparable/related past ventures caused issues?
- Then which parts of comparative/related past tasks had vast upkeep costs?
- Which parts of the prerequisites and configuration are hazy or half-baked?
- What do the designers believe are the most noteworthy risky parts of the application?
- And what sorts of issues would cause the most noticeably awful attention?
- What sorts of issues would cause the most client administration grumblings?
- Then what sorts of tests could without much of a stretch spread various functionalities?
- Which tests will have the best high-chance inclusion to time-required proportion?
Once we create test set covering all these points, we can say the risk based testing is over. Risk based testing is not substitute for actual testing. It is just a quick check. As it is a prime factor for Automated Testing challenges(Software Testing challenges), we need to be careful.
How to solve?
- We need to migrate to a CICD pipeline or a DevOps technology in order to support agility. Ordinarily, we do a Risk-based testing.
- Always check for schedule plan of deliverable . If we lag somewhere, we need discuss the same with scrum master along with the team.
- If it is a non agile,we need to keep other manager informed.
- Just providing information is not enough. Since the schedule is going towards red, we need to provide a go to green plan as well.
- In traditional waterfall model,we can use the responsibility matrics to figure out the deficit so that we can work on them. But in agile,we need to take risk based testing and put everything in backlog. Backlog needs to be flushed as soon as possible.