Podcast: https://joecolantonio.com/testtalks/222-ai-powered-dashboard/

For my blog for this week, I listened to a podcast with Joe Colantonio. His guest for that particular episode was Dzmity Humianiuk who is a product manager for an application called ReportPortal.io. ReportPortal.io is an Artificial Intelligence powered test automation on dashboarding. It is open source and works with almost every test automation tool out there. Dzmity worked 11 years in IT and switched to software development. He had thought of his idea five years ago when he was trying to find a way to collect a large amount of data. This was the first idea that started with implementing something that is robust and would be the standard for all test automation results within his company. ReportPortal.io is really cool because it is like magic, where you are able to get everything with one click. The key benefit being the real time reporting. For example, if you need to execute a lot of cases when you have a pretty big scope of test automation, there is no need to wait for the full execution of all test cases. There is not waiting up to ten hours, and instead you will see results within the portal in just a few seconds after the execution has just started. Usually, any problem or test cases that start to fail, you will be able to the next day. With ReportPortal you are able to notice it within a few seconds, make it click, fix it and execute it again. ReportPortal uses machine learning and implements some of its algorithms that utilize all the historical data that is given in the database. Then it analyzes the most recent execution. Dzmity also talks about how making the tool customizable was crucial and from the beginning they were assuming it would be open sourced. It i built on microservices architecture which means that it is perfect extension point for the report portal. This allows user to be able to implement their own tiny micro service which can use their API which in hand can use any other microservices that are inside. It also allows everyone to see the code and contribute to it. Lastly he talked about how they are even able to integrate it with Silk testing which is very old school testing and make it compatible with the modern software. Again, a very interesting podcast! I have never heard of ReportPortal.io an it was really cool what the product manager had to say about it!

Podcast: https://joecolantonio.com/testtalks/194-reality-testing-artificial-world-angie-jones/

The podcast that I listened to this week was very enjoyable by the one and only Joe Colantonio from Test Talks. He talks to Angie Jones about Artificial Intelligence and Testing. Angie is a senior software engineer test at twitter who has developed automation strategies and frameworks for countless software products. What Angie and Joe talk about is the reality of testing in the artificial world. Angie has noticed that she has seen a lot of tools helping with artificial intelligence and how artificial intelligence will save the day. What is missing from the conversation, Angie highlights, is how to test these forms of Artificial intelligence that is present today, like machine learning which many applications are using it. You do not realize how many things use machine learning like Netflix, and Twitter. Both of these has features that use machine learning. Many see it has something that is in the future but that is wrong. They are present and will be even more prevalent in the future. There needs to be more focus on testing this stuff. People also do not see this as a testable feature, and do not worry about testing it. The thing though is that you think that it my be learning one thing, while it may be tricking you and learning something completely different. Some of the lessons she learned from testing AI is that it challenges a lot of guidelines, especially around automation. There is not exactness or preciseness. There are a range of values that could be valid and Angie did have to get creative and dig deeper down to figure out what was correct. She also learned that if the tester was not a programmer, which is a huge debate whether a tester should be a programmer, she had to test a lot of algorithms and know how to code to test them. Lastly the one piece of advice that Angie would give to the audience is that dont let anyone make you believe that AI and machine learning is this all-knowing black box, and a testers we should know this. Read more into what machine learning is, the different applications used in machine learning, and to take the time to think about how you would test something. The podcast for this week was very interesting. Again, this was a podcast that talked about issues that are going on now. AI and machine learning is something that is becoming very popular and will not do anything but get even more popular. With it growing and growing, it is as Angie said, very important now, and even more vital in the future to figure out how to test it and the correct way.

Podcast: https://joecolantonio.com/testtalks/213-automation-testing-richard-bradshaw-mark-winteringham

As always I listened to another Test Talks podcast by Joe Colantonio. In this podcast he has Richard Bradshaw and Mark Winteringham as hosts as they talk about their new website, automationtesting.com. Automation In Testing(AIT) is pretty much a new namespace website created by these two. A place where you can talk about the design factors and a lot of the theory behind automation. From there, there is also creating; how to create good maintainable automation that isn’t flaky. They also mention that starting with an analysis of problems when in the process of implementing something is important. Once you figure out how to use a model to sort of figure out and identify the different types of problems, the actual tooling side becomes a lot easier. So it is also a good idea to have a good knowledge about tools. It is just important to know the type of problem can make the job all the more easier for you in the long run. Also, when it comes to implementation things start to become more fluid. Since you are not fighting against a tool trying to get it to work in a way that may not be an advantage for you, they flow a bit better. One of the last things that he mentions is having the community talk to the tool vendors more when it comes to ministry testing going forward. He mentions that its usually the tools vendors saying they need their tools, so it’s very one way. There could be some benefits from engaging with the community to find out the problem they are facing while also finding new opportunities there. That includes new products they could build. If the conversations do not even get started, they will never know what they are missing out on. Having these conversations will benefit the whole community and industry. This weeks podcast was very interesting. Usually I find articles about things that help me more with the terminology of what I am learning in class, but it is so cool to listen to podcasts each week that have to do with real life issue and ideas that companies and people are working on at the moment.

Podcast:https://joecolantonio.com/testtalks/219-the-state-of-software-quality-in-2018-with-shailesh-rao/

The podcast that I listened to this week is of course again by Test Talks which is hosted by Joe Colantonio. This podcast is a more recent one that talks about software quality and the state of it in 2018. As software is getting more and more powerful and popular, it is important to try to make it the best quality software it can be so it does not ruin your project or even worse, a business. Joe talks to Shailesh Rao, who is the the current COO of BrowserStick. The first thing Rao notes as importance is comparing your software toa stress free life. It is the ultimate goal, but it is always worked on. Having a bug-free software takes time and you might always be working on it, but it’s the always working on it that is of key. Trying to make it work to your utmost ability is a great goal to have in mind and will help you in the long run. He also stresses the importance of quality itself, not just in coding, but the quality behind hiring someone, and the culture you create. He then goes on to talk about automated testing becoming more and more crucial and seeing it as a means to an end. Only about 20-30 percent of companies are using it, and while many do not use it, there is no lack of intent there and the numbers are growing. The last thing he mentions is a piece of advice which is that discipline is key. Everyone is going through the same struggle and its important to know that. Apply that discipline and don’t give it.

What I really liked about this podcast was that it talked about something that is going on now and what is important right now. It’s really cool to know how popular software quality and automated testing is becoming. It helps me know what companies will want you to know and what you should be good at. After I graduate, of course it will be important for me to know the basis of coding, and to know the most popular languages like java and c, but technology is always changing and I need to be right there soaking everything in, so I can be at my utmost prepared self.

Podcast:https://joecolantonio.com/testtalks/198-testing-and-planning-for-the-unknown-with-kinga-witko/

The podcast that I had listened to for this week was again by Joe Colantonio with guest host Kinga Witko. The two first begin with talking about what Kinga does for a living and as a job. She speaks about the difficulties of her job and how demanding it can be. She also discusses how laws that differ from the U.S to Europe can affect how your testing goes in a job like hers. Afterwards, Joe talks about one of her youtube videos and how she states that you need time for big fixes. She specifically talks about the hardest thing people do not understand is the comprehension behind their project or software being a whole. Many tend to divide their project in two sections, so when they need to do deal with bugs or fixes, they see as something completely separate from their core features. People think that bugs are different from functionality, which is wrong, Kinga expresses. She then goes on to give tips on how to be aware of this. To know that testing is part of the process and bugs should not be part of a separate bit. One tip that she recommends is that a tester should always keep in mind that they should 25%/30% of each task/ development task for something which is unexpected. This doesn’t mean that it has to be a bug, it may be an environmental issue, or something you can not predict from the beginning. She also mentions that people should state problems early on, to avoid risks of even more problems. Lastly, her best approach for testers is to do exploratory testing. Get along with exploratory sessions and try to think outside of the box.

There were a lot of reasons why I really liked this article. The biggest being was that she was a women talking about testing, and computer science as a whole. All of the podcasts that I have listened to thus far have all been by men. I do not mind that because I knew from this beginning that this was a male dominated field, but I am always looking for female coders or testers. I also really liked that she was from Poland because I have not heard/ listened to any European CS people. What she had to say was even more interesting. Even I myself, who has not worked on hardcore projects for a job so far, feel like I already separate my projects into certain areas. I like that she was big on trying to keep it as a whole. A lot of her tips and tricks were very interesting to hear.

Podcast: https://joecolantonio.com/testtalks/196-rapid-software-testing-michael-bolton/

The podcast that I listened to for this week is from a podcast called Test Talks by Joe Colantonio. In this podcast he has Michael Bolton as a guest, who is a software tester and testing teacher. He helps solve testing problems for people who did not realize they could solve them. He is also the co-author of Rapid Software Testing along with James Bach. Rapid Software Testing (RST) is “a methodology and mindset for testing software expertly and credibly in uncertain conditions and under extreme time pressure”. The first thing the two discuss is the three main points of RST. That is skill set, mind set, and its class. Some of the main things that they focus on when it comes to RST is finding trouble with it, they like to explores the risks of it, what bugs will threaten the value of testing, or the project or the business. Michael also emphasizes the importance of testers being able to express clearly what they are here for, quickly and to the point. Another topic that they then speak about is the nonexistence of manual testing, which he talks more in depth about in his own article on Developingsense. He talks about how manual testing does not exist. Testers need and use tools and they engage with the product.

There were a lot of things that I really liked about this podcast. The first thing is that I never knew who Michael Bolton was, and that he was the co-author of something like RST with James Bach. I also really appreciate what he had to say about manual and automated testing and how they exist and why it had ever existed in the past. I also really liked how he mentioned that when people think too much about what they should be including, the bureaucracy, they forget about creating the actual product and what they want to do. They forget about looking into the problems. People do not spend their time wisely when is come to various aspects of the product. People are not taking an appropriate level of time to review and check their own work. More excessive structure and documentation which displaces the time we actually have to do our work is the biggest problem. A lot of what he had to say was very true and I think that the time does not get taken into account with coding and testing for projects. Overall I really liked the podcast and felt it was different from the usual informational podcasts that are geared more towards how to test and the different kinds of testing and instead on what will make you a better tester.

URL: https://blog.codecentric.de/en/2016/01/writing-better-tests-junit/

For my first blogpost, I decided to start off with a blog from codecentric. The blogpost that I decided to read and write about was by Tobias Goeschel that focuses on the importance of testing, and how implementing well written testing through JUnit. One of the most important things about testing is that is allows someone to be able to add new features to their code without breaking what is already in place. This means helping to make changes to the architecture without damaging the behavior which in hand helps them find bugs earlier on. Some of the main things that well written tests help with are how to access API, what kind of data goes in & out and what happens to certain exceptions that occur. A form of living documentation is the value of tests and it helps when revisiting old code, seeing someone elses and looking for bugs. JUnit is known as the most popular form of testing, which is a Java version of SUnit. Although JUnit has a lot of pros, there are some cons to it. One of them being that it doesn’t help with documentation, which i did not know about at all. This means that there is no manual on how big or small each case should be. It instead offers templates. They may sound nice but they do not take into account the different kinds of classes and how they react within its different surroundings. This is no good because others will not be able to understand what is going on. One of the most important things that we can do is to give the same care that was given to our production code to our test code. This means constant refactoring, removing duplicates, having short and readable methods and leaving only if necessary comments. The rest of the article goes in depth on the different measures and precautions that can be taken when applying specifically to testing. This is honestly the first time that I am actually taking a look into testing. I have worked on it when need be in my other programming classes, but have never fully understood the importance, what specifically should be done and the different things that can be done when it comes to testing. This article was the easiest to understand out of the testing articles that I had looked into. The way Groeschel wrote about testing and specifically JUnit testing, was very simplified and I felt I did not have to go over sentences too much to understand what he was trying to convey. I cannot say if I agree or disagree with a lot of what he said just because this is such a new subject matter for me, especially when he starts to talk about JUnit but i felt like a lot of what he said seemed to have made sense. I am excited to see what JUnit has in store for me this semester.

Hello,

My name is Mia and this my first blog for my new blog website. Here you will find articles, blogs, book and/or podcasts that I have found interesting and my point of view on them. More is to come in the near future, Thank you for reading! Mia

URL: https://www.acast.com/completedeveloperpodcast/a-gentle-introduction-to-refactoring

For this weeks Podcast, I again listened to Complete Developer Podcasts. Today I will be talking about a brief introduction into refactoring.  This includes the Wiki version of the definition of Refactoring and a more likely and on point definition of Refactoring. Also included will be reason you would need to refactor code or want to, reasons why you wouldn’t want to or need to. Refactoring while it may be simple is something that I have overlooked in the past because it wasn’t a topic that was spent a lot of time in class on. I thought like a lot of the topics that I have listened to this semester, are about topics that I knew or heard about, but did not go in depth about. Will and his co-host did a really good job about describing what it meant and what it does, which I always appreciate since reading a book can sometimes be hard to understand.

So to start this off, I will give you the Wiki definition they said first when talking about Refactoring. Refactoring is the process of restructuring existing computer code, changing the factoring without changing its external behavior. Refactoring improves nonfunctional attributes of the software. While this may be the definition for wikipedia, this does not actually define what it is. A more realistic definition is that it’s making the internals of the app less painful. Anything you are working with inside the application that is a pain-point and ways of getting rid of that, it is ways to make the app more extensible. The wiki version does not include everything and is not on point.

The next point to cover is answering the universal question: Why need it if you did a good job on your code already? The first thing to point out from this question is that nobody does a good job on their code completely. Nobody builds things that the world doesn’t change around. Your code is going to be under different restraints and requirements. It may be the best code but given some time and it will eventually become garbage. To begin, the first reason is improving the ability of developers to troubleshoot problems. Make it where developers can actually tell what is going on. The next reason is to improve testability. THis means making code changes that are not intended to be surfaced to an external party. Its code changes for organizational structure, testability, or management structure that are internal to your organization and not to your surrounding parties. The third reason is trying to decouple internal components. An example is if you have different pieces of the app that are testing to each other. So part A is dependent on Part B, B is dependent on Part C which is dependent back on B. THe problem though is when you want to upgrade for this instance Part A. If you have a massive dependency like this example portrays, it can be painful because you upgrade A and B gets busted. The fourth reason is to reorganize code in preparation for future observations, which in this case is hitting people now with the new mobile space. They now have to support tablets, phones and even iwatches. You don’t want to break the external functionality, but they have to tear things apart for it to work. People have to pull things apart to put new things in and refactoring helps prepare for this. The fifth and last reason is breaking components apart so you can iterate on them separately. You usually see this in bigger systems, where the company builds an app to handle everything internally. As they start to scale up, for example they go to franchise model, all of a sudden things need to be separated to functional efficiently. Code would need to be reconfigured to best survive the environment that it lives in, it is a evolutionary process.

Lastly what was talked about was why not to, don’t want to refactor code. One reason is organizational inertia. This idea is when someone believes that the code that they have is already good enough, so why mess with it? Another example is when a company has use the same code for a long time it has always worked, and never faced any bugs. If it works perfectly, why mess with it and cause unneeded problems? People also feel attached to their code, so they may not want to change the code that took them a lot of time to perfect. Technical considerations are also important. ANother reason is volatility in your tool chain. This is the inability to comprehend existing system and the inability to test the code.

Overall, I felt that this podcast was very informative. It explained a lot about why refactoring would need to be used and it helped a lot with my general understanding of what refactoring was. I was happy to find a podcast about this because it was very simply explained while going into some detail but without getting too complicated. SOmetimes it is hard to find podcasts that are informative, but also entertaining to listen to. As always, I really liked the podcast that I listened to and definitely recommend it to anyone who want to learn about the basics of refactoring.

URL: https://www.acast.com/completedeveloperpodcast/code-smells-part-2

    So for this weeks article I thought I would switch things up and try a different podcast. Instead of Coding Blocks I decided to go with Complete Developer, which was the first podcast group I had listened to when I first started listening to Computer Science podcasts. The first one I had listened to was called Code Smells part one, and I will actually be talking about the second part that I had listened to this past week. In the first part of the Code Smells podcast they talked all about what Code Smells were and how they correlated with class structures and architecture.      Before we talk about what was talked about this time around, we should first redefine what Code Smells are. They are defined as Code Smells that are quick and easy to identify that may need to be refactored. They are high level signs that point to areas that you may need to take a closer look at in your code. This does not mean that you need to refactor, you just need to look at the code in more than one angle. There are a number of different Code Smells from general to paradigm to even language fracturing different smells. Today we will talk about different code smells related to the actual code itself with naming, unnecessary and bloated code. Naming conventions is important and keeping to that criteria is also important. You should name methods on what they do, not what they produce. Uninformative naming can cause code smells and this varies from person to person. Method names that do not describe what the method does is no good. Other developers should be able to read the methods and know what the method does. They also should know who wrote what code. To go along with this is inconsistent naming. This is naming that does not match throughout the code. They even mention a story about a co-worker who would change their code after an object would go through a method, which is very bad. Make things consistent can help you to automative things with your code, so pick a standard and stick with it.  Another thing that can cause Code Smells are the “Do something ahead” which is when you have unnecessary or pointless code/ boostrapping code. Absence of these help for cleaner code. Anything that is not being used in the application, compilers remover anyway, so if you keep all of this unnecessary coding there will be Code Smells seen. Another problem is when requirements change and things get commented out. When you leave commented out code, branch it out instead, that way you can always go back to it but its not in your code and instead in your source control. The point of code smells is that they are quick easy ways to see deeper problems.  Redundancy, more than one duplication, is when two classes, or two methods do the same thing, may not have the same code but do the same thing is another Code Smell. It happens when multiple developers are working on the same thing in a project and are unaware of each others efforts when solving that problem. So the wet code needs to be dried out, and by that don’t repeat yourself. After that they go off on a tangent about comments and when they should and for the most part shouldn’t be used.      As always I really enjoyed the podcast. I am always happy to be able to find another podcast that is just as enjoyable to listen to as Coding Blocks. I think the way they split this up into two different podcast was also helpful so I wasn’t getting a lot of information all at once. It’s important to note the different kinds of Code Smells so when I am coding I can be aware of them and fix them before they get even smellier. Enjoyable and interesting as all of my other ones!