Showing posts with label Open Source. Show all posts
Showing posts with label Open Source. Show all posts

Saturday, January 14, 2023

How to read the user selection from a radio button group using Selenium?

SeleniumUtil library has been occupying my free time for the past couple of months. Since I’ve already written at length about what it is I won’t do that again here but if you really want to know you look here [1] [2].

When I implemented the abstraction wrapper for the HTML radio button group I ran into a problem. How would someone go about reading the user selection form a radio button group? Take a look at this HTML block,



According to the HTML5 spec, Radio Buttons belonging to the same group would have the same name attribute value. So toggling a given radio button using Selenium is not too difficult, but unlike Checkbox's the Radio Buttons I've seen in the wild (including this W3C example) doesn't append a checked attribute upon user selection. This complicates things.

I first tried retrieving the selection using the $0 variable that stores the user selection. But it turned out it was a browser specific variable that is not exposed to JavaScript. So how can we get a handle on this element and read its value? I did this,


But you can save all the pain because this snippet and bunch of other JavaScript goodies are available in SeleniumUtil 0.7.5.  

Saturday, January 7, 2023

SeleniumUtil 0.7.0 is now available with a few Java Script utility methods

Abstraction helps to promote code reuse and reduce development time among other benefits. When considering Selenium based test automation, you can abstract at many different points such as at dependency, infrastructure, technology, page, component or even at the element or locator level. SeleniumUtil is an open source library that aims to provide generic abstractions and other useful utilities so that you don’t need to worry about them in your Selenium based test automation projects.

Version 0.7.0 is now available in maven central and it provides a few technology level abstractions in the form of a few parameterized Java Script methods.


Usage











Tuesday, December 27, 2022

SeleniumUtil is an open source library to help make Selenium+Java automation easier and faster

I’ve been through two tech companies where they’ve had their own test automation frameworks. The last framework that I used was built to handle Web UI, API, and AS400. The framework was built by providing wrappers for common open-source automation components such as Selenium and Rest-assured. It was easy to set up an automation project using the framework, and only a few of us had any real concerns with it. It was the responsibility of the respective development teams to use the framework to automate their products based on a few loose programming guidelines. As the teams go through this exercise, they would build any custom components they might need as they see fit. Some of these components are universally used but were not available in the framework of the respective open-source components OOTB. Components such abstractions for working with HTML tables or custom ExpectedConditions. 


When I had some time on my hand I looked around to see if there are any open-source libraries that I can use out there to cut the automation project setup time and I found that there isn’t a lightweight library that can be easily integrated to existing projects. So I started one of my own.


At the moment the library provides a few wrappers for HTML elements such as RadioButton, MultiSelect, and Table. The plan is to implement other useful features such, Wrappers for common JavaScript script snippets, custom ExpectedConditions, and sliders. The library is at version 0.6.5 and it's available on Maven Central[1]. If you’re interested in contributing to the project please follow the instructions here [2][3].


[1] - https://search.maven.org/artifact/io.github.handakumbura/Seleniumutil/0.6.5/jar

[2] - https://docs.google.com/document/d/1Diudxs53eL8QkfYwHpExkusEtpJxF0mDHVrr6XymXYE/edit?usp=sharing

[3] - https://github.com/handakumbura/Seleniumuntil


 

 




Wednesday, March 8, 2017

Barriers to FOSS adoption and the role of the provider

A couple of weeks ago I posted a writeup on why organizations can’t afford to ignore open source anymore, the write-up was based mainly on my own experiences and knowledge I came to possess as a result of working for a product company that is built around an open source business model. Towards the end of the writing process, I felt there is a lot more that can be said about FOSS, especially concerning adoption and the role providers play in assuaging adoption pains.
....
As discussed in the previous post[1] the drive for Open Source adoption in organizations can come from the industry or broader technological community manifested as ground level traction by the in-house engineers. This driver was looked at by Miralles, Sieber and Valor. Two types of technology adoption views were considered in their research. These two views being,  technical push; a deterministic view, where the decision to adopt is mediated by an accumulation of factors such as technical attributes, the cost of ownership and ability to transition into open source. Organizational pull; factors intrinsic to the organization such as organizational capabilities, vendor-organization match and psychological factors of the decision maker. The research found FOSS to have a greater technical push compared to its proprietary counterpart, in all areas except lock in(ease of transition) but in most cases, it was beaten off due to low organizational pull when it came down to the decision to adopt(2006). This study was done a decade ago, it would be interesting to see if the strength of correlation between the technical push and the decision to adopt has changed over time, looking at the current technological landscape one can assume it has gotten stronger.
The technological superiority of FOSS has been discussed in countless research papers and countless more web articles. Furthermore, even if the strength of correlation between technical push and decision to adopt has gotten stronger from the time the research in question was done, common sense dictates the factors looked at in organizational pull should have a stronger relationship with the decision. The decision to adopt therefore should be made by assessing the potentialities through both views. This is where I feel FOSS is lacking, its ability to convince that it is the right choice regardless of the view one adopts when assessing it. The purpose of this post is to point the reader on how the shortcomings of FOSS can be circumvented through the services of a provider.
Before we can address how a provider can address the drawbacks of Open Source and other barriers to its adoption, we should have a better idea of these drawbacks and barriers. Hauge et al found Lack of support and expertise, difficulties in selecting the right OSS products and ambiguities in liability as major barriers to adoption.(2010) Morgan and Finnegan found compatibility issues, lack of expertise, poor documentation and lack of roadmaps and other documents pointing to strategic direction of Open Source projects as technical drawbacks. Moreover, the researchers found a lack of ownership, a lack of support and difficulties of finding right staff/competencies as business drawbacks.(2007) As mentioned in an earlier paragraph, Miralles, Sieber and Valor highlighted the following three organizational barriers. Organizational capabilities; concerns regarding in-house expertise on the technology and the logistical/operational constraints of building up expertise. Network externalities; the indecisiveness that one might feel due to the phase of evolution in open source. Psychology of decision makers; factors such as the impression adoption decisions of peers have on your own and other individual differences.
Providers such as Red Hat and WSO2 build value on top of FOSS by addressing these shortcomings and drawbacks, providing products that are better tailored to enterprise needs. Providers that have adopted similar open source business models provide paid auxiliary services on implementation, support, maintenance and consultation. These auxiliary services may be availed to a great extent by any organizations considering Open Source adoption but discouraged due to its perceived drawbacks. 

Lack of expertise,

Product expertise will be needed by organizations at various stages of their technology adoption and transition journeys. The specific needs pertaining to expertise at one point of the adoption journey can differ from another, therefore organizations evaluating providers should look into the potential provider's ability to cater to these varied needs.     
Providers should be able to address concerns about an organization's in-house expertise with focused on site consultancy services, documentation, and other training resources. Furthermore, The providers should possess the competency to address concerns that may come about at different points of adoption that are specific to the organization's existing technological infrastructure. Lastly, the providers should have dedicated channels(such as support channels) to disseminate the expertise.
Organizations, in turn, can put programs in place to cultivate in-house expertise of the products, leveraging the documentation and other learning resources provided as value additions by the providers.      

Compatibility issues and concerns of lock-in,

Organizations may get discouraged by possible compatibility issues between FOSS and their existing technological backbone. Though this is a concern that is common to both open source and proprietary software in adoption and transition, in the case of open source, the access to the information needed to decide on compatibility may be hard to come by. Therefore, organizations should be able to get the assistance of the providers when they are evaluating the possibility of adoption. Dedicated channels should exist for organizations to access the information from the providers. Organizations should opt for providers that assist in this evaluation process, some providers may even provide specialized services catered for this very requirement.   
Considering the comparatively low cost of ownership, It may be worthwhile for some organizations to purchase lower tier support/assistance services purely for compatibility evaluation. Organizations may avail these services to run pilot projects with the products, the benefit of such pilot projects are twofold as they will build up in-house competency on the technology.
Some providers may even offer their products as SaaS offerings, organizations evaluating OSS may use these services to get a better idea of functional compatibility of the products. Though it should be noted that at times the functionality of such SaaS offerings may be cropped to improve suitability.    

Concerns with liability and longevity,

As FOSS is maintained by a community unbound to organizational goals and needs, many organizations find liability as a barrier to adoption. Therefore, organizations should expect the providers to address these liability concerns with contractual obligations such as SLA's. Organizations should look to dedicated L1, L2 support from the providers.
As with proprietary software adoption, it makes sense to place the responsibility for the adopted technology between internal resources and external resources of the provider. Some providers may be able to provide dedicated agents that can integrate into the in-house teams to address concerns on behalf of the organization with the provider.
It makes sense to go with a provider that has been in the domain for a considerable length of time and proven domain expertise. Furthermore, organizations may look to the provider’s product strategy through product vision documents, roadmaps and such when assessing longevity.   

In summation, it is my personal opinion that many of the barriers to adoption that prevent the organizational pull favoring FOSS can be addressed with the assistance of providers, with a thought out adoption plan on the adopter's side and the backing of the right provider. That, those organizations that embrace Open Source as discussed in this post would have an advantage over those who have opted for proprietary solutions.

List of References

Hauge, Ø, Cruzes, D. S., Conradi, R., Velle, K. S. and Skarpenes, T. A. (2010) 'Risks and Risk
Mitigation in Open Source Software Adoption: Bridging the Gap between Literature and
Practice' IFIP Advances in Information and Communication Technology 319(1), 105-118

Miralles, F., Sieber, S. and Valor, J (2006) 'An Exploratory Framework for Assessing Open
Source Software Adoption'. Systèmes d'Information et Management 11 (1), 85-111

Morgan L., Finnegan P. (2007) 'Benefits and Drawbacks of Open Source Software: An
Exploratory Study of Secondary Software Firms' The International Federation for
Information Processing 234(1), 308-311      


What's in my Bag? EDC of a Tester