[{"data":1,"prerenderedAt":572},["ShallowReactive",2],{"article_list_qa_":3},[4,340],{"_path":5,"_dir":6,"_draft":7,"_partial":7,"_locale":8,"title":9,"description":10,"excerpt":10,"tags":11,"image":16,"publishDate":17,"body":18,"_type":331,"_id":332,"_source":333,"_file":334,"_stem":335,"_extension":336,"author":337},"/ckeefer/2024-3/e2e_testing","2024-3",false,"","E2E Testing: To What End?","Friend, can we agree that tests are a good idea? I won't scorn you for sometimes omitting them - time and budget constraints are what they are, and even the best intentioned of us sometimes have to just give our projects a lick and a promise. \"Proper test coverage soon\", you sweetly croon as you rock it to sleep, the knowledge that you're telling a dark, terrible lie twisting you up inside. Maybe you could just scrape enough budget together for some simple unit tests? Then, at least, you'd have \"tests\", right?",[12,13,14,15],"qa","software-testing","e2e","playwright","/ckeefer/2024-3/img/E2E_Testing_2024.png","2024-06-15",{"type":19,"children":20,"toc":317},"root",[21,28,33,38,45,50,55,60,65,70,76,81,94,99,115,120,126,131,154,159,164,169,194,199,204,209,215,220,226,231,250,255,261,266,271,276,281,286,291,296,301,306,312],{"type":22,"tag":23,"props":24,"children":25},"element","p",{},[26],{"type":27,"value":10},"text",{"type":22,"tag":23,"props":29,"children":30},{},[31],{"type":27,"value":32},"Well, yes, but also no. Here at A+L, we often receive broken birds from prospective clients - projects from other developers that may never have worked properly, and certainly don't do so now. We offer an in-depth Code Analysis service, where we go through your project file-by-file, line-by-line, and work out why things are so slow, badly performing, buggy and broken in your codebase, and offer recommendations for how to remedy these issues. One of the things we often see in the worst of these projects is no testing at all; but the second most common theme there is nominal testing - the tests exist, they can be run, but they don't actually test anything meaningful.",{"type":22,"tag":23,"props":34,"children":35},{},[36],{"type":27,"value":37},"There are many flavours of testing. Unit and functional tests have their roles to play, and a comprehensive suite of testing will include them; but if you're looking for the most bang-for-your-buck, particularly on a web-based project, then you should be considering end-to-end testing.",{"type":22,"tag":39,"props":40,"children":42},"h2",{"id":41},"im-lost-what-is-e2e-testing",[43],{"type":27,"value":44},"I'm Lost: What is E2E Testing?",{"type":22,"tag":23,"props":46,"children":47},{},[48],{"type":27,"value":49},"At its core, end-to-end testing involves automating interaction with an application in a manner identical to that of its intended end user, in such a way that every element of the application involved in normal usage can be exercised and verified by the testing.",{"type":22,"tag":23,"props":51,"children":52},{},[53],{"type":27,"value":54},"For example, e2e testing for a web application would involve loading the site in a web browser (ideally the same browser and version(s) expected to be used by intended end users), logging in using the same interface an end user would, and exercising the various areas and functionality in the web browser by clicking, scrolling, tapping, double clicking, etc.",{"type":22,"tag":23,"props":56,"children":57},{},[58],{"type":27,"value":59},"This is accomplished by controlling (aka driving) a browser through an interface that allows programmatic control of its operations, and offers the ability to draw structured data back out of the browser to confirm its state. This allows a test suite to direct a browser to connect to a certain URL, wait for the browser to fire the appropriate events indicating that it has successfully loaded the page to the point where certain DOM elements are in place and interactable, trigger events and inputs against these elements, and receive the results of these interactions from the browser. Anything a human user could do with the browser can be thus automated and tested.",{"type":22,"tag":23,"props":61,"children":62},{},[63],{"type":27,"value":64},"Because the tests exercise the same functionality in the same way that an end user would do so, within the same environment and through the same interface, this approach to testing is more holistic than other approaches such as unit or functional testing (although it can be beneficially mixed with such tests in some cases). The application is at once tested from the client UI down to the server, database and related services. This is what lends end-to-end testing its name and value.",{"type":22,"tag":23,"props":66,"children":67},{},[68],{"type":27,"value":69},"This paradigm appears most often in web development, but can be applied to other arenas of software development where the appropriate tooling exists.",{"type":22,"tag":39,"props":71,"children":73},{"id":72},"sounds-easy",[74],{"type":27,"value":75},"Sounds Easy",{"type":22,"tag":23,"props":77,"children":78},{},[79],{"type":27,"value":80},"Have I convinced you this might be useful? Ready to start throwing some tests together? You've heard there's some automated tools to track clicks and navigation and such, you can get some juniors on this and get it done, right?",{"type":22,"tag":23,"props":82,"children":83},{},[84,86,92],{"type":27,"value":85},"Let's back up a moment. ",{"type":22,"tag":87,"props":88,"children":89},"em",{},[90],{"type":27,"value":91},"E2E Testing is software development",{"type":27,"value":93},". Not just that it tests software development, but that the tests themselves are software, and require the same level of attention to detail, careful planning and thoroughness in implementation as the software that it is testing.",{"type":22,"tag":23,"props":95,"children":96},{},[97],{"type":27,"value":98},"Well-crafted tests return their time investment manifold in the improved quality of the associated software; poor tests become a drag on project velocity without producing measurable benefits. It is very easy to create hideous spaghetti tests that are slow, brittle and difficult to maintain or expand upon; it requires skill and practice to create tests that are maintainable, expandable, fast and robust.",{"type":22,"tag":23,"props":100,"children":101},{},[102,104,113],{"type":27,"value":103},"Yes, there are ",{"type":22,"tag":105,"props":106,"children":110},"a",{"href":107,"rel":108},"https://playwright.dev/docs/codegen-intro",[109],"nofollow",[111],{"type":27,"value":112},"automated tools",{"type":27,"value":114}," that can help you throw something together quickly; no, you shouldn't rely on them, at least not exclusively - using them as a starting point may help expedite things, so long as you're prepared to refactor the often repetitive and loosely structured code generated by such tools into something robust and maintainable for your project.",{"type":22,"tag":23,"props":116,"children":117},{},[118],{"type":27,"value":119},"Not to dissuade you from embarking on your e2e testing adventures, but it shouldn't be an afterthought! You'll need to budget for it, plan for it, and structure it, the same way as any other feature of your codebase. Do otherwise, and you'll likely regret trying to integrate it at all. This leads to a third often seen issue with broken bird codebases brought to us from other developers - the tests started off strong, but quickly spiraled into messy spaghetti code that became brittle, difficult to maintain, and a drag on the project, until the tests were simply abandoned and left to rot.",{"type":22,"tag":39,"props":121,"children":123},{"id":122},"the-ends-justify-the-tests",[124],{"type":27,"value":125},"The Ends Justify the Tests",{"type":22,"tag":23,"props":127,"children":128},{},[129],{"type":27,"value":130},"Alright, so now you've soberly considered both the need for tests, and the structure and budget that tests will require, and you have your ducks in a row. Now you just need the tools, and to figure out how to use them.",{"type":22,"tag":23,"props":132,"children":133},{},[134,136,143,145,152],{"type":27,"value":135},"I recommend ",{"type":22,"tag":105,"props":137,"children":140},{"href":138,"rel":139},"https://playwright.dev/docs/intro",[109],[141],{"type":27,"value":142},"Playwright",{"type":27,"value":144}," as the current best in class for browser automation and e2e testing. It has all the functionality that was once the exclusive property of a tight binding with the devtools protocol, as found in ",{"type":22,"tag":105,"props":146,"children":149},{"href":147,"rel":148},"https://pptr.dev/",[109],[150],{"type":27,"value":151},"Puppeteer",{"type":27,"value":153},", without requiring the use of node.js; instead, there are language bindings for many of the languages commonly used in web development - JS, .Net, Java, and Python (both sync and async, although I would recommend use of the async API exclusively - more on that in a moment).",{"type":22,"tag":23,"props":155,"children":156},{},[157],{"type":27,"value":158},"Automated testing works best in an environment where tests will be run independently of developers, and report on the results of the test runs in a way easily visible to the team and project manager. Continuous Integration (CI) is one way of achieving these goals. CI is pretty easy to achieve these days, whether you're using Github Actions, Gitlab CI/CD, AWS CodePipeline, etc. The exact setup of any of these is outside of the scope of this article, but may be a future topic - stay tuned for that.",{"type":22,"tag":23,"props":160,"children":161},{},[162],{"type":27,"value":163},"In the meantime, wheter you have the means and motivation for CI or not, you can still take advantage of e2e testing. Let's assume you'll take my recommendation on Playwright, and discuss some SHALL and SHALL NOTs.",{"type":22,"tag":23,"props":165,"children":166},{},[167],{"type":27,"value":168},"Playwright logically organizes tests on a per-file basis, and aims to run tests in parallel. This leads to various considerations:",{"type":22,"tag":170,"props":171,"children":172},"ul",{},[173,179,184,189],{"type":22,"tag":174,"props":175,"children":176},"li",{},[177],{"type":27,"value":178},"Tests MUST NOT be interdependent between test files, or else parallelism is impossible.",{"type":22,"tag":174,"props":180,"children":181},{},[182],{"type":27,"value":183},"Tests MUST NOT alter state in such a way as to prevent other tests from executing within a clean context. Tests MUST isolate the impact of alterations to application state to those areas which are the concerns of the relevant test suite. This may mean mocking out certain aspects, such as the database or some other service, in some cases. Tests SHOULD NOT mock out elements except as needed, and then MUST document what is mocked and why, with reasoning as to the impact on the tests included in the documentation.",{"type":22,"tag":174,"props":185,"children":186},{},[187],{"type":27,"value":188},"Tests within a file CAN be interdependent (serially reliant), but SHOULD NOT be - a test SHOULD NOT require that another test within the same file be run before it to set state. Instead, a test SHOULD rely on appropriate hooks to produce the needed state for the test. If for some reason making tests serial within a certain file is particularly desirable, this deviation MUST be documented and re-evaluated regularly.",{"type":22,"tag":174,"props":190,"children":191},{},[192],{"type":27,"value":193},"Tests SHOULD focus on testing just one thing. Related functionality SHOULD be grouped together in the same file, but NOT the same test.",{"type":22,"tag":23,"props":195,"children":196},{},[197],{"type":27,"value":198},"E2E tests should be organized into their own directory, rather than living alongside source files - there is no reason to expect 1-to-1 mapping of test naming or areas of responsibility with those of application source files.",{"type":22,"tag":23,"props":200,"children":201},{},[202],{"type":27,"value":203},"Besides global and test-specific fixtures or setup/teardown functions, functionality ancillary to specific tests should live in the same file as the tests which use that utility. Utilities that are useful globally should not be imported from other test files, but organized into a separate file for import. This can include things like mocks, user profiles, authentication and authorization helpers, etc.",{"type":22,"tag":23,"props":205,"children":206},{},[207],{"type":27,"value":208},"Some areas of the application may not be suitable for e2e testing (for example, they rely on a 3rd-party service that, if mocked out, leaves too little to be worth testing for some reason). If this is the case, central documentation that is easily accessible and kept up-to-date should include areas that are excluded with detailed rationale, and these exclusions should be re-evaluated regularly.",{"type":22,"tag":39,"props":210,"children":212},{"id":211},"on-sync-vs-async-apis",[213],{"type":27,"value":214},"On Sync vs Async APIs",{"type":22,"tag":23,"props":216,"children":217},{},[218],{"type":27,"value":219},"As a tool for developers working in environments where async Python may not be available, or drop-in use for such projects, the Python binding for Playwright offers Sync and Async flavours. In truth, the Sync flavour is really “faking” a sync API via the use of greenlets, and this has an impact on certain elements and expectations of the application it’s running within. There are some circumstances where the sync API may be the right choice, but they are generally a “you will know it when you see it” scenario. If you don’t know whether you should use sync or async, you should use async. All new tests should be written using the async API. Playwright and the browser environment are both truly async in behaviour and expectations under the hood, and so employing the async paradigm is the correct and recommended approach.",{"type":22,"tag":39,"props":221,"children":223},{"id":222},"just-tell-me-what-to-write-darn-it",[224],{"type":27,"value":225},"Just Tell Me What to Write, Darn It!",{"type":22,"tag":23,"props":227,"children":228},{},[229],{"type":27,"value":230},"Okay, we know what tool we're using, and how to use it. What kinds of tests are we actually writing?\nOur tests will fall into three broad categories:",{"type":22,"tag":232,"props":233,"children":234},"ol",{},[235,240,245],{"type":22,"tag":174,"props":236,"children":237},{},[238],{"type":27,"value":239},"Functional Tests",{"type":22,"tag":174,"props":241,"children":242},{},[243],{"type":27,"value":244},"Adversarial Tests",{"type":22,"tag":174,"props":246,"children":247},{},[248],{"type":27,"value":249},"Regression Integrations",{"type":22,"tag":23,"props":251,"children":252},{},[253],{"type":27,"value":254},"Let's looks at each of these in turn, and discuss what considerations go into crafting them.",{"type":22,"tag":256,"props":257,"children":259},"h3",{"id":258},"functional-tests",[260],{"type":27,"value":239},{"type":22,"tag":23,"props":262,"children":263},{},[264],{"type":27,"value":265},"Functional tests should be crafted from the same requirements that lead to development tasks. Ideally the tests should be created by someone other than the developer that wrote the code to be tested. This allows validating the clarity of the requirements, and allows for revealing the  misunderstandings, assumptions and blind spots of the developer. When a developer writes their own tests, they may make the same mistakes twice. That said, tests written by the same developer are better than no tests at all.",{"type":22,"tag":23,"props":267,"children":268},{},[269],{"type":27,"value":270},"Testers do not need to be consulted during the requirements gathering/generation stage, any more than developers do in general; anything that can be made to be done in the browser can be tested via e2e testing, without exception. Some things are more difficult than others, and in the same way that requirements gathering might involve feasibility checks on development tasks, it may be worth consulting with developers experienced with e2e testing on whether a given feature or task, as written, would be more or less difficult to test than something equivalent but formulated differently.",{"type":22,"tag":23,"props":272,"children":273},{},[274],{"type":27,"value":275},"Tests should ideally be written just behind the code they are testing; ideally, an MR for a feature cannot be considered ready for merge without accompanying, adequate and passing tests. In cases where the developer and test developer are different individuals, the test and feature code may be written in parallel, but this raises significant difficulties for the test developer, such as identifying what the locators will be for the elements involved in the test; as a result, I'd suggest that all tests be written against code that is considered ready for inclusion in the codebase in general.",{"type":22,"tag":256,"props":277,"children":279},{"id":278},"adversarial-tests",[280],{"type":27,"value":244},{"type":22,"tag":23,"props":282,"children":283},{},[284],{"type":27,"value":285},"Besides testing the application “as intended” based on requirements, tests should also make efforts to exercise the forbidden or unexpected. For example, attempting to access areas of the application that the tested user shouldn't be able to interact with, making repeated requests in short order, sending unexpected data to the API, rapidly switching between areas of the application, etc., and confirming that attempts to access unauthorized areas or API endpoints does not succeed, rapid navigation doesn’t break expected layout, etc.",{"type":22,"tag":23,"props":287,"children":288},{},[289],{"type":27,"value":290},"This is a potentially expensive step in terms of time and implementation cost, as the ways in which your application should not function are less bounded than the ways in which it should. As a result, some smaller or simpler projects can and should skip or limit the scope of this element of e2e testing. On larger or more complex projects, however, it forms a useful part of the overall approach to catching unexpected behaviour and confirming authentication and authorization is working as expected, and is particularly important for applications where different user roles possess different permissions and/or access.",{"type":22,"tag":256,"props":292,"children":294},{"id":293},"regression-integrations",[295],{"type":27,"value":249},{"type":22,"tag":23,"props":297,"children":298},{},[299],{"type":27,"value":300},"Manual testing remains an important part of the overall testing plan and process, and an experienced QA will sometimes uncover bugs that were not discovered with the existing automated tests. When the bug is confirmed and its operation understood, this new knowledge MUST be encoded into the automated testing at that point. Creating new tests that can confirm the existence and triggering of the bug behaviour should be created as part of the process of fixing the bug, in the same manner as for the functional testing. These tests then become a way to catch regressions and offer developers and stakeholders confidence that future changes are unlikely to cause the return of previously resolved bugs.",{"type":22,"tag":23,"props":302,"children":303},{},[304],{"type":27,"value":305},"Care must be taken at this point not to allow the tests to degrade in quality and focus. It will be tempting to throw tests for bug behaviour into existing functional tests, or bundle multiple bugs together. Instead, each bug should be broken out into its own test. These tests can live in the same test file as related functional tests if appropriate, but the same approach to test isolation must be observed as for functional tests. Each test should aim to do one specific and easily identified thing, and never more than that.",{"type":22,"tag":39,"props":307,"children":309},{"id":308},"we-done-here",[310],{"type":27,"value":311},"We Done Here?",{"type":22,"tag":23,"props":313,"children":314},{},[315],{"type":27,"value":316},"Yeah, pretty much. Automated testing is such a critical part of software development, and it so often gets left for last, subsisting on the crumbs of budget left over after all the neat and shiny features have been completed. Don't let your project become one of the broken birds that clients bring to us to mend - put your e2e testing in the development schedule from the start, and give your project some healthy wings.",{"title":8,"searchDepth":318,"depth":318,"links":319},3,[320,322,323,324,325,330],{"id":41,"depth":321,"text":44},2,{"id":72,"depth":321,"text":75},{"id":122,"depth":321,"text":125},{"id":211,"depth":321,"text":214},{"id":222,"depth":321,"text":225,"children":326},[327,328,329],{"id":258,"depth":318,"text":239},{"id":278,"depth":318,"text":244},{"id":293,"depth":318,"text":249},{"id":308,"depth":321,"text":311},"markdown","content:ckeefer:2024-3:e2e_testing.md","content","ckeefer/2024-3/e2e_testing.md","ckeefer/2024-3/e2e_testing","md",{"user":338,"name":339},"ckeefer","Christopher Keefer",{"_path":341,"_dir":342,"_draft":7,"_partial":7,"_locale":8,"title":343,"description":344,"tags":345,"publishDate":346,"excerpt":344,"image":347,"body":348,"_type":331,"_id":566,"_source":333,"_file":567,"_stem":568,"_extension":336,"author":569},"/areichert/2023-10/rapid-testing-techniques-for-web-and-mobile","2023-10","Rapid Testing Techniques for Web & Mobile Apps","Testing rapidly or the need to test quickly under shortened execution cycles is not new. Rapid testing has been around for as long as software testing has existed but increases when a product release is imminent, strained, or behind schedule. There are many reasons development gets behind schedule. Similar to testing, development is prone to surprise requirements changes and increases in scope and complexity.",[13,12],"2024-06-01","/areichert/2023-10/img/rapid_testing.png",{"type":19,"children":349,"toc":560},[350,354,359,364,369,373,379,384,389,394,432,437,442,448,453,458,463,468,473,479,484,512,517,522,527,533,538,550,555],{"type":22,"tag":23,"props":351,"children":352},{},[353],{"type":27,"value":344},{"type":22,"tag":23,"props":355,"children":356},{},[357],{"type":27,"value":358},"What usually happens is the time lost is regained by shortening the testing schedule. The impact of a shortened testing cycle depends on the complexity of the application, the tester’s experience level, and if continuous testing is used or if all testing is completed near the end of the development cycle. In other words, organizations with continuous unit testing or valid, functional test automation for regression may suffer less than others.",{"type":22,"tag":23,"props":360,"children":361},{},[362],{"type":27,"value":363},"What can be done as a QA to adapt and switch gears? Rapid testing is common. Rapid testing works but the quality of the testing and test coverage relies heavily on tester experience and application knowledge. The keys to effective rapid testing are the techniques used, the tester's knowledge of the application functionality, and a rapid testing strategy or plan.",{"type":22,"tag":23,"props":365,"children":366},{},[367],{"type":27,"value":368},"This guide describes testing techniques and practices for managing rapid test execution while also keeping application quality high.",{"type":22,"tag":370,"props":371,"children":372},"toc",{},[],{"type":22,"tag":39,"props":374,"children":376},{"id":375},"what-to-do-when-your-testing-time-is-cut-short",[377],{"type":27,"value":378},"What To Do When Your Testing Time is Cut Short?",{"type":22,"tag":23,"props":380,"children":381},{},[382],{"type":27,"value":383},"If you’re new to software testing, or part of a team of testers for heavily regulated software, then you may not have experienced the routine occurence of testing time being reduced to hit a previously promised release date. For many software testers timeline changes occur frequently. When backed into a literal testing corner, testers must learn to use a variety of testing techniques that support rapid testing without negatively impacting application quality.",{"type":22,"tag":23,"props":385,"children":386},{},[387],{"type":27,"value":388},"The first step in managing rapid testing is having a plan or strategy. By defining a strategy, testers gain the time to review, experiment, and ensure the strategy works well. Be prepared to update and make changes as lessons are learned. Like many Agile-type projects, rapid testing relies on continuous improvement to fully meet a testing team’s unique needs.",{"type":22,"tag":23,"props":390,"children":391},{},[392],{"type":27,"value":393},"Within your rapid testing strategy, identify:",{"type":22,"tag":170,"props":395,"children":396},{},[397,402,407,412,417,422,427],{"type":22,"tag":174,"props":398,"children":399},{},[400],{"type":27,"value":401},"Test case priority",{"type":22,"tag":174,"props":403,"children":404},{},[405],{"type":27,"value":406},"Customer workflows",{"type":22,"tag":174,"props":408,"children":409},{},[410],{"type":27,"value":411},"Duplicate tests between developers and testers",{"type":22,"tag":174,"props":413,"children":414},{},[415],{"type":27,"value":416},"Existing test automation",{"type":22,"tag":174,"props":418,"children":419},{},[420],{"type":27,"value":421},"Recent defects",{"type":22,"tag":174,"props":423,"children":424},{},[425],{"type":27,"value":426},"List of exploratory tests based on application functional groups",{"type":22,"tag":174,"props":428,"children":429},{},[430],{"type":27,"value":431},"List of web and mobile app differences, if any",{"type":22,"tag":23,"props":433,"children":434},{},[435],{"type":27,"value":436},"Rapid testing is best performed when it’s planned. However, the first few times it may come as a surprise. In either case, it’ll save you time and effort if you create even a quick testing strategy. A test strategy doesn’t have to be long and complex. Even a simple checklist will work. What you need is to understand what tests are the highest priority for customers and define the minimum testing possible to release a quality application.",{"type":22,"tag":23,"props":438,"children":439},{},[440],{"type":27,"value":441},"Once you know the testing that must be done, effective test suites can be created and tasks assigned. Knowing the number of testers and maximum tests enables testing teams to ensure test coverage needs are met. Sacrificing qualify for speed is never ideal, but often it’s a business reality.",{"type":22,"tag":39,"props":443,"children":445},{"id":444},"what-are-rapid-testing-techniques",[446],{"type":27,"value":447},"What are Rapid Testing Techniques?",{"type":22,"tag":23,"props":449,"children":450},{},[451],{"type":27,"value":452},"The main goal of rapid testing is to test all application functionality at least once. Testing each function at least once requires understanding the existing test cases and their related objectives. The test cases themselves may be automated or manual, the team just needs to create the test execution suites with tests that exercise each function at least once.",{"type":22,"tag":23,"props":454,"children":455},{},[456],{"type":27,"value":457},"Another way to manage rapid testing effectively is to eliminate test duplication. In other words, don’t simply create a series of regression or smoke test suites randomly without understanding the tests and objectives.  90% of regression suites contain numerous duplicate tests. Executing duplicate tests wastes time. It’s important to limit testing to covering all functionality at least once.",{"type":22,"tag":23,"props":459,"children":460},{},[461],{"type":27,"value":462},"Consider creating a separate rapid testing regression suite made from exploratory test tours developed specifically for customer workflows. In this way, you’ll have a dedicated suite of tests specifically designed for testing the functionality customers use the most.",{"type":22,"tag":23,"props":464,"children":465},{},[466],{"type":27,"value":467},"Another method for reducing test duplication is to test web and mobile apps in tandem. For example, if a web client exists alongside a mobile client, create exploratory test scripts that test both of them at the same time. Cover the functionality of both, along with the data, APIs, and integrations of each all in one test execution. Avoid running the same tests on both platforms separately wherever there are shared elements.",{"type":22,"tag":23,"props":469,"children":470},{},[471],{"type":27,"value":472},"Creating a test suite of exploratory testing may prove useful, but if there’s no time then simply dive in. Dive in by assigning functional areas or customer workflows and have testers run through them. Consider designating a priority for each functional area. Run the highest priority tests first and then continue with the rest. A high-priority test is anything that negatively impacts customers using the application.",{"type":22,"tag":39,"props":474,"children":476},{"id":475},"how-to-decide-which-tests-to-execute",[477],{"type":27,"value":478},"How to Decide Which Tests to Execute?",{"type":22,"tag":23,"props":480,"children":481},{},[482],{"type":27,"value":483},"To organize the best value for rapid testing select tests with the following:",{"type":22,"tag":170,"props":485,"children":486},{},[487,492,497,502,507],{"type":22,"tag":174,"props":488,"children":489},{},[490],{"type":27,"value":491},"End-to-end test coverage",{"type":22,"tag":174,"props":493,"children":494},{},[495],{"type":27,"value":496},"Backend functionality tests including APIs, database interactions, and messaging systems",{"type":22,"tag":174,"props":498,"children":499},{},[500],{"type":27,"value":501},"Essential customer functionality",{"type":22,"tag":174,"props":503,"children":504},{},[505],{"type":27,"value":506},"Calculation verification",{"type":22,"tag":174,"props":508,"children":509},{},[510],{"type":27,"value":511},"Critical UI data display",{"type":22,"tag":23,"props":513,"children":514},{},[515],{"type":27,"value":516},"Rapid cycle test suites may include smoke tests but should focus on full regression test cases if possible. Smoke tests are valid and useful, but don’t guarantee an application functions well enough to satisfy a customer’s needs. Successful smoke tests merely indicate the application pages open in a readable state. Most customers will demand more from an application than that all the pages open and the links are accurate.",{"type":22,"tag":23,"props":518,"children":519},{},[520],{"type":27,"value":521},"Imagine you’re getting ready to file government taxes using a cloud-based website. As a customer you’ve entered in all your financial and tax data, and scanned in your receipts, only to find out you can’t submit or save. All the work you’ve put in is now useless and you lose all the data as soon as the application closes. It’s no consolation that all the pages render correctly if you can’t accomplish your goal.",{"type":22,"tag":23,"props":523,"children":524},{},[525],{"type":27,"value":526},"Similarly, it’s critical to verify calculations and all displayed data. Most regression tests can prove API, database, and messaging systems are functioning as expected. If you pass valid data through the system and the calculations work, the backend is functioning. Choosing to include end-to-end tests is helpful in providing customer workflow coverage. Keep in mind the most important goal is keeping the customers happy using the application.",{"type":22,"tag":39,"props":528,"children":530},{"id":529},"tips-for-managing-quality-test-coverage",[531],{"type":27,"value":532},"Tips for Managing Quality & Test Coverage",{"type":22,"tag":23,"props":534,"children":535},{},[536],{"type":27,"value":537},"There’s no good way to speed up testing without sacrificing testing quality. However, by creating a rapid test strategy and a suite dedicated to rapid test cycles, testing teams can retain test coverage and still ensure a high-quality release. If you find rapid testing becomes the norm in your organization, consider utilizing continuous testing techniques.",{"type":22,"tag":23,"props":539,"children":540},{},[541,548],{"type":22,"tag":105,"props":542,"children":545},{"href":543,"rel":544},"https://www.telerik.com/blogs/continuous-regression-testing-pros-cons-how-works",[109],[546],{"type":27,"value":547},"Continuous testing",{"type":27,"value":549}," can be performed with both manual and automated tests. Expanding automated test development is also a strong option for times when testing needs to be executed rapidly and repeatedly during the development cycle.",{"type":22,"tag":23,"props":551,"children":552},{},[553],{"type":27,"value":554},"Managing quality is important to ensuring the application releases satisfy customers. After all, without customers, there is no application. It’s business critical to ensure customers can use the application and reach their goals without annoyances, interruptions, or defects.",{"type":22,"tag":23,"props":556,"children":557},{},[558],{"type":27,"value":559},"Rapid testing works and it eliminates waste within the testing process. Plan for rapid testing and develop test suites to support it and your QA testing team will always be prepared to deliver quality.",{"title":8,"searchDepth":318,"depth":318,"links":561},[562,563,564,565],{"id":375,"depth":321,"text":378},{"id":444,"depth":321,"text":447},{"id":475,"depth":321,"text":478},{"id":529,"depth":321,"text":532},"content:areichert:2023-10:Rapid Testing techniques for web and mobile.md","areichert/2023-10/Rapid Testing techniques for web and mobile.md","areichert/2023-10/Rapid Testing techniques for web and mobile",{"user":570,"name":571},"areichert","Amy Reichert",1780330265161]