About a two years ago I wrote a blogpost about how the finals week procrastination affect directly to students. But this time my last-blogpost will take different direction.
This is my last semester of college and it’s kinda sad because it’s ending. But at the same time it’s awesome because the point of college it’s not being here forever. The goal is to get knowledge and skills to survive in the outside word.
So for the Testing and Quality course I learned theory and did most of the things that I was using already at work (as unit testing and continuous integration). But I learn even more things I didn’t know that existed.
To be honest I enjoyed the flexibility the course gave me, maybe for students that spent the whole day at Tec, this approach is not very good. But for people like me that don’t want to drive at 3:30pm though traffic jams and very hot days. This course is the best option (bonus is that you can learn at your own pace).
There are some disadvantages for the course structure. The course works for students that do their assignments when they are supposed to be done (or at least not soooo far away from the deadline day). But for students they might think that not having deadlines or attendance mean vacations. which is not true. It’s important for the student to manage their own tasks. Or at least try to change their minds about not having a person behind them telling them to do work at what time.
I think this course is good for learning testing but also an awesome introduction to take control of your own time.
Though the 3 previous parts, we practiced our Continuos Integration. We built and test (and did some kind of monitoring) to a central repository after “automated” builds tests are run.
“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.”
Martin Fowler, another guru of software as Kent Beck
So I learned that DevOps is helpful for finding errors quicker than waiting until the end. Sometimes you don’t know the failures that might happen outside the local environment.
Cheating a bit with Jenkins
Jenkins is a good option if you want to build at a bigger scale. This is an open source automatization server written in Java, advantages of using it:
Continuous integration an delivery
“Easy” installation and configuration
Has hundreds of plugins
Extensible and Distributed.
I know that a lot of companies use Jenkins because it makes the DevOps practices a lot easier, since it has a lot of flexibility.
But not everything is color pink. One of its advantages can be a double edge sword, the fact that is OpenSource. Therefore some issues might take longer to fix. Also the migration from an old instance to the newest is a big pain (real work-life situation).
By this day, I had this question twice in my Testing course exam, “What’s the deal with excise tasks?”
Excise is all the extra stuff we have to do, what it costs, or the time spent on the project. For example, buying licenses, researching, money used on testing. These tasks consume a lot of our time. I believe this is natural, that excise tasks take more time that actual revenue.
Off topic – Exam week
This post won’t have the minimum quality I would expect for my regular blogposts. But what would you expect from a post I’m writing a Friday Night/Saturday morning at 1:20am?
I just finished all my hard exams and started to felt weird for doing nothing, so writing a post for this blog was a partial terrible? solution. I’m 100% sure this will change tomorrow morning after waking up for the first time in 6 days of sleeping ULTRA late. I didn’t left things until the end this time, but the fact that I’m a graduate candidate makes everything worse. It’s like being the guy who will kick the last penalty in a final of the FIFA world cup. A mistake can decide of whether I graduate or not.
CENEVAL exam, student loans documentation, and exams week merge into a short period of time. But I have faced this kind of stress at least once every single semester during the 5 years of college and every time I have survive. I thank all my friends and family that have supported me to become the person I’m today. A person who can write a blogpost of DevOps and only speak about it for 1/3 part.
I learn basics of DevOps and realized that 90% of the time doing the code was trying to figure out why it didn’t work, therefore it was excise.
This post will not be about Software Testing and Quality, (sorry JUnit fans). Today I’ll talk about a very well written blogpost called “Blogging and me” from Ana Rodriguez (find her on twitter as @ohhelloana).
I had a Scheme exam two hours ago. So after this test I just wanted to relax myself a little bit. So I decided to read the “Blogging and me” blogpost. I started because I had to, but I finished it because it was so enjoyable to read.
I don’t even know if I can do a post like that. Writing like two paragraphs takes me forever and it’s filled with syntax/lexical/semantical errors. But the important moral of the post is more about don’t be afraid to share your content.but please use your common sense before publishing
I tend to write my blogposts thinking that someday some person will find it by mistake. Probably if he just sees a bunch of text without any styling, he will just close the page.
And maybe I will never get to anybody besides those Malaysian bots that appear on my WordPress analytics every now and then. But as Ana Rodriguez say:
“Blogging can make memories that you own and are in control of;”
And I believe this is truth, my blog posts are just pictures of myself. Old blogposts show what I was thinking in a previous parts of my life, and may even remember periods of my life I didn’t remember.
Revisiting my first content
My first commit: It consisted in a line that said “Hola” (Hello). Not the greatest licensing for my code whatsoever
My first blog post: I tried to start a blog for myself, where I gather nice movie quotes and random thoughts that I felt I couldn’t shared in social media as Facebook. (fun fact: this blogpost is fill with love poems and corny memes from my teenage years, avoid it)
Maybe in the future I’ll see this blog as kinda lame as well.
My first tweet: I remember having a Beatlemania phase on middle school. Of course that a lot of people have heard the Strawberry Fields Forever song Kevin!!
My first instagram post: I remember instagram logo wasn’t as colorful as today, and it wasn’t owned by Facebook, maybe in 6 years Mexico will be owned by Mark Zuckerberg.
My first video: I don’t even remember the email for that account. But I was a very big fan of Neopets.com. I used to do videos and stop-motion lego animation with my sister’s camera and my dad’s laptop. I don’t even understand how I got 1.7k views for those videos. Even with my current channel I can’t pass the 30 views.
Internet is a tool
So in the end, internet is a very extensive term. It allow us to do so many things. But it is also a place where we can express our thoughts and content. It’s incredible all what you can do. Blogging is boring if you decide to do it boring. If you hate writing, you can always go to video-blogging or podcast. There are so many alternatives ready for you to use
Last week was the 30th anniversary of the World Wide Web! 🎉 This is the same year that the Berlin wall came down and sadly the last time that Liverpool became premier league champions. (yes it’s a long time ago).
So thanks to Tim Berners-Lee, inventor of the WWW, now you can be reading this post from almost any part of the world (not the building 2 from Tecnológico de Monterrey, Campus GDL internet is really bad in there). Here is a quote of him that describe his vision of the internet
Suppose all the information stored on computers everywhere were linked. Suppose I could program my computer to create a space in which everything could be linked to everything.
Internet has changed our life in sooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo many ways. And I’ll show some of them thanks to a very cool site that took ✌🏻screenshots✌🏻 of old web pages, this is WayBackMachine.
Its awesome to see how internet keeps changing. In 1994 (just 5 years after the WWW was created) Pizza hut was already doing online pizza delivery. The site (image below) looks like a site that didn’t found the css file. But still it’s awesome to see how we integrate the net into our daily life.
Simple Smalltalk Testing
Changing the topic a little lot, I’ll speak about basic small talk. This is based on this article written by Ken Beck (a guru of testing).
If you want to see my thoughts about the article directly you can download the hypothesis chrome extension.
PyCharm and PyUnit
If you have Linkedin Learning (before Lynda) a good course you can follow is this. I couldn’t find any place to leave a comment but in a form of Course Evaluation, and I also gave a like to the course.
Welcome back to a series of blogposts about how to set up a little server in a Linux Virtual Machine, in this post we will lean about Github and SSH
if you are not familiar to the topic you can go to the first or second part of the series
Ensure that you have your GitHub account.
Before you start you should have a Github account.
Ensure that you have a repository created for testing.
If you followed the last part we had a web server created in node, we will use this. This will be our root.
Setup your GitHub two-factor authentication.
This part is a step forward process and Github explain it 100 times better than me, but I’ll explain it anyways in case you don’t want to move to another site. It’s really nothing from the other world, is more just following a series of steps:
Go tho the git setting and click in the security tab
Click the enable two factor button
Follow the steps in the site
⚠️ ⚠️ DONT FORGET TO SAVE YOUR RECOVERY CODES ⚠️⚠️
They send you a mai anyways
You are ready
Github SSH keys Setup
This is a little bit harder than the last step, the Github team explain it as well (though some commands don’t work the same for ubuntu)
Ensure that you can do a git clone (use ssh) to your server from your repository.
Welcome to a series of blogposts about how to set up a little server in a Linux Virtual Machine, if you are not familiar to the topic you can a little more about in here (which is the first part of the series)
Install a Linux distribution
For this task, I chose the Ubuntu 18.04.1 LTS which runs in Virtual Box. This is the same I use for other courses (maybe this is not a good idea). If you would like to download the same Linux distribution, you can install this “old” mini iso from ubuntu.
Other Linux distributions (thanks to @ken_bauer for the links) :
DevOps is a hot trend lately, but it’s not a new thing. This term is becoming real popular in recent years, (just like other terms as machine learning and agile methodologies),
This chart is tricky since there weren’t that many Google internet users at 2004 to 2009 but still you can see the big raise of search numbers in recent years
So… what is DevOps exactly? According to the Agile Admin. This term is all about agile operations and the value of collaboration between development and the operations staff throughout all stages of the development lifecycle when creating and operating a service.
Developers + Operations = ??? = profit
In other words, DevOps is the cooperation between the development and operations team and the people involved in the project to have a satisfactory delivery. It encapsulates the continuous delivery, automate deployment,designing the operability and monitoring.
The DevOps and the Agile methodologies are very tied together, nevertheless, DevOps and Agile are not the same thing.
In my experience, the DevOps team is the team everyone blames when a push is made into the development or any other phase and it doesn’t work properly. They are the sysadmins or masters of /Jenkins/Travis/etc… but this is not exactly the truth. DevOps is the answer to the fast pace of the modern world technology.
Continuous integration in testing
Thanks to the continuous integration which is a part of DevOps which is based on Agile, a developer can download a source code, test, build the system and verify the test! So mistakes made by developers are caught fast. So both DevOps and System tests in agile methods share the idea of “automate builds” including the verification tests. Sadly this process takes time, so the test have to be fast!
Like all the popular stuff, some people won’t like it (either having a reason or not). DevOps is popular so… some people say it’s the same thing sysadmins been doing forever just with more ceremonies and the agile principles. But I guess DevOps is a perfect solution for software development because more than just a term is a combination of tools, values, principles and practices that allow the delivery of projects at a higher velocity.
All agile methods have an underlying assumption that instead of defining all behaviours with requirements or specifications, we demonstrate some behaviours with specific tests. The software is considered correct if it passes all particular set of tests. But to be honest, no one is sure of what the term correctness mean when applied to a computer program.
Do TDD tests do a good job testing the software?
Test Driven development is an agile approach (agile is a mindset not a methodology). So it’s a good tool to be responsive to change, because its focus is create a system that does something as early as possible. TDD allow us to obtain critical feedback quickly as possible. For example today at work something in the backend crashed, but it’s better that if it’s going to fail, that fail as quickly as possible. In conclusion, yes, it’s good depending your focus.
Can we automate our tests without TDD?
Yes we can, automation is not unique to TDD
Can we use TDD without automating our tests?
Yes we can, but this mean it will be manual, so it will have to spend more time and it will return the human factor. So in other words, it’s a no in disguise.
What four structures do we use for test criteria?
Minimal test set
Minimum test set
What usually prevents our tests from achieving 100% coverage?
As discussed later, there are infinite number of inputs and can’t be explicit enumerated. But we can divide up the input space to maximize the number of faults found per case. To be honest a 100% coverage is not even a realistic or possible goal. Secondly, some requirements can’t be satisfied and are very hard to find (as a purple M&M’s according to the book). Sometimes this is because the existence of dead code that can’t be reached.
Another reason, what does 100% even mean? Where is the criteria for saying how much worst is 99% from 100%.
Some organizations in industry who adopt TDD report that it succeeds very well, and others report that it fails. Based on your knowledge of TDD and any experience you have, why do you think it succeeds sometimes but not all?
Even the book knows that the main cost of Agile methods for testing (in this particular case TDD) is that a lot of things are different. So it’s not easy for established teams and companies to change their mindset just like that. Therefore, sometimes TDD fits the project, sometimes it doesn’t. It’s not the methodology but how it’s implemented.
A few software organizations use test criteria and report great success. However, most organizations do not currently use test criteria. Based on your knowledge and experience, why do you think test criteria are not used more?
Based on my experience, test criteria is still used, but not as it used to be. It’s more about following what the user story specifies. The term completetesting or full coverage are poor designed because the potential inputs for most programs are unlimited.
In traditional software development, system requirement are often questionable in terms of how complete and current they are. In agile methods, they are undocumented! So what do system testers do?
Amman, P. and Offutt, J. (2016)
As the book say, there are no definite answer for test criteria.
It’s very funny painful how sometimes when I work on a project, 40% of the time is dedicated to develop a functionality and the rest fixing the secondary effects. If this effect is a bug then I write an issue either on the repository or anything related to the project management. But here is the trick, as humans we believe we can keep track of everything in our minds, but in my experience I have seen a typical scenario:
(I | He | She | They | We ) will write about the bug later or in the next sprint
Something that will be fixed very late or never.
The authors Jorge and Gina have proof of why we can’t fully rely on electronic repositories a 100%. Which is mainly related to coordination problems.
Do we always record the necessary information to understand the whole story of the bug?
According to their studies the researched bugs databases had the next problems:
Some bugs in the records are not bugs in strict sense.
Some bugs have duplicate records
Some bugs exhibit symptoms that are initially seen as different bugs and recorded separately
Some bugs do not always die when they are marked as closed
Some bugs basic field in the records are incorrect
Some bugs have wrong status.
Some life of bugs will never be understood without a face to face or personal investigation.
So in the end it is really interesting to see how when they tried to see the track of the life of the bug they reached dead ends. Or found that histories omitted important details of the bug. I believe our social human factor is the key to why we can’t trust 100% information extracted from electronic repositories.