Course evaluation

First of all, I present the evidence of the ECOA answering:

On the other hand, I will write a paragraph or two about Ken’s quality course. I’ve always thought that Ken’s classes are something of a great thing… if you know how to take advantage of it. Ken is a professor that must be sought to recieve his benefits, but I am not talking in a bad sense. Ken knows a LOT of people, and also knows a LOT of sources for learning. Many of these sources are given away by Ken to us, for free, for educational purposes, and there is some really brutal material from the hand of some of the most respected experts of our areas.

Sadly, most of his students just choose to not read or check those sources, they just ignore or not read them enough. So I think Ken gives really a lot of chances for us to learn, but it is each of us’ own decision to see if we want to learn or not. I like this kind of process, because I think it is a way for us to grow and gain maturity to learn in our own rhythm and with our self mind.

Deeper discussion on chapter 5

Chapter 5 in the book talks about TDD and test criteria. We had a little discusssion in class on wether this works or not. We had a little talk inside our own teams, and came to know some of the reasons this could happen. This post will take a little this topic, and will expose my own thougts.

First of all, TDD can be a little hard for programmers at the beginnig. This approach includes continuous integration, that is, push owr changes to a general reposiory where all changes from all people are seen at the moment. This helps us to see the mistakes quickly and to integrate things easier. This coding and testing approach may be a little confusing and hard to learn at the beginning, it has an abstraction level by itself.

In the beginning, this may seem like a lot of work, and repeated cycles of the same amount of work many times during the day, and this, in some sense, may be true. But one must start to think in the amount of work that will be saved in further iterations of the project. If mistakes are seen quickly, then effort and money will be saved in the end, since it is generally harder and more expensive to work in correcting errors when the project is in its final phases.

Sometimes, and we read this, some enterprises cannot have access to some specific tools, for example, some continuous integration stuff (not likely at all, I think). What I mean is that there may be some things that the company lacks for applicating TDD successfully, talking about material and also people. What I conclude from all this is that TDD is a great alternative for working and saving. Even though it sounds like more work in the beginning, the savings at the end are great, and I have strongly insisted on this since long ago.

Test and criteria for them

This week we had an approach for testing criteria. In more than one occasion we have left some testing designs for our codes, but we must ensure that these testings are well made, and that is not ensured magically. Also, we also know that we cannot guarantee a 100% fault-free software, so we need some techniques that will help us to test what we can and what is most important.

I will start with the most common statement. We cannot offer a software that is 100% free of any fault, that is theoretically impossible. Every program has a potentially infinite amount of inputs, some of which we can’t even control, so it is outside our power to make a program that is perfect. Instead, we can cut our meaning of “perfect” and put it inside a subset of important functios that will help us to check if our program is good enough for that set of functions. This is basically what criteria is all about.

Criteria is all about making abstractions of the testing and the data obtained, and trying to ensure, with those results, that the success testings are enought to bring our new program or new functionalities. These things are achieved by using the test coverage. Test coverage is the set of things that want to be covered. For example, when we center ourselves in precise methods, then those methods are the ones that the coverage must, well, cover.

I will have to leave it here, because this week we only had a little introduction to what this is like. Following posts, I shall be able to bring some examples of this, since the book dives deeper in this in further chapters, especially on how to make these tests successful.

The great TDD

This week we had our first introduction in the class for TDD, that stands for Test Driver Development. This was a developing technique that, for me, didn’t sound very well at the beginning, but, as I progressed with my job, my current projects and the work in class, I understood that this was something that I had done before, in a ver particular sense and not in the way it sould be done.

TDD is a way for developing methods one by one, and according to the things that the testing lacks to be successful. I will try to explain it better and in deeper detail. One developer starts with the requirements and specifications for making new functionalities. But what must be implemented first are the tests, not the methods. The tests must be made with some unit testing tool, or similar, and some errores will pop out. One must implement the new functionalities according to the errors and failed tests.

This approach is really nice, because, when making the tests, we can really put in our own understanding and priorities, the really important functionalities, or the urgent ones that need to be developed quickly. Also, we get a nice step-by-step (kind of) of how to develop every method and functionality. Also, we are making two things at the same time: we are developing and testing, and also, at the end, we will have a lot more confidence on the code we will develop.

I became aware at first when we were told to watch a course for unit testing in Python, and some other videos on TDD in a practical approach. I realized that this is a popular debugging form, but not in the way it should be done. I recall that I just ran my programs for finding errors, and correcting them. This is basically a debugging form, but has very much to do with this practice. In the end, we all have a little spark of testing in some ocassions, but do not realize that in that moment, but ages later, when we are taught all these things in school and have to put them in practice in a proper way.

Software quality control

This week we had the first partial exam, so for the blog entry I just wanted to tell a funny story of what I really thought the software quality and testing looked like in real life. I, of course, am taliking about many years ago, and I wasn’t really sure about going into software engineering, but I already knew I wanted to be an engineer.

When I was little, I thought a software tester was a man that was sitting in a desk waiting for new software to come out. That man had to open the software and begin to use it. Each error that was found, the man had to write about it, and send the code back to de developing zone again. I am surprised that I was not as far as I thought from reality, but it is not precisely a group of men sitting in a large office. I know many of my friends are given chunks of code implemented in an interface for them to check them, and have to write reports on bugs they find.

Not all the jobs for testing are so slave-oriented, shall I say. The general intention of a job like thise one is to have a nice and comfortable environment to make the software work better. But software testers are nothing of people sitting in a room just finding bugs and fixing them, they are responsible of the whole testing process, and are the ones who should design the testing steps depending on the final objective of a project.

Once again, I must say that this thinking originated from my current job, since I had to design a testing flow for an API, and my general knowledge did make me think about my previous beliefs about software testers, but I quickly knew it wasn’t true, since I saw no activity related to me being a “tester” involved to manually test the software, but to design some tests for a tool to automatically make them. I thought this was a fun thing to share this week.

Testing in our jobs

This time, I would like to take a deeper reflection on unit testing based on what I have worked in class and my personal experience in my job. As I stated before, we tend to overlook the testing discipline until we are asked to do it, and, God, how much are we asked to do it! I know that many of my fellow mates get a first job on testing, and they really are not so much into it, since many of us begin working before our 7th semester (when the testing course is given).

I didn’t have a first job on testing, but semestre i came to ruin my life and I am currently taking the testing course (in my 10th semester), and now that I have a new job, I was asked to design a test flow for the API. Of course, I wasn’t really sure of what to do, in fact, I thought that my major job was to test, and began to panic internally. No need to worry, because I quickly got help from others.

What I could see is that there is no better teacher than life, and these type of experiences help a lot to grow, apply things seen in class and to learn a lot. This happening helped me to make a better interpretation of the things we were seeing in class, some concepts caused me a litte trouble, but no more. Without really knowing, I designed a good flow to test 80 endpoints using the automation tool from Postman. Without knowing it, I was doing unit testing, and as I ralized that, several things came to my understanding.

I think is good for everyone to live this kind of things, and we surely all will live them, because we will all hopefully get jobs in the software area. I just wanted to make a little diving into my own experience and clarify that it was as helpful as the lessons have been, and the readings and class activities.

Test automation

This topic talks about automating tests, and has a lot of advantages. Think of people working in testing, and think about how much time do they should need to perform the testing one time, and another, and another, and also be aware that every person is different, and can have mistakes proper only to the person who is working. Automation tries to mitigate all that.

We have the division of tasks in revenue and excise tasks. Revenue tasks are the ones that provide some value to the code, for example, planning a data abstraction. Excise tasks, however, does not; for example, compiling a class. Excise tasks are the ones that are candidate for automation, since they do not require a great human thinking nor effort. Factors for this include benefits that may bring time savings, less human error, consistency of test designs and consistency of results, and many other things.

We must consider the software testability for this. That is: the degree to which a software can be tested, how easy is it to observe the results and make changes to the program. To be able to automate, we must be able to design good test cases. Test cases are, well, cases in which we want to test our codes. We have several good practices that we can do: first of all, define prefix (values to take the code to a testing status) and postfix values (values to take when everything finishes), also, exit cases, which tell us when to stop, and the verification values, that will help us to see if our test was successful or not.

Testing frameworks exist, and they answer the need of automating tests very well. It was a real headache for people to not be able to automate testings, until one day appeared some tools to be able to automate unit tests. SUnit was to automate Smalltalk unit testings, and many more similar frameworks generated, until JUnit was made. This is probably the most famous testing framework ever, and it is very, very easy to use. We hve some blog entries with excercises.

My own conclusion is that automation is a very powerful tool nowadays, and one does not see the importance of that until, one day, you see it in action, and it happened to me when, in my actual job, I had to use some unit testing tools to test our API.

 

DevOps part 5, Reflection

Now that we have had the rest of the DevOps assignments, this one is more of a reflection about everything done. Before I did this assignments, I really didn’t knwo what people were talking about when they said the word DevOps. I thought it was a kind of framework like for front end or things like that, not a series of practices to optimize the busniess and production. Right now, where I am working, they have a master in DevOps (well, sort of), and it is a person that is in charge of implementing and maintining DevOps in the company. But even though I talk with that guy some times, I never really asked him what his work was.

We got the task of seeing if there are tools or frameworks to help us implement DevOps in a bigger scenario. I found that Atlassian has many tools for this. I once worked with Jira and Bitbucket in my work, and I didn’t realized that the meaning of this was to integrate the rest of the team with the programming and the other areas in a common software for registering tasks. I couldn’t really understand how to use Jira, it seemed very confusing to me, but I think this can be an example of a good tool for this. Also, there are a lot of testing software that automate everything for us. I currently use Postman for unit testing REST API’s, it offers a nice tool that you in which you can program tests with Javascript.

Finally, I am able to understand the importance of the excise tasks and their work. On my actual work, I can understand that revenue tasks are meant to be understood by many people, therefore must be of public knowledge. Also, can require many programmers working together to come to a solution for something. Excise tasks, on the other hand, are tasks that computers can make in a daily basis (or more frequently), so testing tools can be made. This tasks help form part of the final program too, and must not be overlooked when the program is finished, we can obtain lots of information from them, when we use them for testing, for example.

Class after class and assignmet after assignment, I keep learning the importance of all these concepts and good practices. I can see it in the theory and also can see it in the practice, and they are essential things for guaranteeing a good technical and business performance.

DevOps part 4, JUnit(or other) Automation

For this week’s DevOps assignment, we were asked to make some other simple steps. First of all, have JUnit working properly from our terminal. That was achieved by using a .jar file that was practically passed to us by Ken, the result of running that jar file is the following.

I had some serioud trouble running the .jar, because had no Java installed and the packages I got were not working properly. In the end, everything went good.Next step, was to set a status page for a simple test in JUnit. The tesing code is pretty straight forward, since I am just testing a very simple function:

package junit;

public class JUnitHelloWorld {
    public boolean isGreater(int num1, int num2){
        return num1 > num2;
    }
}

public class JUnitHelloWorldTest {

    @Test
    public void isGreaterTest() {
        System.out.println("Test");
        JUnitHelloWorld helloWorld = new JUnitHelloWorld();
        assertTrue("Num 1 is greater than Num 2", helloWorld.isGreater(4, 3));
    }
}

For our next step, we verified that the tes program worked through our JUnit in the terminal, the output was simply put into a result.html. It is the one we expected, since the test can be found and verified, the file is selected with the -f flag, the command used is java -jar junit-platform-console-standalone-1.4.1.jar -f JUnitHelloWorldTest.java > result.html, and the content of that file is:

Finnally, we just integrated all that in the crontab, to make sure we push the changes into our repository. For that, we implemented a script for commiting and pushing:

The content of our contrab is:

I also had some problems for executing the script in the crontab, so I had to set those variables as I found them in StackOverflow.

And the page simply looks like this:

Finnally, I think the README can be updated the exact same way, just by filling something to it or depending on the test results. It will be important to adjust that content to a Markdown syntax, obviously.

In blogging

This week, a blog post (about blogging) was assigned for us to read, this due to some comments about the blog posting in both the Quality course and the Smart Citizens course. This post showed Ana Rodrigues telling her experience on blogging, and I had a clear idea on how important blogging is to her. I can clearly see two strong points, that I will describe in the next lines.

When blogging, one can learn a lot on several things. The intention of having a blog is to spread some knowledge with others, and this tends to be a nice objective even if the blog is just a personal experiences blog, each of them bring knowledge to the people who reads it. Also, this means that the person who writes it learns as well, in any way. One can learn while investigating something to blog about, or just to think abour themselves and write about it. It is, in any way, a place for knowledge, a really nice community for people to learn in an easy way.

I can relate myself to that, also. I have learned a lot of things when blogging, and also clarified many of them. Since I blog for some school courses, I use that as a kind of “study time” for reading and understanding some things. I some times still don’t understand the topics completely, but I do not feel that I didn’t do anything to try. It is also something of a personal satisfaction in this way.

The other point Ana has is that, when she stopped blogging, she began to be depressed. She was very busy in her work and her learning, but I could notice that her own learning without spreading it was senseless. She clearly needed a space for herself, and for spreading her personal and professional things. A blog is, also, a place for expression. She says that many people is scared of doing this, for fear of being judged, but, as it is afree space for anyone, one should not worry about that.

I’ve never been against blogging, I think it is a good personal space, a learning opportunity and a way to help others know things, to reinforce the things that you may want to reread, and also to spread, which is a very important aspect in today’s life, that information must be free and available for everybody, and blogging makes that possible, as it is people working for other people, without any interest, just for learning (well, many of them).

 

References

Oh Hello Ana. (2018, December 14). Retrieved from https://www.ohhelloana.blog/blogging-and-me