Week 3 Plan

Tasks for this week:

  • Send email to Abraham
  • Research other technologies that will interact with WhatsApp API for SugarCRM.
  • Research iFrame + WhatsApp
  • Find options for unit testing in Javascript.
  • Create Software Requirements Specification Document
  • Define Unit Tests
There will be an issue on Github for each task.
We will administrate the issues and other stuff as spikes in the project. Link in here

And also a little of organization in here

And we store most of the documentation in here

Test && Commit || Revert ?

About two weeks ago I started an internship in a Software company. They like to use this relatively new framework known as Agile. But it isn’t only used where I work, it seems that a lot of companies are trying to migrate to an Agile approach (or some kind of distorted version of it 🙄).

In other words, they like using the SCRUM mindset.

In other words, Ken Beck has influence my work days and probably a lot of many other people.

So after doing a lazy Google research I found out that the Agile roots (extreme programing) were mostly developed by a smart guy named Ken Beck. He did not just worked on this awesome methodology, but also contributed to Test driven development, Smalltalk, helped popularized the CRC cards along Ward Cunningham, and made the unit testing framework JUnit. It’s incredible all the work this guy has contributed into the Software industry. ​

Kent Beck (right image) Was one of 17 authors of the Agile manifesto which shaped the constant changing software industry

So what about TCR?

Kent Beck proposes: TEST && Commit||Revert which basically consist in:

If my test pass then I want to commit it!

If I fell that something wrong happened in my code then I can go back to the last time it worked. Therefore, the incentive is to make small changes, all in a stable way. It’s better to have many smaller commits than a big commit with all the different changes.

This doesn’t mean you will have to write more tests. But if you are going to make 3 tests at once maybe it’s better to test one by one so the code of the 3 don’t fully disappear. As Kent Beck says:

How could you make progress if the tests always have to work? Don’t you make mistakes sometimes? What if you write a bunch of code and it just gets wiped out? Won’t you get frustrated?

Kent Beck

And yes, the mistakes will be made, we are humans and the human factor will never assure to have working code 100% of the times. But it is better to instantly wipe out all the bad code. So if you don’t want for big chumps of your work to be sent to the forgiveness then don’t make really big commits between the successful tests.

I guess most of us, university students that hadn’t finish a Testing course, program either by submitting the whole code project until the end, until it’s working as a whole. I’m not counting much the team projects because we commit occasionally, but, it’s a different reason. I think we commit to share code, not to have it safe for testing. And even deeper I guess we don’t do any formal testing.

TDD vs TCR

Test Driven Development: Also created by Kent Beck (is there anything this guy can’t do?), is basically a programming practice where you have to write test first and then write the code that will pass it. Finally do a refactoring.

I don’t have a lot of experience with TDD to be honest. To be even more honest I wasn’t even sure about what it really meant. I guess my testing before this class was running a program, if something goes wrong fix it. And occasionally throw as many weird inputs to see what happens. But I want to change this. Maybe TDD is the solution, maybe not.

TDD workflow

Test Commit Revert: It’s an alternative workflow. TCR is chaotic in a sense that there will be different problems. Maybe TCR will be very weird in Github. To have a lot of tiny commits, for 12 line of code seems incorrect. But there are some solutions as squash commits. If all test passes then commit to master, if anything fails use the the revert button, Life is too short for waterfall planning.

References

You can read the whole Agile manifesto (all along the early 2000’s web pages experience) in here: https://agilemanifesto.org .


Semester Plan

  • Week 1
    • Planning
  • Week 2
    • Planning
  • Week 3
    • Planning
  • Week 4
    • Research SugarCRM API documentation
    • Research for the best way to integrate WhatsApp into a webpage
  • Week 5 – Week 10
    • Development
  • Week 11 – Week 13
    • Quality and Testing
  • Week 14
    • Deployment

This plan is an estimation, it can change through the time

Week 2 Plan

Welcome to the team sugar‘s quality and testing blog. For the first week we will do the following tasks:

  • Write a general description about what the project is about.
  • Discuss in the team the structure of the blog posts and the logistics in there.
  • Understand the APIs to understand the limits of our project:

Meet the editors:

Samuel Osuna @osunaztech

Julia Paola @juliapaolao

Kevin Cabrera @kevintroko


Week 2 delivery

What did really happened this week?

  • We did get a general description of what the project is all about:
  • Decide who will edit the post every end of the week. This was decided inside the team. The schedules can be find in here
  • Team lead blog has been assigned to Kevin O. Cabrera
  • Important files will be stored in a Drive folder.
  • Git repository setup in Github : https://github.com/samosunaz/wa-integration
  • We got access to a SUGAR CRM instance to start working 🙂

First Personal Post 2.0 #TC3045

Image taken from Diyfail.com

Hello my name is Kevin Oswaldo Cabrera Navarro. In the next 3 months I’ll be writing about Software testing, verification and quality. So why does Testing and quality matter?

Quick example of why quality is important sometimes

The emoji movie had a 8% score at rotten tomatoes. Photo credits to Michael Steber

I wonder if there was any quality department inside Sony pictures that didn’t realized about how bad does the idea of this movie actually is. This is the equivalent to the story about how small testing can save tons of money to a company. Probably the correlation is so arbitrary, but it is a good example of why everything should have a quality measurement (it doesn’t matter if it is a movie, a book or a software system)

No bugs in here! đź¦—

One of the main goals in this blog is to prevent the usage of the word bug to refer to a fault, error or failure in a program. Maybe it is a word rich in history but in this blog I will try to follow the advices of Paul Ammann and Jeff Offutt writers of the Introduction to Software Testing book to don’t encapsulate all the different meanings into only one word.

But that’s another history for a different post. See you later