3 Steps for Determining What Test Cases to Automate
Know your goal and scope of the test case
Be objective about the test case’s complexity and risk-levels
Make sure that your testing efforts are well-balanced in time, efforts, and budget
The value of automated testing is proportional to the number of times a test may be repeated. Manual testing is preferable for tests that are only performed a few times. Test cases that are run frequently and require a substantial quantity of data to execute the same action are good candidates for automation.
Automating the following tasks will help you get the most out of your automated testing efforts:
Tests that are repeated for numerous builds.
Tests that are prone to human error.
Tests that necessitate the use of numerous data sets.
This is a frequently used feature that introduces high-risk situations.
Tests that are impossible to complete by hand.
Tests that are performed on a variety of hardware and software platforms and combinations.
When manual testing, tests that involve a lot of time and effort.
DevOps is an iterative process that occurs throughout the product development process. In the usual DevOps process, there are various stages. The phases are listed below, along with descriptions of the intersection of development and operations and how they fit together in the DevOps model. Let’s have a look at each phase in detail. The “DevOps infinity loop” is a popular metaphor for this.
Plan: During this phase, the software will be planned. Data from software monitoring in operations can help impact planning, so there’s a connection between development and operations.
Code: The programme modules or functionalities are coded in this section. Different team members can work independently using version control systems such as Git, committing their modifications and submitting pull requests to the main branch.
Build: The software is turned into machine-readable instructions. Continuous integration servers make sure that the programme is always up to date with the latest commits.
Test: The testing phase is where the development and operations teams run manual and automated tests.
Release: The software is released into a pre-production environment during this phase.
Deploy: Deployment entails both the promotion of the software into the production environment and the setup of the software.
Operate: The operations team makes sure the programme is working properly in both functional and non-functional areas. Monitoring performance, adjusting for load, and making additional configuration adjustments are all part of this phase.
Monitor: Continuous monitoring aids the development team in anticipating future changes, such as bug repairs. It also serves as a starting point for the development team’s production configurations for future releases.
******************* Java-Basic ******************* 1. Types of polymorphism 2. Difference between override and overload 3. Methods that cannot be overloaded 4. Static block and instance block 5. Difference in Static and non static 6. Encapsulation and common use cases 7. Abstract vs interfaces 8. Inheritance in java 9. Methods that cannot be overloaded 10. Type casting in java 11. String buffer and string builder 12. Why string is immutable in java 13. How to handle exceptions 14. Can I write try catch without the catch block 15. Difference between throws and throw 16. Use of iterator in java 17. Difference in Final, finally and finalize 18. Boxing and unboxing in java 19. Increment and decrement operation 20. Variable Args 21. This and super keyword in java 22. Issues during Swtich case without break 23. Upcasting and downcasting 24. Baseclass of all class in java 25. Baseclass of error and exceptions 26. Access specifiers 27. Continue and break statement 28. Can main method return any value 29. Can we overload main method. What happens when overloaded 30. how to execute and statement before main method 31. Difference between == and equals() 32. Can user declare constructor as final 33. Can we cast any other type to Boolean data with type casting. 34.does java compile if user use ‘static public void’ instead of ‘public static void’ 35.can we use this() and super() in a constructor 36. Can we create object of abstract class 37. Can we create reference for an abstract class 38. Can we declare a class as static 39. What is instanceOf keyword 40. What’s the load factor of HashMap 41. How to prevent a class from being sub classes 42. Final variable, final method and final class 43. Ways to create a string variable. 44. What is gc() – garbage collector 45. Subclass and innerclass 46. Infinite loop in java 47. How to make copy of an element 48. Checked and unchecked exceptions
1. Classes inside List interface, Set interface, Map Interface 2. Arraylist vs Linkedlist 3. Arraylist vs array 4. Arraylist vs vector or stack 5. Which class of List Interface to be used if user have more insertions and deletions 6. Which class of List Interface to be used if user have more retrieval 7. Set Interface: HashSet, TreeSet, SortedSet 8. Map – HashMap, HashTable, TreeMap, LinkedHashMap. 9. Stack and Queue 10. How to maintain insertion order in Set, List and Map 11. How to sort elements in ascending order in Set and Map
1. String reverse 2. String Palindrome 3. String Anagram 4. Find occurrences of characters in a string 5. Find the count of Capital and Small letters in a string 6. Remove duplicate characters from string 7. Swap to numbers without temporary variable 8. Reverse number 9. factorial 10. Fibonacci 11. Count number, alphabet and special characters
Chrome can be used to simulate a slow connection. Install Chrome if it is not already installed on your system. After that, open a new tab and press CTRL + SHIFT + I to bring up the developer tools window, or click on the hamburger icon, then More tools, then Developer tools.
Now click on Network section – a drop-down menu of pre-configured speeds appears, which you can use to simulate a slow connection.
To add your own custom values, click the Add button under Custom. To create a new profile, click the Add Custom Profile button.
This is an excellent tool that is integrated into Chrome that you can use to determine the load time of your website on slower connections. Please feel free to leave a comment if you have any questions. Enjoy!
Consider six of the most critical metrics to monitor and the value they provide.
Response Metrics
Average response time is the time between a client’s initial request and the final byte of a server’s response, which includes the delivery of HTML, images, CSS, JavaScript, and any other resources. It is the most precise standard method of determining the actual user experience.
Peak response time is a roundtrip time measurement for a request/response cycle, but it focuses on the longest cycle rather than an average. Rapid response times assist in identifying potentially problematic anomalies.
Error Rate quantifies the proportion of problematic requests to total requests. While it is not uncommon for some errors to occur during periods of high load, error rates should be kept to a minimum to optimize the user experience.
Volume Metrics
Concurrent users indicate the number of virtual users that are active at any given time. While requests per second are comparable (see below), the difference is that each concurrent user can generate a large number of requests.
Requests per second indicate the total number of requests sent to the server each second, which may include requests for HTML pages, CSS stylesheets, XML documents, JavaScript files, and images, among other resources.
Throughput indicates the amount of bandwidth consumed during the test in kilobytes per second. Low throughput may indicate the need for resource compression.
The purpose of the test pyramid is to provide a structure for designing and executing tests. It is also the cornerstone of testing at Google.
The test pyramid has four layers – unit tests, service tests, integration tests, end-to-end or acceptance tests. By dividing up the different types of tests into these levels, it becomes easier to decide what type of testing needs to be done when building and maintaining software.
At the bottom are unit tests. Unit tests are “white box” tests because they interact directly with product code. They typically perform operations on functions, methods, and classes. Unit tests should be concise, to the point, and focused on a single object/variation. They should be devoid of external dependencies and should instead rely on mocks/monkey-patching. These tests took less time to execute.
Integration tests are located in the center. Integration tests examine the point at which two distinct entities come together. They should be “black box” in nature, interacting with actual instances of the product being tested, rather than with code. Integration tests include service call tests (REST, SOAP, and others).
End-to-end tests are at top level. End-to-end tests trace a system’s path. They could be argued to be a multi-step integration test, and they should also be “black box.” Typically, they interact with the product in the same way that a real user would. Web UI tests are an example of integration tests, as they require the entire stack to run.
And manual testing is the cherry on top. Certain types of tests, such as exploratory or usability testing, cannot be automated, but we should always strive to minimize the number of manual tests.
You should be aware that as we progress up the pyramid, three factors begin to increase:
Costs associated with the development and maintenance of tests
Time frame for execution
Possibility of erroneous negatives
Key aspects relating to the software testing pyramid include the following:
Avoid conducting duplicate tests at multiple levels. There is no reason to conduct the same tests at various levels. For instance, if boundary values were validated in unit tests, they should not be repeated in the GUI – you will not obtain any new data.
One should strive to reduce the difficulty of tests whenever possible. For example, you can verify interest calculation on a negative sum at a “medium level” or even at the unit test level. Therefore, why should you do it at the UI level? Lower-level test automation is more efficient; it enables you to identify defects earlier and saves you time and money.
[A must read for all SDETs and Automation Engineers].
This time Zhimin Zhan provides a number of code examples for improving test maintainability.
When you can run automated tests often, and the application changes all the time, it is important that test scripts are: Quick and easy to maintain. Easy to read.
The leading reason for test automation to fail is that the team fails to maintain its automated scripts. In this article, Zhimin Zhan helps to understand some simple and practical tips at the test steps level that can help you make your automated functional tests more maintainable. These techniques are:
