Improvement I have done

 To avoid repeating the same steps as a lot in each test script

  • Create navigation page
  • Create methods for navigation
  • It reduces the number of lines in the script
  • For login there are 4 lines with this approach there is only one line with params
  • For visit admission there are 10 lines with this approach there is only one line with the params

Separate data creation and pre-condition steps from test scripts

  • Use dependsOnGroup, dependsOnMethod group annotations and create separate scripts for data creations
  • If the data creation fails the test script will be skipped

When adding a pull request add a pre-defined template format to give the correct idea about the fix

  • Add "Before Fix" 
  • Add "After Fix"
  • Add "Additional method" field

How to identify code-level issues in page object classes?

  • Link Sonar Qube analysis
  • Configure bit bucket that cannot merge pull requests with critical or blocker sonar issues

Nightly installation fails if there are sessions or the database is opened during automation execution

  • Add a task in the Windows remote desktop machine to restart machines at the scheduled time

Every day has to trigger regression test suite execution manually in Team CI env

  • in the Jenkins file of the pipeline and add the property TRIGGER_SCHEDULE = 13 15 14 * * 1- 5 corn job

Add default review group and default no of approvals needs for merge

  • Since it is our page object and test repository we need to maintain quality from our side so that when other team members add a pull request it needs to be approved from our side definitely

Add a list of checklists that need to be considered before approving a pull request

  • Follow the company format and configure it with IntelliJ
  • Add the correct import order
  • Add Javadoc for test classes and each method of page objects
  • Clear description of parameters with examples in page objects
  • Follow the correct format (camel case) for method names and variable names
  • The method name should be similar to the test case name

Make test scripts independent since they have to run on different environments

  • We are executing test scripts on different environments like team ci, pre-production, line, int environments
  • So data can be different in each environment
  • So we always create new patients 
  • Create users
  • Create specific configurations like global settings/server settings
  • Create templates

Create common page objects for Java dialogues

  • Create a common page object
  • Use the parameters to pass the dialogue title
  • Create common methods for button clicks like OK, CANCEL, YES, NO

How to improve the readability of classes and test cases, methods and variables

  • Use Java doc for each class
  • Use Java doc for each method
  • Use proper explanation for parameters with example
  • Follow the same pattern for creating methods and variables like camel case

The same variable is used multiple times in multiple classes

  • Create separate Java classes for variables
  • usernames
  • patient names
  • right-click options
  • common button names
  • Making reusable things publically accessible

Page object class have many lines. It is hard to maintain

  • Java guideline for a class in 300 line - fine
  • 300 -500 reasonable
  • 500 - 1000 - ok, but need to refactoring
  • > 1000 - definitely refactor
  • Break the content into reusable components

Create separate classes for reusable variables

  • Constant class pattern
  • It improves readability and maintainability
  • Reusability
  • centralized management
  • improve consistency
  • Use constant variables
  • Use the final non-access modifier so the value cannot be changed once assigned

To do the performance test I need a large volume of data. How to create a data set effectively?

  • If I use the automation scripts it takes much time to create data
  • We can use POST API requests to create data effectively
  • Use collection runner and CSV file to generate large amounts of data 






Comments

Post a Comment

Popular posts from this blog

False Positive

 A false positive in software testing is when a test incorrectly indicates the presence of a defect or issue in the software when there actually is none. This means the test result shows a problem that doesn't exist, leading to unnecessary investigation and troubleshooting. Example: Imagine you have a test that checks if a login feature works correctly. The test is supposed to verify that users can log in with valid credentials. If the test fails and reports that the login feature is broken, but in reality, the login feature works perfectly fine, this is a false positive. Causes: Test Script Errors: The test script itself might have an error, causing it to fail even when the application works correctly. Environment Issues: Issues in the test environment, such as incorrect configurations or network problems, might lead to false positives. Timing Issues: Tests might run too quickly before the system has fully updated or responded, leading to incorrect failure reports. Impact: Wast...
Read more

100% Percent Test Coverage

  Testing Methodologies: Shift Left Testing: Focus on testing early in the development lifecycle, identifying and fixing bugs during development rather than later stages. This includes unit testing, code reviews, and static analysis tools. Agile Testing: Integrate testing closely with development in an iterative approach. As features are developed, tests are written and executed concurrently. Exploratory Testing: Encourage testers to explore the application freely, looking for unexpected behavior and usability issues. Model-Based Testing: Create models that represent the expected behavior of the system and use them to automate test case generation. Testing Techniques: Equivalence Partitioning: Divide the input space into valid and invalid partitions based on expected behavior. Create test cases for each partition. Boundary Value Analysis: Test cases around the edges or boundaries of valid input ranges (e.g., minimum, maximum values). Error Guessing: Based on your knowle...
Read more