1 / 12

Manual Test is Unsustainable

ExlTech has designed a software testing course along with an exhaustive coverage of manual as well as automatic testing concepts. Our course covers basics of manual testing

adityausit
Download Presentation

Manual Test is Unsustainable

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Manual Test is Unsustainable

  2. Index

  3. Manual Test is Unsustainable: -Creating automated tests can be very difficult, especially if the code is long in the tooth and has not been created with automated tests. -Many product development teams do not invest in automated tests. They think they can't afford them. You think your product is different and cannot be automatically tested. This thinking is flawed.

  4. Back in the recent days of the products, the manual test was not too time-consuming. But that changed slowly. The system is growing, the manual test effort is growing. After all, it seems that no manual test effort finds all the problems. If we have issued 10 development units, to create a number of new features, we assume that it only needs 5 units to test the new functionality. In other words, test effort is proportional to development effort by a constant factor.

  5. -We know it's not that easy. The coefficient is certainly wrong, and to think that all development efforts are the same, is wrong, but it is a simple model that can help us to explore the folly of manual Tests. In addition, the simple model is implicit in the workflows of most companies. -Companies tend to have fixed resources, I mean people, build and test their products. There are the developers and the testers. Or maybe there are developers who change hats and spend some of their time testing. Either way, there is a de facto develop: test coefficient in practice at your workplace.

  6. What's the problem?! Everyone knows that software works without further effort as soon as you let it work. [Huh, what did he say?] Please don't quote me out of context, I'm just being sarcastic. Let's pull some wisdom out of the system Bible to scare you, change code that isn't covered by automated tests. The system Bible says “ " when a system works, leave it alone.""Systmes does not like to be played with violins."Now put John Gall. I guess all US programmers are unemployed. Our business is to change and develop software. We need to find a way to accept the warnings from the system Bible and to advance our systems further.

  7. -With each iteration, not only the new functionality must be tested, but also the working functions of the previous iterations must be tested again. No problem, just add some more resources; I use my plug compatible test units; I mean people with the skills and knowledge needed. -The reality of the situation is that we don't have unlimited budgets, and if we did, you wouldn't be able to hire people with the skills and knowledge needed that are fast enough to fully test the product. And this means that we have to face the reality of the growing untested code gap. -The untested code gap is killing productivity and predictability. We do not choose where to go the beetles and make them easy to find; they choose their hiding places and have no mercy with us. They flare up and put teams in fire extinguishing mode.

  8. Are we beaten? Do we have to settle for buggy products and long test and fix cycles? No, we're not! We must accept that a product test strategy based on manual testing is unsustainable. Unsustainable systems will collapse eventually. We can't afford not to automate much of their software testing.

  9. RB Grady says that 25% of the bugs in your bug list are the result of someone adding a new feature or fixing a bug. So we can't just assume that the functions of previous iterations will work; we need to test them again. Let's refine the model.

  10. To know more abou software testing visit us: https://www.exltech.in/

More Related