Meet our open source champions: Monica Tamboli, Quality Assurance Warrior

My first job as a Unix System Administrator involved managing production systems. Although I learned new things, I did not enjoy it much. So when I was looking for my next job, I had 2 offers: one from the development team and the other from test team of the same product. I decided to start with the test team to get a good high-level view of the product with the intention of moving to the development team after some time. However, I have been enjoying my job so much that I have stayed with testing/QA. I know some people think of QA being the first job anyone with 6 month of training could do. But that is not the case here. This level of testing is very involved. 

We have a diverse range of customers each with their own application and environment/infrastructure. But really, it’s the system test team that is the first customer for our products - helping to ensure everything works effectively before our 'real' customers get the technology or update. In testing, we have to simulate our customers environments by developing business applications and running them on different platforms for long periods of time and under stress. Debugging problems in complex environments can be very challenging to determine real defects versus user issues or problems in other tools. This job requires a mix of various technical skills, including cloud administration, system administration, database administration, automation development, and programming/scripting.

I joined the Liberty team during earlier versions of the traditional WebSphere Application Server. My earlier testing involved setting up different operating systems (like Solaris, AIX, HP-UX and Windows) and installing WebSphere, Database Systems (DB2, Oracle, Sybase, MS SQL etc) and LDAP servers. Then I assumed the roles of different focal points, including dynamic caching, transaction processing, and security. Security has been my favorite because I got to work on technologies like SSL/TLS, OAuth and OIDC, which you can see in action during the daily life as a consumer of e-businesses. Check out my blog to find out more.

Later, it was really interesting to work on WebSphere Liberty and Open Liberty. A few years ago, we started to focus on testing our WebSphere products in containers on Kubernetes. As a part of this, I also got to work on additional open source projects like Kabanero, Appsody, and Tekton. I also own a Java EE test application focused on testing enterprise security that I update for new features, including migrating to Jakarta EE. In addition to running test applications using Open Liberty on VMs, my team also uses container images to deploy them to Kubernetes (OpenShift) clusters using the Open Liberty Operator.

This question took me down the memory lane of the fun days when we used to work with physical servers in a typical noisy lab. You would put actual compact disk (CD) in those systems to install OS and other products. Slowly, CDs got replaced with network installs and physical machines with Virtual Machines (VMs) and now containers. As much as I love new technology, sometimes it feels like we had better control over those systems. The technology scope was not as wide and it was not changing as quickly.  

Cloud-native offers many advantages for our workloads like agility, scalability, and portability but it brings many challenges as well. The technology involved is more complicated and there is a steeper learning curve to fully grasp and reap the true benefits. With open source, there is a wider variety of product choices and technology changes very rapidly. By the time you get comfortable with a product, there might already be a new product you need to consider. It is hard to predict what additional products (like, for observability) our customers will use with our products, making it harder for us to mirror the customer environments. In modern cloud native environments, many container images that include products in your environment could be available and you want to make to use the correct certified images. It also becomes important to take appropriate security considerations like scan (vulnerability detection) and sign (to avoid tampering) for the images. Lots of our workloads involve transactions and require stateful deployment. Finding the correct persistent storage in different cloud environments can become a bit tricky too. 

DevOps encourages automation at every step to achieve speed and agility and is an integral part of our testing strategy. Jenkins jobs are used to automate various steps of the testing lifecycle, saving time , avoiding user errors, and archiving logs and metrics for later reference. Travis is used for building and verifying SVT applications updates. We also used Tekton Pipelines to automate various tasks like building the application, publishing the image to container registry, scanning the image, and deploying to the cluster. DevOps also encourages "Shift Left Testing": moving testing tasks as early as possible in software development process. This involves a cultural shift for an organization and you must also find the right balance of automated versus manual tests. To me, the biggest challenge seems like too many choices, with each of having different strengths.

We use many open source technologies like Kubernetes, Podman, Docker, Git, Maven, Jenkins, Prometheus and Ansible. These open source tools have helped us tremendously to become more efficient and effective by automating multiple tasks.

I have had many opportunities to mentor interns who are often skeptical about System Test when they join our team. But by the end of their internship they would enjoy the work and many of them chose to return and work for us within the testing team after graduation.

I’d give this advice: It is really important to spend time to find out what their interests are (for example: AI, Cloud, Coding, DevOps etc) and find them something which keeps their interest and creativity alive while contributing towards the team goals. Also, I think it’s important to take time to really explain and emphasize to them the broad scope of testing for your product. For example, the flexibility that comes with a role in testing means they can work on all aspects of application development and operations. Automation provides a fantastic, solid foundation as they progress in their career and enables them to develop valuable skills useful in many other roles.

My words of wisdom: In the technology field these days, there is so much to do. There should not be a dull moment at work. If you are not feeling motivated, talk to your team lead and find something which excites you. 

I would start with using the open source technology first to get comfortable with it. Open bug issues in the open source repositories and start working with the community. It is important to be very specific and provide all relevant details when opening bugs for any open source projects because people may not have the same context as teams within the same organization. You need to be aware of any information (screen shots etc) you are sharing in these public issues so that it does not become any security threat. You may want to start with a very small update to understand the process. I encouraged our team to start with some document updates. All the professional and soft skills like being respectful, clear communication, and constructive feedback are important while working in open source. 

If you are involved in development of open source projects, creating good unit and functional tests is important. We use the same standards for testing of open source projects (open liberty) as other commercial products. 

As enterprises have started to depend on open-source projects heavily, it is really important to focus on quality.  I would like to wrap up this post with this thought of making sure that we keep focus on serviceability (good error handling and clear log messages) and usability (easy to use), reliability and security aspects of open source projects.