Posted on

Job – Test Automation (~10years exp) (Delhi / NCR)

Job Opening: Immediate Joiner required:
Looking for a test automation expert/architect having ~10 years of experience on multiple automation frameworks.

Location: Delhi/NCR.
Candidate should be from Delhi/NCR only.

Remote working available.
Insterested candidates can drop email (with contact details/ resume) at leadershipintech@gmail.com

Posted on

Testing Cycle in Agile Process

There are typically 3 types of automated tests that are run in a CI/CD pipeline

1. Sprint Level Tests

  • These are new automated tests that have been written to test the functionality of the Sprint. They should be contained in a
    separate test suite that runs once a day to ensure the newly implemented functionalities are working as expected.
  • They are later merged into the regression tests suite.
    In the acceptance testing phase, usually the teams have a high level acceptance test plan that ensure the critical functionality of the systems are still working as expected afer the new
    features have been merged into the main code branch. Also, the smoke and regression tests are run again in parallel.

2. High Level Smoke Tests

  • These high level automated tests run on every code check in to ensure the critical functionality of the system is still working as expected. This could be a mixture of UI, API and Unit Tests. The point of this test is to get quick feedback about the system and it usually should finish running within 5 – 10 minutes.

3. Daily Regression Tests

  • These tests are run to ensure the new code added to the system did not break existing functionalities. They are more detailed than smoke tests as they cover end-to-end flows through the system. They are usually run at least on a daily basis and probably multiple times before a release.
  • Throughout this process, teams may continue to do manual scripted testing, exploratory testing and/or risk-based testing depending on their level of continuous testing maturity, application complexity and risk tolerance.

Source: Getting started with Automation (testIM E-Book). Click here to download.

Posted on

Automation Plan – Keep it simple

Nowadays, all companies started moving towards more and more automation. It is essential to have a plan in place; otherwise, automation may fail.

Here’s a guide (by Ray Claridge) to making automation a success.

  • Business buy in – Before starting to automate, make sure you’ve got buy in from line managers and developers. Remember, automating is time consuming and will cost your company money to get off the ground.
  • Plan – Don’t just start automating random functionality, have a plan and document explaining the approach and how long each test will take to develop. Remember, get sign off from all parties involved.
  • Identify high risk areas – Automating a fully fledged system is going to take a long time. So do some analysis to identify the high risk areas such as: most used, high volume, security or transactional sections and focus on them first.
  • Identify areas less likely to change – Maintaining automation test scripts is not a five minute job, so don’t start on areas that are likely to change. Equally, don’t assume that functionality less likely to change doesn’t need testing. Past experience has taught me never to assume.
  • Document your tests – You need to this so that it’s clear to others what exactly the tests cover. Also handy if your automated product is not available or your tests are falling over.
  • Keep track of your test runs – Keeping a chart of all you your tests and tracking automated vs manual effort, gives visibility that you’re saving your company money. Also handy when trying to get buy in.
  • Keep it simple – Remember, tests should be simple so they can be re-used again and again. This keeps down the costs when maintaining and allows others to pick them up in the future, especially if you’ve got a contractor in to write the tests.
  • And lastly one for all the Product Mangers, Development Managers and Business Units –
    Don’t assume that because you’ve got someone writing automated tests that all your code quality issues are over. Remember – automation is only as good as the tests written!
Posted on

Security Testing Taxonomy in 7 Steps

360logica provides a foolproof testing solution by adopting interesting ways and using a range of neat tools. Here is the 7 step process to test security of any application.

Step 1 – Discovery: The step involves analyzing system based on its scope, proposed and making a checklist of possible threats at each stage.

Step 2 – Vulnerability Scan: The system is run against prepared vulnerabilities to define risk level using automated tools.

Step 3 – Vulnerability Assessment: Considering existing and potential risks in the framework and tracking it to the environment under test mandate.

Step 4 – Security Assessment: Broadly assessing vulnerabilities and manually verifying it confirm exposure. It also involves assessing system response, file logs, codes, error messages, and broad coverage to check system defects.

Step 5 – Penetration Test: Using SQL injection and cross site scripting techniques to simulate malicious attack. This helps in identifying system’s ability to resist unauthorized access, data integrity,seamless operation, consistency, and problem solving abilities.

Step 6 – Security Audit: Specifying risk functions, control issues, compliance difficulties, areas reported during the security testing.

Step 7 – Security Review: Detailed analysis and information validation in such a way that ensures that the security standards are implemented and work in a seamless way through gap analysis, review of code and design documents, and evaluation of architecture diagrams.

Posted on

Tips to Baseline the Performance of the Old System

If your project is replacing an existing system, it is immensely valuable to establish a baseline for the new system based on the existing system. Start by analyzing the usage patterns of the existing site. What operations are most common? What paths are users following through the site? How many users are accessing the system at various times throughout the day? Wherever possible, this data should come from system logs rather than assumptions and guesswork. Then start designing your test:

  1. Create a mix of scenarios that account for 70-80% of the site usage
  2. Add any other scenarios that are known, or suspected, of having poor performance or affecting the overall performance of the system.
  3. Run a test that simulates various load levels corresponding to the load levels seen throughout a typical day
  4. Verify that the results agree with actual performance of the system during real-world use. If it does not, then adjust the test design and scenario mix to better match the real-world usage. Return to step 3 and try again

Having an accurate benchmark of the existing system yields several benefits:

  1. Performance measurements of the existing system can be compared objectively to the new system
  2. Research on the usage patterns of existing users will greatly improve the estimates of usage of the new system – improving the design and accuracy of tests on the new system

Reference: webperformance.com

Posted on

Selenium – Python – Get all child elements

There are various ways to find child elements:

  • find_elements_by_name
  • find_elements_by_xpath
  • find_elements_by_link_text
  • find_elements_by_partial_link_text
  • find_elements_by_tag_name
  • find_elements_by_class_name
  • find_elements_by_css_selector

For instance, consider this page source:

<html>
<body>
<form id=”loginForm”>
<input name=”username” type=”text” />
<input name=”password” type=”password” />
<input name=”continue” type=”submit” value=”Login” />
</form>
</body>
<html>

The form element can be located like this:

login_form = driver.find_element_by_id(‘loginForm’)

More references here