Website Technology Profiler

{
  "PageContent": "<h3>Software Testing Articles | “The problem is not that testing is the bottleneck. The problem is that you don’t know what’s in the bottle. That’s a problem that testing addresses.“— Michael Bolton</h3>In present world, smartphones and tablets are the popular medium to access the internet for any requirement, forcing organisations to develop mobile applications of their service offerings.The hardware and software are developed independently but function together based on product expectations. For example, a web application is developed in PHP/.NET/Java and is expected to work properly on all available mobile devices and different web browsers.Here the question arises: how will an application perform functions as expected on client’s devices? While fulfilling such expectations, we need to keep in mind that there are numerous combinations of web browsers and its versions, operating systems and plurality of mobile device models. The process to validate application behaviour is as expected across the mobile devices and browsers based on application requirements is known as mobile device compatibility testing.On mobile devices, users can have native/web or hybrid applications and each application type will have certain difference in display/functional behaviour/look n feel etc. While testing each type of application, team needs to consider few points.Web applications are written in HTML5, navigate to a special URL through web browsers. Testing team need to consider following points while testing web applications:1. Content: Entire website/product cannot fit on small screen mobile devices2. Navigation: In-spite of showing full size website/application, different navigation methods are required3. Size: Font and objects needs to be resized for small screen devices4. Functions and Feature: On different devices and operating systems, application behaviour is always unpredictableNative applications are installed on the device and are accessed through icons on the device home screen. They are installed through an application store like Google Play or Apple’s App Store. These applications use device’s notification system and can also work offline, hence testers need to consider following points in testing:1. Application installation and upgrade process through application store and related issues2. Fewer applications dependent on the operating system than with responsive Web design applications3. Many versions are required for each operating systemHybrid applications are partially native and partially web applications. They can be installed through application store and access through web browsers as well with special URLs hence testing team need to consider all the above discussed points while testing such applications and be more focused. Application content, UI, functionalities should be same everywhere.While doing mobile device comfortability testing, we need to cover maximum devices and ensure results are close to 100 percent of users’ device base. We also need to identify the perceived bugs to the corresponding layer – operating system, web browser, device features or skins? Also need to focus on the functionalities which are probable to fail in the case of a technology upgrade or a new device launch.Now we will talk about the five step approach to make mobile device compatibility testing more agile and scalable.1. Develop Device Compatibility Repository: Analyse the major available mobile devices for following information like hardware feature, platform details, technology features supported (audio/video and image format etc.), hardware features included, and network and other technology features supported by the device. This device structure list will be useful for device compatibility testing.2. Shortlist the device list based in compliance: Short-list devices for specific project based on region or country individuality. This can help to cover up lost popular devices in the region.3. Prepare device list based on its compatibility: For better visibility, prepare list of compatible v/s partially compatible devices to confirm features which may not work and cause issues in partially compatible devices. In some cases, the potential device is rare or highly expensive, hence team uses emulators for development and testing. iOS and android emulators are mainly designed for native applications, however their default web browsers accurately act how the application will behave on a real device.4. Execute tests on most compatible devices: To ensure 100% application functionality accuracy, focus on minimum one device from each manufacture if testing is not possible on all the devices given in the list. Execute tests on partially compatible devices as well. Perform testing on the latest and most widely used devices as well and ensure initial focus on the functions that might be influenced by unsupported features.To summarize, Native, hybrid, or web application are ultimately to render the needs of the mobile users. Hence the majority of time utilized on mobile device compatibility testing is focused on the executing functions as the customer would perform on different devices, operating systems and web browser combinations and confirming that the screens and behaviour is as expected. Although there is no unique best method as each have strengths and weaknesses. The choice of one device/application versus the other depends on each company’s unique requirements.",
  "Url": "https://priyastrivedi.wordpress.com",
  "IpAddress": "192.0.78.12",
  "ReverseDns": null,
  "Asn": null,
  "Http2": false,
  "Http3": false,
  "ResponseTimeMs": 602,
  "StatusCode": 200,
  "ServerHeaders": [
    "nginx"
  ],
  "Ssl": {
    "Issuer": "CN=E8, O=Let's Encrypt, C=US",
    "Subject": "CN=wordpress.com",
    "NotBefore": "2026-01-07T11:45:24-08:00",
    "NotAfter": "2026-04-07T12:45:23-07:00",
    "SubjectAltNames": [
      "DNS Name=*.wordpress.com",
      "DNS Name=wordpress.com"
    ],
    "Hsts": true,
    "Ciphers": [],
    "Protocol": "Tls13",
    "DaysUntilExpiry": 66
  },
  "Cdns": [],
  "HostingHints": [],
  "Cms": [
    "WordPress",
    "WordPress (robots.txt)"
  ],
  "Frameworks": [],
  "JsLibraries": [],
  "Analytics": [
    "Google Analytics UA",
    "Google Analytics GA4"
  ],
  "AdsAndMarketing": [],
  "PaymentGateways": [],
  "EcommerceHints": [
    "Magento",
    "PrestaShop"
  ],
  "SocialSignals": [],
  "MediaProviders": [],
  "SeoTags": [
    "content-type: text/html; charset=UTF-8"
  ],
  "HtmlLanguage": "en",
  "HasRobots": true,
  "HasSitemap": true,
  "SecurityHeaders": [
    "HSTS"
  ],
  "CookiesObserved": [],
  "XhrApiHints": [],
  "SitemapCounts": {
    "total_urls": 27
  },
  "ChatWidgets": [],
  "ABTesting": [],
  "PrivacyConsent": [],
  "EmailMarketing": [],
  "WebFonts": [],
  "DynamicJs": [
    "Web Server: nginx",
    "ES6+ JavaScript Features",
    "Angular (Data Attributes)",
    "Bootstrap (CSS Classes)"
  ],
  "ResourceHosts": [
    "priyastrivedi.wordpress.com",
    "0.gravatar.com",
    "stats.wp.com",
    "gmpg.org",
    "s2.wp.com",
    "s1.wp.com",
    "s0.wp.com",
    "af.pubmine.com",
    "wp.me",
    "pixel.wp.com"
  ],
  "CssFrameworks": [],
  "BuildTools": [],
  "ServerTech": [
    "Generator: WordPress.com",
    "PHP (inferred from WordPress)"
  ],
  "DatabaseHints": [],
  "PageTitle": "Software Testing Articles | “The problem is not that testing is the bottleneck. The problem is that you don’t know what’s in the bottle. That’s a problem that testing addresses.“— Michael Bolton",
  "MetaDescription": "“The problem is not that testing is the bottleneck. The problem is that you don’t know what’s in the bottle. That’s a problem that testing addresses.“— Michael Bolton",
  "ImageCount": 7,
  "ScriptCount": 31,
  "LinkCount": 23,
  "Errors": [
    "Reverse DNS failed: No such host is known."
  ],
  "UiFrameworks": [
    "D3.js",
    "Swiper",
    "Vuetify (Class Names)",
    "Angular Material (Class Names)",
    "Bootstrap (Class Names)",
    "Ionic (Class Names)"
  ]
}