On testing

In this blog post I’d like to write about an experience I had at work.

As I mentioned in another post, we recently underwent an agile transformation at my workplace. We went from something resembling a waterfall model to an agile one. I don’t know if it’s industry standard, but this meant that the QA team and the dev team became one. This caused some problems, chief among them that the dev team did not have experience with the testing tools of the QA team. One of this tools is called ReadyAPI.

I was working on fixing a defect that was sized as a 3, and one of the requirements of the definision of done was to test that the defect was actually solved. I won’t get into the details of my task, but the problem was that because of the specifics of my task, it was impossible to perform automated testing, and I did not have the slightest idea on how I could test it appropriately.

I got in touch with a coworker that was part of the QA team and asked him for help. Long story short he was able to write a test specific to my case, and we had a chat about it. He told me that he was annoyed that the product owner had sized the defect as a 3. I mentioned to him that the coding involved on my part was akin to a 3 point story, but then he mentioned that if the coding was a 3, there was no more room to include the testing effort. He also walked me through the test he wrote and told me that it took quite a bit of effort. I certainly would not have been able to write this in any reasonable amout of time, and would have changed the defect into a 13 if I had to do it by myself.

Thanks to this little interaction I saw that the testing part of the stories we take is not taken into account as much as the development. I think this would not be an issue if reliability in our product wasn’t as important as new features, but I would argue that because of the nature of the product, it is more important than the new features. I don’t see why the leadership team would leave so little time to testing, but demand intricate graphs and test coverage before a release.

Verification and Validation of Software

Recently at my work we have been going through an agile transformation, and one of the goals was to lose the development team and QA team, and just have a team that did all of the development and QA. Thanks to this I have learned more about testing methodologies and tools. I have been taking a look at all of the tests that our software goes through and its incredible. This agile transformation made me realize that the old way of designing software has a lot of issues. I was talking with the person who used to be the head of QA and he was talking about how much redundancy and useless test cases we had because dev and QA were separated. Us in the dev team had written unit tests that the QA team had no knowledge of, so they wrote manual and automated test cases that valildated the same thing.

We were also talking about what tools we used to do the testing. We currently use a suite called ReadyAPI which is extremely expensive, and alot of the team dislikes it, both on the QA and the dev sides. There have been talks about taking the time to develop our own testing software using Python or JS but mangement does not want this, since they see it as not necesary. I hope we can one day get this project greenlit since I think working on a testing suite would be a very valuable experience.

Hands On: Task One

Everything that was required for task one I have already done previously. I am an avid Linux user, been using it as my main OS since 2017. I started as many do, using ubuntu but quickly lost interest since I saw it as a clunkier and worse version of windows. I could not see the true value of Linux in a distro like Ubuntu. I started to look for different distros and found some posts about Arch Linux elitism. I was intrigued so I started to research this distro. What I found was a nigh impossible distro to install, use and learn, I was game. Since I did not want to lose all of my files, I first tried installing arch in a VM. It was a total failure, and after a few days of trying I gave up. I started to look up guides besides the official install guide in the Arch Wiki (which was a mistake) and found a distro called Antergos. Antergos was a distro based on Arch with an actual GUI installer. I was frustrated enough at this point that I gave up trying to install Arch and decided to go with Antergos. I used Antergos for quite a while, and with it, learned Arch. The difference between Arch and Ubuntu was like night and day. Everything was under my direct control. I really felt like the administrator of the machine. I was even able to change the screen brightness from the terminal. I was in love. Then the NVidia drivers came and changed everything. I broke my installation about 3 times before I finally got my display drivers working. Doing all this configuration and installation and messing it up was very frustrating, but I kept throwing myself at it. The process of going from default drivers for the intel iGPU to a bumblebee installation with me deciding what program runs with intel and what program runs with Nvidia took me about a week at first. I could do it in probably 30 minutes today. This learning and breaking and getting better and faster is what I wanted from Linux, and thanks to Arch I got it.

Since I was already confident in my abilities to install and use arch, I decided that for this task I would install Gentoo. What a big mistake. If I thought the Arch installation process was clunky and convoluted, I never imagined a distro would include kernel compilation in the installation process. I quickly gave up on Gentoo since I did not want to slam my head against the keyboard for a week again, and I decided to go a little different, more professional route, RHEL. I had heard about RHEL, and how it was the main distro for the enterprise, and it was not free. Well, it is now free for development use and I decided to try it, so RHEL will be the distro I use for this class.

For the web server, I really dislike JavaScript, so I decided to use C# for the server. Seeing as how Microsoft is migrating to dotnet core with Linux support as one of its main selling points, I wanted to try it. I discovered a new web server from Microsoft called Blazor. I was really intrigued by it and decided to use it. Can learn more about it here: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

For the DB, I went with a standard MariaDB installation, since I don’t really care about the DB.

For the shell, I have been using bash for my entire time in Linux, so I decided I would try zsh.

What I knew about testing before taking this class.

I am currently working at Intel. I am developing a product that requires a lot of testing. I have to do some preliminary development testing before I can submit a code review and, after the code is submited for review, the QA team starts the real testing. I knew very little about testing before taking this job, but now I have heard terms like smoke testing, test driven development, testing pipelines, feature testing and unit test. I even needed to write a unit test before I even knew what that was. Keywords I never heard abot like assert and is intrigued me. Sadly, a lot of the testing is done by hand, without the help of specialized tools. I don’t know if this is because of the nature of the product I work on or if it is because of an standard. I would not like to work as a tester because of this. If it was focused on writing code to test other pieces of code I think I would like it, but since I have only done that once in my life, I am not sure. I hope I can learn about these terms and others on this course.