Testing Software

The importance of testing by Lezley Davidson

We are now entering the real of software testing, which is something that has been mentioned a lot of my previous blog posts but now we are going to enter completely on the topic.

Before starting, we are going to define testing as validating that a piece of software meets its business and technical requirements.

Testing Process

The process of software test depends a lot of the company or individual, because depends on the workflow that is used, but I found this blog post by Url Eriksson that explains a general overview in 4 key elements:

#1 Test Strategy and Test Plan

I mentioned about testing plan in my Software Verification and Validation blog post, this plan comes at the start of our project while we are setting up the requirements and we improve or make changes when we have a deeper view of the system during the detailed design. Some of the elements that we need to take into account are the following:

  • Features and functions that are the focus of the project
  • Non-functional requirements
  • Key processes to follow – for defects resolution, defects triage
  • Tools—for logging defects, for test case scripting, for traceability
  • Documentation to refer, and to produce as output
  • Test environment requirements and setup
  • Risks, dependencies and contingencies

#2 Test Design

One important thing that we do not take much into consideration while we code is our test cases, this can backfire while we are creating our unit tests and do not have a proper way to test the functionality, one thing that we can do to avoid this situation is to design and plan our test accordingly, or even sometimes you can have a Test Driven Development approach.

Agile Testing Life Cycle

#3 Test Execution

Actual photo of me trying to test my code. Photo on Pickryl by U.S. Navy.

The way the test are executed depends a lot of the methodology of the life cycle that you are following to develop your code, can be a single waterfall integration test, or multiple tests every Agile sprint, or so on, at the end, your end goal is having enough tests to make sure that the system is relatively bug-free and changes do not break key components.

One of the focuses during the execution is “What is the environment that we are running these tests on?”, one example that is really common is on Mobile Development, we have a lot of set of screens and devices that go from low to high end, and need to make sure that an application work on these. On my experience, while I had done web development work at Google, we had tests that make sure that our application runs correctly on different browsers.

#4 Test Closure

To finish up our test we need to make sure that we have a green light for the test, for this, metrics are established in the company or team, some examples are as follows:

  • 100% requirements coverage.
  • Minimum percentage of tests passed.
  • Critical defects to be fixed.
  • Percentage of lines of code covered by test cases.

It all depends on what the company and the stakeholder’s establish as the requirement, as a rule of thumb, the minimum percentage of tests passed is always above 90%.

Types and levels of testing


There are many types of test that we can do to make sure that changes do not break our software, Sten Pittet has a great article where he talks about some types, we are going to talk about them here:

  • Unit Testing: Tests individual functions or methods.
  • Integration Testing: Verify that services or different modules together behave correctly.
  • Functional Testing: Verify that the output of an action gives the correct result, doesn’t matter what happened before.
  • End-to-end Testing: Replicates an user behavior in a complete software environment.
  • Acceptance Testing: Verifies that the system meets business requirements. Mostly done to end users.
  • Performance Testing: Checks the system when it’s under heavy stress to see how it behaves.
  • Smoke Testing: Quick tests that check basic functionality. Normally done after you deploy an application in a new environment.


We can find four levels of testing, that ToolsQA describes on this blog post as follows:

Testing levels by ToolsQA.
  • Unit Testing: Checks if the software components are fulfilling it’s duty. (Level 1)
  • Integration Testing: Checks the data flow from different components of the system. (Level 2)
  • System Testing: Evaluates all the functional and non-functional needs of the system. (Level 3)
  • Acceptance Test: Checks the requirements of the stakeholder’s are met. (Level 4)

Activities and Roles of Testing

QA image by Colin But.

In every software company, there is a some people that is in charge of the testing. In a blog post by Test Institute. I found 2 of the most important roles that you can find in teams at professional environments.

Test Lead / Manager

As the name suggest, this person functions as the team leader of the testing environment, his/her key activities are:

  • Defining the testing activities for testers.
  • All responsibilities of test planning.
  • Allocate resources for the testing.
  • Prepare the status report of testing activities.
  • Interacts with customers and stackholders.
  • Updating project manager regularly about the progress of testing activities.

Test Engineers / QA testers

These are the subordinates of the test lead, the key activities are:

  • Read all the documents and understand what needs to be tested.
  • Based on the information procured in the above step decide how it is to be tested.
  • Inform the test lead about what all resources will be required for software testing.
  • Develop test cases and prioritize testing activities.
  • Execute all the test case and report defects, define severity and priority for each defect.
  • Carry out regression testing every time when changes are made to the code to fix defects.

Something important to keep in mind is that on some companies, software developers also work as test engineers sometimes, if there is no dedicated team for it.

Testing environments

Types of test environments by Temdotcom.

What are testing environments exactly? Well, remember that previously we talk about all these types of tests? Now, we need to know where to run them, and also, in large production environments, they are mostly automated, for these, you need to have an environment where they can run, and that’s what we are talking about today. There are a lot different tests that can be done, and the types of test environment that we can have depends a lot on the author, so we are going to focus on the ones on this blog post by Temdotcom.

Integration Testing Environment

We talk about integration tests before, to set them up, we need to have a complete environment where we can run it, since we need to run multiple components at the time, and then make them communicate to make sure everything is working correctly.

Normally, a team will have a set of integration tests to run, and it all comes down to having the hardware, software and right configuration to be able to run the tests.

Performance Testing Environment

This environment is to determine how the system behaves in some situations, and verify their response time, stability and other factors that need to be determined based on the requirements.

These tests are quite variable and sometimes complex to determine, some of the things that need to be setup during these tests are:

  • Number of CPUs.
  • Number of concurrent users.
  • Size of RAM.
  • Data volume.

Security Testing Environment

When working with software where security is critical, security teams want to make sure that the software does not have potential vulnerabilities or flaws in different areas. Normally these are setup by security experts.

First of all, they set a base case for normal vulnerabilities that can happen on the environment of the software, for example, SQL Injection. Once this tests are done, the security experts focus on more in depth test cases that require knowledge of how this particular system works.

Chaos Testing Environment

Chaos Engineering is a whole other aspect to learn about, the main goal that we are trying to focus is to test our system when the worst possible scenario can happen, for example, let’s say that Google authentication is gone and your application relies on that, what would happen? One of the most crucial scenarios is a web application with microservice architecture.

Test Case Design techniques

We talked before on this blog post about designing our tests, in which we can use a set of useful techniques that allow is to plan and think about our test cases.

Black-box techniques

Black box testing by Guru 99.
  • Boundary Value Analysis: Explore errors on input domain. Catches any input that might break the system.
  • Equivalence Partitioning: The input data is set into multiple different classes and then testing all of that data, reducing the number of test cases.
  • Decision Table Testing: The test are based on decision tables (duh), and compared with the different combinations.
  • State Transition Diagrams: This tests are based on State Machines with a finite number of states, the transitions are based on rules that depend on the input.
  • Use Case Testing: The test cases are based on business scenarios and end user functionalities. These cover the entire system.

White-box techniques

White Box Testing by Invensis
  • Statement Testing and Coverage: As the name suggest, is testing coverage of the test cases, which means the percentage of all available methods/functions that the source code contains that are covered by tests. The acceptable percentage is given by the client or per business preferred metric.
  • Decision Testing Coverage: This testing technique covers all the possible combination of cases that will test all the branches that are part of the code.
  • Condition Testing: It covers a 100% of the code, and all expression expect true or false. The testing outcome is designed to be fast.
  • Multiple Condition Testing: Same as the condition testing but with more than two possible conditions. More scripts are required, hence more effort.
  • All Path Testing: The source of the program is leveraged to find every executable path. This can help determine faults on the code.

Managing Bugs

Once we have our application running, doesn’t matter the amount of testing that we do, as the application gets bigger, the user will always find a way to break the program in some way, and part of our job it’s to fix it, the problem is, how do we know about that bug?

One of the main ways to do this is through bug reports, which is a detailed way to log and notify developers about the defects that are present on the artifacts, while we encounter these they need to have meaningful information that helps us solve the problem. Guru99 has a great blog post that contains the following fields:

  • Defect ID: Unique identification number.
  • Defect Description: Detailed description of the defect including information about the module in which was found.
  • Version: Version of the application in which was found.
  • Steps: Detailed steps along with screenshots with which the developer can reproduce the defects.
  • Date Raised: Date when the defect is raised
  • Reference–  Provide reference of documents such as requirements, design, architecture or maybe even screenshots of the error to help understand the defect
  • Detected By – Name/ID of the tester/user who raised the defect
  • Status – Current status of the defect.
  • Fixed by – Name/ID of the developer who fixed it
  • Date Closed – Date when the defect is closed
  • Severity which describes the impact of the defect on the application
  • Priority which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively

All these information can be filled by either users or testers, depending on the way it is sent. Often a feature in the application is built to be able to log the information, for example, a simple form in a web application.

Final Thoughts

Cool meme by Buggylina

The world of software testing is huge, with a lot of places to focus on and a lot of different techniques that we can use. One of the main things I have learnt during my professional experience is that testing takes more time than what you take to code a feature, since there are a lot of factors that you need to take care of on large production environments.

One of the most important things I can recommend is to NOT write many tests for something that is not necessary, sometimes you might think that over engineering your code might be great, but sometimes can backfire and overshadow bugs that can happen during product. The best advice, be smart about your tests.


Why verifying and validating your software is important?

Photo by ThisIsEngineering on Pexels.com

Hi everyone! Today we are going to learn about an exciting and important topic for software development, Verification and Validation of Software (also known as V&V), the first thing that we need to understand it’s those two keywords, I have mentioned about them in a previous blog post, but will refer to them in here:

“A test of a system to prove that it meets all its specified requirements at a particular stage of its development.”

Definition of Verification by IEEE-STD-610

“An activity that ensures that an end product stakeholder’s true needs and expectations are met.”

Definition of Validation by IEEE-STD-610

As we can see in the definitions, the key difference it’s that verification can happen at any particular stage of the development, this to verify that the system meets the requirements at that stage, and we finally validate our end product to see if it satisfies the users/stakeholder’s expectations. Although, validating can be at the end of each stage too.

V&V on Life Cycles

V&V sounds good, but every time you are working on a software project on a company, it is natural to follow a life cycle model (you can see more about them in my post), and the question will be: How can I verify and validate at every phase?

Mohamed Sami has a great blog post, that I recommend reading, where he talks about V&V and how it’s implemented in each of the Software Development Life Cycle (SDLC) phases:

RequirementsThe requirements need to be unique and server a purpose for each one of them. The requirements need to fulfill the vision of the client/stakeholder, eliminating every ambiguity.
DesignVerify that the designs meet the requirements that are specified by the previous phase.The design has prototypes, either of UI, wireframing, or architecture design. Could even be a design document.
ImplementationThis is the place where we verify the code by using unit and integration testing, and code reviews.The requirements are well defined and implemented, make changes accordingly if necessary.
TestingVerify that all the test cases have passed, and the software works properly.Validate that the software is fit for client and user acceptance, meeting the requirements previously defined.
DeploymentVerify installation and configuration of environment, running tests.Make sure that everything works when is installed.
Implementation of V&V in SDLC phases.

International Standards

Photo by Breakingpic on Pexels.com

Now we arrive to the standards part! Which we have a lot of those regarding software practices, we are going to dive into these really briefly, keep in mind that if you want to deeply learn about these, it is recommended to go to the links I will provide in each one of them. We are going to focus on only two of them ISO and CMMI, keep in mind that there are others too. I recommend reading this blog post where it details more high level information about V&V.


The first International Standard of V&V that we are analyzing is ISO/IEC 12207:2008, which includes a series of activities of verification and validation that are part of the software development process.

The requirements need to be reviewed before going forward.Elaborate test requirements, such as the test cases based on those requirements.
The software design need to have reviews on both high and low level design documents.Evaluate testing cases based on the designs.
During implementation Code Reviews are necessary.Test functionalities and other metrics needed.
It’s necessary to verify that the user manuals and other documents are correct and updated.Test that the software meets business standards.
V&V in ISO 12207:2008

On my experience, this is the one that I am most familiar with in my past internships at Google, specially with both high and low level design documents and code reviews, which is a fundamental part of the development.


The Capability Maturity Model Integration (CMMI), evaluates the process of developing, maintaining and operating software systems. It has with it a few V&V activities that are good practice for large companies:

Do peer reviews.Validate that the software is ready are suitable for the production environment.
Establish organizational policies for planning and reviews.Make changes accordingly with the lessons learnt in the reviews.
Verify what are the work of the products built.When providing validation, everything needs to be monitored and controlled.
V&V in ISO 12207:2008

Personally, I am not to familiar with this method, although I have experience pieces of it, such the establishment of organizational polices for planning and reviews. From my perspective, this environment works best when releasing huge products for enormous companies, one example is Oracle DB services for companies. You can read more about this model in here.

Plan V&V

First of all, when we start gathering requirements and designing, we need to have a plan on how we are going to verify and validate our software, this is called the System Verification Plan, and it’s common to see in a “V” like life cycle:

V diagram from Berkeley article.

On this document it shows what are the procedures that are going to be follow to validate the program, and it also shows the requirements of the stakeholder’s. It can be written at the start of the software development life cycle, but sometimes changes are made later after the design once things are starting to get clearer about the whole system structure.

Administrating the plan

While in executing, things need to be always monitored, for this, we have can administrate what is happening, for this we mostly use tools, and nowadays, online tools, there is this document from the Requirements Experts where it shows many tools for administration, and also I have a blog post where I talk about Tools for V&V. For administration the ones that are the most useful are:

  • Verification Requirement Definition Sheet.
  • Task Definition Sheets.
  • Task Performance Sheet.

Final Thoughts

Spaguetti Code from EGU blogs.

Verification and Validation is crucial for a lot of software development companies, it provides a way to correct or identify issues before they appear, and mostly avoiding having “spaguetti code” as the code base starts to get larger. Definitely a thing that is worth reading more about!

The power of reviewing

Photo by Markus Winkler on Pexels.com

Hey there! Evaluation time, how many times have you went back and check the code that you have made before? What about how many times did you sent your code to a colleague or classmate to review it? Today we are going to talk about exactly that, why you should care about it and do it for own good.

What is it?

As the name suggested, is simply letting someone read your code and point out possible flaws or improvements that can be done. Seems easy enough, but not really, there are many aspects that need to be addressed depending on the requirements of the project or the company you are working on, but one thing is for sure, if you are an entry level engineer or an intern, you probably need to learn from someone else.

What makes a good code review?

A good code review depends a lot on the interaction of the reviewer and the person being reviewed, the reviewer needs to have plenty of experience on the programming language or the code base to do a meaningful review where you can learn from, generally, if you are open minded about your knowledge, you will have a successful code review.

There is a good video I found explaining what makes a good code review, I recommend watching it since it covers important topics for people that are not familiar with it.

Youtube video. How to make a GOOD Code Review?

Additionally, there is a really good blog post by Palantir where he goes into detail about the Code Review best practices, I recommend reading it since it makes a lot of interesting points.

What is this useful for?

One of the mains things that we can do with this review is early detection or errors or improvements that can occur, this is were senior programmers can teach and make the junior programmers make mistakes that can potentially make an outage.

Apart from outages and testing purposes, one thing you will encounter a lot in huge repositories is the Code Health, where we need to make sure that the code is readable and maintainable as possible, because on most large projects you work on, at one point there will be another person that works on it, and if you don’t follow standards or styles, it will become almost impossible to maintain. I recommend this really useful blog post about this topic.

How can I do it?

First of all, a code review is to learn, keeping your mind open even if there is 30 comments on your first submission is fine, your reviewer is there to teach you, a common list of steps you follow before submissions is this:

  • 1st: Before you commit review your own code! You are using other people’s time here.
  • 2nd: Understand what you are changing.
  • 3th: Built and test yourself, do not try to do changes without this!
  • 4th: Comment your code! Especially if it’s a complicated piece of code.
  • 5th: Consider how the code will behave in production, not all code that works locally will do on production.
  • 6th: Do test and check build files! Testing is your primary focus, most of the people will enforce you to add tests to your own code or run some test of the main pipeline to verify that your change doesn’t do any harm to other elements.
  • 7th: Follow up on reviews fast!
  • 8th: Reviewers are not perfect, not all they say has to be the absolute truth, you can reply back your reasons if you have them, but do not take anything personal.

How does it look like?

Investigating the effectiveness of peer code review in distributed software  development based on objective and subjective data | Journal of Software  Engineering Research and Development | Full Text
Code Review workflow by Eduardo Witter dos Santos

As seen in the picture, the normal workflows has the following actors: Authors and Reviewers, and on most of the huge software companies, there are many tools that verify everything. First you request your review, this will normally be automated reviewed to see if it follows the style guides, doesn’t break anything, it compiles, etc., after that, the system sends to the Reviewer the code to check it, it it’s not ready it is sent back to the Author to do modifications, and this cycle continues…

Once the Author and the Reviewer are satisfied with the result and it’s ready for productions, it can submit (or merge) the changes to the code, which this is a whole process on it’s own for DevOps. There is an important thing to notice, the Reviewer can be multiple people, in my experience at Google we normally have three types of reviewers to be able to submit any code to prod, the Code Owner (owns the repository or folders where you make the change), the Language Reviewer (it’s certified as a reviewer for a certain programming language) and whatever other person (if needed). You can add as many as you want that are necessary.

Final Thoughts

In my experience, Code Reviews are quite scary at first but then you get the grip of them and realize how useful they are. At my internships at Google, I have experience these almost daily since it’s an essential task that you need to do, and I learnt a lot from it.

I hope that you find something useful for this post, and if you want to learn more, you can always comment on this post to contact me, thanks and have a nice day! 🙂

Improving your Software with standards

Photo by Startup Stock Photos on Pexels.com

As the title suggest, we are going to learn something new today! We are going to strictly talk about Software Process Improvement (SPI), which is a methodology that allow is improve (duh) the software that we deliver. Instead of explaining it with a bunch of text, I found an excellent video that gives a brief introduction to the topic:

Youtube video about Process Improvement

One thing you can catch from the video is that is not focused on software, but it’s talking about general projects, but it’s an excellent way to get some ground start to what is about to come. Most of this process involves the following:

  • Current Situation Evaluation
  • Improvement Planning
  • Improvement Implementation
  • Improvement Evaluation

As the names say, they are all focused on improving the current state of a software. To explain more in detail about the SPI I am going to explain some of the methodologies that are used.


The Capability Maturity Model integration (CMMI) is a model that focuses on the behavior and organization, it’s objective is to provide organizations with processes to encourage productive environments and a streamline that it can follow to do efficient behaviors that can lead to problems at software development. The model consist on the following:

Implementation process of CMMI by i3 Design Consulting.

As seen on the image before, it follows the same old pattern of any other iterative process, but the important thing here is that is focused on the people, with the training and system implementation and the internal audit, where they take a really quantitative approach about the efficiency in the project parties.

A great resource to read into a more in depth approach about this model can be found at this article.


The Personal Software Process (PSP) is a structure that helps engineers to measure and improve the way the work. It helps develop skills in a personal level in the way you do your own work or projects, this is a basic structure of how it looks like:

Basic PSP structure by Juanjo’s blog.

A blog post that I really like (and the one I took the picture before) is from Juanjo’s blog where he explain into really deep detail about PSP, just a heads up, is in Spanish, but you can use a translator ;).

All the abilities that are compiled in this are a requirement to work as part of a Team Software Process (TSP), which is a process that develops huge programs, that require more than thousands of lines of codes and are intensive, one example that you build with this type of process is something like high quality medical software. A great video I found for this process (in case you want to know more) is the following:

Youtube video about TSP.


Now we enter the real of ugly names that you won’t probably remember other than ISO-1something, the good thing is that is has another name! It’s also known as Software Process Improvement Capability Determination – seriously? – (SPICE for short).

When we talk about standards ISO always comes to play with us, SPICE establishes requirements to evaluate processes and models of of evaluation, where evaluation requirements are as follow:

  • Evaluation of processes.
  • Improvement of processes.
  • Evaluation of capacity and efficiency of the processes.

Well, what the hell is all of this? Basically is a standard to determine how a process is evaluated to verify if our requirements are achieved or not, and catalogues them as a “maturity” level, in the following image you can see the way they are classified:

Maturity levels by Plays in Business

Additionally, if you want to learn more about this standard you can read the ISO official published documents, or you can read this blog post from Satish Kini about the topic.


This almost Microsoft model consists in a set of good practices and process to manage the development of software, it’s based on processes of small and medium companies, making it ideal for startups, or in small development departments and software maintenance, it’s main focus it’s on the process of the basic structure of a company, dividing it by top executives, management and operations, in which it evaluates effectiveness, productivity and continuous integration in each one of them.

MoProSoft's process categories. An analysis of the structure of... |  Download Scientific Diagram
Process categories in MOPROSOFT, article here

One important thing about this method is that is Latin American, so English information about it it’s scarce, but there is a version of the process in this link, which is a translation from the original one.

IDEAL Method

IDEAL model from “A User’s Guide for SPI”.

Initiating, Diagnosing, Establishing, Acting & Learning (IDEAL) is a model that gives a roadmap to reduce defects during the start, planning and implementation processes. The main process as seen on the model image above are as follows:

  • Initiating: Careful and thoughtful planning for successful future.
  • Diagnosing: Determine what is recommended and set strategies and priorities.
  • Establishing: Plan actions.
  • Acting: Do those actions.
  • Learning: Whatever went wrong, learn from it and improve it in the future.

For more in depth reading, please refer to the user’s guide where they explain this model in detail.

Finals Thoughts

In the end, we have a lot options that we can use to improve our software quality in the future, and also have many tools that we can focus on depending on the thing we want to build or work on. Is important no now that, as I said in my post about software life cycles from a year ago, there is no absolute or ideal model that can be used in every project, you must seek for tools and analyze what is best for you.

Have a great day 🙂

Tools for Software Verification & Validation

Photo by Negative Space on Pexels.com

Hi all :), this new topic involves tools that helps with Software Verification & Validation (V&V) focused on testing, but first, we need to do or usual sequence of learning something new, defining what is this!

When we talk about verification & validation, we talk about completely different things when we aboard testing, let’s define both of the concepts specified by the IEEE standard:

“A test of a system to prove that it meets all its specified requirements at a particular stage of its development.”

Definition of Verification by IEEE-STD-610

“An activity that ensures that an end product stakeholder’s true needs and expectations are met.”

Definition of Validation by IEEE-STD-610

There is a key difference between the two concepts, verification is involved “at a particular stage of its development”, while verification is at “an end product stakeholder’s true needs and expectations are met“. In simpler terms, we verify that our software is working during our development, and then validate once the product is finished that it meets the requirements.

Plutora on their blog has a great post defining the key distinctions of both of them and has an excellent visual resource as a Venn diagram of the task that are performed in each one of them:

Verification vs Validation by Plutora on Verification vs Validation: Do You know the Difference?

In the rest of this blog, I will share many tools that are helpful to work in a project while also providing ways to verify and validate your project if you want to go to that extend.

Version Control

Version control is an essential tool that is widely use today, when you start studying your Software Engineer career you need to learn this tool because of how helpful it is for collaboration. Most of the big companies use this to control the version of their products and that the developers keep creating more features without affecting the live product. As a summary, version control allows the following:

  • Work with multiple people continuously on a project.
  • Have a history of the changes that are done in the code and you can access them later!
  • You can work on different versions at the time and divide it in features.
  • It can integrate the work from different teams into one whole project.

Sounds great! So, can I use it? The answer is yes, it’s open source, completely free to use, we are going to see one of the most common used ones, which is Git.


A hacker is demanding ransom for hundreds of stolen Git code repositories -  The Verge
Git logo by Git.

This is a free open source version control system that is widely used, it’s the most common one you will find everywhere and it’s a must know at least of it’s existence. Many other version control systems has some other tweaks and improvements depending on the requirements that are needed, but for general purposes, Git is the system to go to.

The way Git works is to handle every change as “snapshots”, that way, every time a rollback or applying a change is needed, just changes between these two snapshots. For example, let’s say that your Hello World program prints “Hello World!” (duh) and you submit it using git, let’s call it Snapshot 1, then you want to change the program, instead of printing that you want to print “Hello everyone!”, once you do this change you create Snapshot 2 and submit to the repository, the way to Git to update the most recent one is to change the Snapshot from 1 to 2.

Add change to staging area then commit to repository
Creating a change set with Git by Andre Fachat

IBM has a great post talking how Git works technically, I will recommend to go in depth of the basics of the system to learn a little bit more about this important tool.

To learn Git there are a lot of resources out there, here are a few of them:

On my experience, one of the version control systems that I have used in the industry is from Google, it’s called Piper, it’s built to handle billions of lines of code in a single repository, you can read more about this on a Wired article by Cade Metz where he talks about Google’s repository.


The frameworks that automate testing have been increasingly appearing over the last few years, specially due to their high demand, one of the ones I have used before is Selenium.

SeleniumHQ Browser Automation
Selenium logo by Selenium.

Selenium is automated browser interaction tester, it can help to do complex tests that can be time consuming to do by hand, for example, let’s say that you want to verify the login of the user to a shopping cart, it can be quite hard sometimes to do all of that process just by code, that’s how Selenium comes to play, it can help makes all these things easier in a testing environment and you can “record” the actions that you want the test to perform.

There are many resources to learn from thanks to it’s high popularity, one that I personally prefer is from the documentation section of SauceLabs, explaining with details and examples the way it works and how to use it.

Apart from Selenium, there are many tools that are available that you can search for that suit your needs, some examples:

  • Katalon Studio: RESTful APIs, web services, etc.
  • TestComplete: JavaScript, VBScript, Python or C++.
  • IBM Rational Functional Tester: Web, .NET, Java, Visual Basic, Siebel, SAP, Adobe Flex, etc.
  • Many others

Tools for Administration of V&V

Test Management Tool | Kualitee
Dashboard view of Kualitee.

Administration is quite a challenge when it comes to applications that involve multiple team members, and of course, when an engineer sees a problem it will find a way to create a tool to automate it, to illustrate an example of one of the most famous tools out there, I am going to talk briefly about Kualitee.

This is a web-based test management tool, it supports manual and automated testing, giving a great dashboard and full control of the test workflow. When you are managing a project, often you need to setup a development pipeline to try to avoid errors or problems that can harm the product in the future, and this is what this tool tries to help. Some of the cool features in has are:

  • Mobile application support, with logs & assigned bugs.
  • Create your own automated testing, manage and execute it from a single tool.
  • CI and other 3rd party integrations, including Selenium for web testing 🙂
  • Manage the project, test cases, track issues, report tools, etc.

Of course, this is not the only option, there are many tools to explore until you find the one that suits your needs, some other famous examples are Jira & Jenkins.


In software development, testing and management are really important tasks that we take for granted on the school, we do not really care about those things on the projects we normally do for a class, but on the industry is a must, starting to learn about these tools that we have available it’s a great way to be prepared for what is coming for those you doesn’t even know about Git, hopefully this can help as a starting point to find what you are passionate about 🙂

Giving Quality to your Software

Photo by Startup Stock Photos on Pexels.com

Quality? Is that something edible?

At the start of the software engineer career, one of the first things that the professors try to teach is understand what is what we call software, of course, the definitions can vary but in the end we can agree upon a simple definition: “It’s a set of programs that allow the computer to do tasks”. After understanding this you can now create your own program and gain millions!!! Well… no, sadly, once you enter the real world you understand that software tends to increase in complexity as the project starts to grow, and that’s when quality on our software comes into play.

And now the important question then, what the hell is software quality? And for this question, I like a definition on this blog post by TestBytes, where they described as the following:

The quality of software can be defined as the ability of the software to function as per user requirement.


This definition applies to whatever program that you build, for example, your Python hello-world program has the quality you would expect if by running it prints “Hello World!”, it’s easier to maintain it’s quality due to the lack of complex requirements, but when we start thinking about programs or services as big as Google Search, what are the key aspects that can tell us about it’s quality? For this, Silas Reinagel created an interesting blog post defining seven aspects that constitute software development. I created a simple diagram to briefly explain all of them:

Aspects of Software Quality by me.

How Can I Ensure the Quality of my Software?

One of the things I have learnt is that this question is not simple to answer, since it depends on the organization and what they are trying to achieve. Global App Testing member Fahim Sachedina, has a good blog post that tries to answer this question, on the other side, Experimentus member Nigel Rawson has a post focused on testing, combined with the information display in here I will list 3 things that can help out with improving the quality of the software that you produce.

Prioritize the user

“Quality is essentially about meeting user expectations. Consistently. Reliably. Confidently.”

Karin Dames, Editor of Teal Times

The user is everything, it’s the one that you need to head your software towards, if you do not make the customer happy, they will simply find for an alternative and you lose. One important thing you need to start to worry about is the User Experience, is one of the investments that startups need to put their resources on if they want cases of success in their products.

Testing is your friend

Photo by Startup Stock Photos on Pexels.com

Testing is everything, specially for bigger companies, imagine, your service is running live for millions of users, and you decide to make a change that ultimately crashes the whole system, now everyone hates you, what could you do to avoid that? T-E-S-T-I-N-G

It is a crucial part of your development pipeline, every crucial change needs to be tested to avoid problems, one of my recommend approaches to get used to testing is Test Driven Development (TDD), what I like about this is that it forces you to think about how to test every line that you code, and as painful as it sounds, it is actually not that difficult, Kent Beck is his famous book sums it up pretty well:

1.- Add a little test.

2.- Watch it fail.

3.- Make a little change.

4.- Run Tests and succeed.

5.- Refactor to remove duplication.

Kent Beck

Innovation = Improvement

Github Actions for automated workflows.

From my experience in my internships at Google, one of the things that are used nowadays is automate EVERYTHING, and one of the most important things that help with a multiple developer environment is automated testing, where each change that the developers do is the to check the verify, there are many tools available for students that you can start to learn to get used to it, GitHub actions has started to have many features available to allow this kind of automated actions, you can check about them in the Marketplace.

Reviewing code

Photo by Kevin Ku on Pexels.com

Reviewing is a good thing, before submitting your changes, once you submitting the changes do a code review, but also, it’s important to do refactoring of a code base once a project gets bigger. One important thing is to reuse, what worked well. I found a post from Sukhrob Golibboev that talks about the importance of refactoring, I will suggest giving it a quick read.

Standards of Software Quality

One of the things that makes my heart hurt from time to time is when I hear someone start to talk about ISO or IEEE, it can be painful and boring to read pages about international standards sometimes, since the information can be really confusing to get at first, but in fact, we came across these everyday in our life’s in the industry. Particularly, when we talk about Software Quality, the ISO 9000 and IEEE STD 1061-1998.

But I found something interesting, I blog post in Monterail by Paweł Rebeś talks about how ISO 9000 was the previous outdated, and then they introduced ISO 25015, that adds the categories marked in red in the following diagram:

ISO/IEC 25010 categorization of software quality requirements Source: ISO20500.com

I would strongly suggest to read on Rebeś blog post where he does a great job explaining into simpler terms every point that is marked on the diagram.

Something to keep your mind on

As you advance in the path to becoming a software engineer, one of the things that are crucial to take in consideration is the quality of the software you develop when you develop a project that is part of a big company, there are many tools available to automate the majority of the activities that we as developers do (testing, deployment, etc.), this can help a lot to improve efficiency and to ensure that we deliver a product of the biggest quality to our customers.

If you have the chance of working into a bigger company all these tools will be provided to you with some internal technology/framework that you will learn to use, but on most of the cases all the tools are pretty similar outside and inside the company, so starting to learn Github Actions, Jenkins, etc. will help a lot in your future 🙂

Returning to the world of blogging

Hey there 🙂 It’s been while since the last time I created a blog post, I started this as an activity of the course #TC2004, and now I am back and upgraded to #TC3045.

A quick review of interesting things about me, I am a student from Mexico currently enrolled in the university ITESM, my passions are technology, music and video games. On the professional side, I have been in two Google internships (currently I am finishing my second one), and I am mostly focused on being a full stack developer.

My family and me taking a picture outside the Google store in the Googleplex, Mountain View, CA.

On the category of this course I will focus on covering topics about Software Quality and Testing, as well as my ideas on certain topics and the experience I have with these on the professional environments, if you want to have a chat with me or contact me I will link the following social media and public accounts so you can contact me or know more about my work:

I hope you can find something interesting in my post and I am available for any discussion about any topic 🙂

Modeling Languages and Tools

Grady Booch flickr photo by vonguard shared under a Creative Commons (BY-SA) license

On almost all my previous blog posts related to Software Development I had mentioned a lot about something called Unified Modeling Language (UML) created by Rational Software, but I haven’t really covered the definition of it, and as you can guess, in this post we will cover the topic of Modeling Languages and as all the other definitions we had seen, by itself is quite abstract and covers a lot of alternatives.

If you search for Modeling Language, you will probably end up with results about UML because of it’s popularity, but according to Techopedia, the concept by itself means any graphical or textual computer language that provisions the design and constructions of structures and models following a systematic set of rules and frameworks.

As stated, you can basically create your own unique Modeling Language, called it as whatever you want and become famous (if you are lucky), but, you might have the question, why is UML so popular? In this post we will focus on answering that question. Keep in mind that there are a lot of modeling languages out there (this image pretty much sums a lot of them up).

Unified Modeling Language

One of first things you will probably see when you start exploring the software development environment is the word UML (I pretty much spam you with this word in my TC2004 blog posts). The creators of this modeling language are Ivan Jacobson, Grady Booch and James Rumbaugh (yes, they appear again!), there’s a lot of information UML, there’s even an official page (I recommend checking it out), but let’s try to put it in less complex words, we can summarize it as follows: it’s just a standard modeling language, which is a way to design and construct the system we are building.

I recommend reading the History of UML section by Visual Paradigm, in which they show a great timeline of how it has been evolving, but where are we now? Let’s look at an image that shows how a UML diagram looks like:

As you can see by the image, we define the actors, the actions it can do, and it’s interactions with the other parts of the systems, but there are multiple types of UML depending on the thing you are trying to represent, for example, you can also represent objects:

There are several types of UML representations, this post by Noel Ceta showcases and explains some of these types, I recommend you to check it out to learn a little bit more. Keep in mind, that if you go to other sources on the Internet or books, you might find a little differences in the way the information is presented, but they basically state the same thing, so don’t worry.

Creating UML Diagrams

Some of you might want to create UML diagrams because they are really useful to show dependencies in your code, and it’s really easy to do it since nowadays there are a lot of useful tools online that can help you with that, for example, if you code in Java, the names Eclipse and Intellij might sound familiar to you, the good thing about this IDE’s is that they provide a ton of functionalities, and one of them that is very usual in Java is the ability to generate the UML diagram of your project. For Eclipse you can use something like ObjectAid UML Explorer; in Intellij you can find it as a built in feature (you need the Ultimate Version, if you are student you can get it for free ;)).

But let’s say that you want to plan your UML diagram while designing (should be the appropriate approach to avoid spaghetti code), if you are a student with an adjusted budget, I really encourage you to use Draw IO, I have personally used it a lot for the past years in college, and it’s a saver.

Final Thoughts

Again, you probably have the feeling of: “What should I use?“, and of course, I cannot answer that questions, as every single thing in our path through software development, like methodologies, tools, techniques, etc., we have been seeing that there are an incredibly amount of alternatives to pick from, the same applies to Modeling Languages, we only talked about UML, but you are free to use whatever you want, but it’s important to at least know a little bit about everything to make sure that you can choose the right tools for the job you are making.

System, Actors and Relationships.

Continuing our journey to understand software development, we will stop to think about the important aspect of the product we are building, and by that I mean who is interacting with our system. Now, imagine that we combine the words that are in the title, what do we get? The answer is our next important topic: Use Cases.

Where are going to continue by defined the use cases based on the Unified Process paradigm we defined in the previous post Unifying Software Development Methodologies, where there are going to be many users that interact with it, and those interactions might be different depending the type of user they are (actors), and also might have different relationships with the objects that are part of the system or other users. For example, an online classroom (the most used example, but easiest to understand), where there are teachers, helpers and students. They have different views, permissions, and a different way to interact with the whole system, i.e., the system has different use cases depending on the user.

via MEME

I know, i know, I might be over reusing the word “use cases”, I didn’t understood at first why they are important because they kinda seem obvious, so let me explain. Most of humans are really good at creating or building something if you have a set of instructions, sometimes these steps are really easy to follow and even sometimes are not necessary, for example, when you are preparing a bowl of cereal, you don’t really need instructions for that, but if you want to make a Lakeside Paella, you probably not even memorize the ingredients.

Use cases are really important to define the actors in the system, and at the same time, creating a blueprint of what to expect. This blog post by Tech Republic states that use cases are a great guidebook when you are developing and they give ten reasons why they are really important, in my options these three are key (the rest are important too, I recommend reading the post, it’s really useful):

  • Reveal process alternatives, process exceptions, undefined terms, and outstanding issues: You will never cover all the things needed in a complex system, but you need to try to minimize these errors, and when you create use cases, you and your team can start brainstorming or realizing about things you haven’t consider before.
  • Recognize patterns and contexts in functional requirements: Some uses between uses are related, and by defining them before hand, we can define similar functionality that both can share, to make a more simpler and cleaner design.
  • Ensure the delivered software works properly: A key factor before delivery is testing, and if you have a blueprint of the expected behavior, you can use it to create test based on those assumptions and write good tests that others can read and help understand the functionality of the system.

There’s an important thing that you need to consider about use cases that Josh Spilker states on his blog post “What Is A Use Case?” (careful with the popups): Use cases explain behaviors, but not how to built or construct the system, they are quite simple.

Sometimes use cases are represented as diagrams, and in that case are part of UML and known as Use Cases Diagrams, they do not have to be always like that but are one of the common ways to define them.

Final Thoughts

If you read my previous post about Software Life-cycles, I talked about Agile, that approach has some term that might sound familiar to you if you read more about it, called User Stories, which I originally confused with use cases, they are somewhat similar, but they really serve different purposes, I recommend reading User Story vs Use Case by Visual Paradigm to understand the difference if you are struggling with the same problem.

I find quite amazing what people on the 80s-90s built from the necessities they started noticing when they were building software systems back in that time, and that the name Ivar Jacobson appeared again (this guy is everywhere in these blog posts). Use cases are a clear example of that, they are something that is really useful for early and future development because they define part of your requirements, an also you can come up with things you haven’t thought before.

Unifying Software Development Methodologies

Photo by Christina Morillo on Pexels.com

On a previous post I talked about the Software Development Life Cycles, in this post we are going to continue looking through one specific process, called Unified Process (UP).

This well written scientific journal defines it as a system that goes though many iterations, with cyclic feedback and adaptation. Meaning that the whole system is development incrementally over time, and by each iteration the process makes changes based on the feedback received. There are four main phases: Inception, Elaboration, Construction and Transition.

We need to make clear a definition that can commonly lead to misunderstandings, the Rational Unified Process (RUP) it’s one the best known UP, and sometimes authors used this names interchangeably, but the Unified Process is referred as the general concept of the whole framework, since there are many examples of UP’s, the concept just include those elements that all the processes have in common.

Rational Unified Process (RUP)

This process was developed and published by Ivan Jacobson, Grady Booch and James Rumbaugh for IBM, were they combined their methodologies into a single framework based on UML. Probably these names are familiar to you, if not, I recommend you to read more about them, they have created and published a lot of tools and techniques that are used widely in software development, one example is Unified Modeling Language (will explain this topic in a future post).

IBM published a paper were they defined the Rational Unified Process as a disciplined approach to assigning tasks and responsibilities within a software development organization, and its goal is to ensure the production of high quality software, taking into account the needs of the end users, and it has the following characteristics:

  • Is a process product.
  • Enhances team productivity.
  • It’s activities create and maintain models.
  • Is a guide of how to effectively use the Unified Modeling Language.
  • Is supported by tools, which automate large parts of the process.
  • Is a configurable process.
  • Captures many of the best practices in modern software development.

To explain each one of the main phases of the process, here’s a quick and great video that summarizes everything you need to know, it you don’t like to watch videos and prefer to read a more in-depth definition, here’s a great blog post that shares information about the process and it’s main phases.

Video explaining the four phases of RUP.

Other Unified Process Examples

As I stated before, there are many more UP-like processes that developed over time and when needs on the industry change, these are inspired on the Rational Unified Process, and make it simpler or with little modifications since sometimes all the elements of RUP are not needed, but maintaining the core of it. We are going to see two quick examples: OpenUP and AUP.

Open Unified Process (OpenUP)

This is a method that is open license (as the name states), were only the fundamental and sufficient elements are included, it was used by the Eclipse Foundation, in other words, OpenUP is a lightweight alternative from RUP. There is a great article called OpenUP – The Best of Two Worlds that briefly explains why it’s useful to use this process. Here’s a diagram presented by the Eclipse Organization on a document that well explains the OpenUP process that I recommend reading:

Diagram of the OpenUP life cycle.

Agile Unified Process (AUP)

Similar to OpenUP, AUP is a simpler version of RUP developed by Scott Ambler. He actually wrote an open document were the whole process it’s defined. The process uses Agile techniques and concepts such as Test-Driven Development and Agile Modeling, it life cycle phases are defined in the following figure :

The Agile Unified Process (AUP) lifecycle.

It changes a little bit the phases work during the iterations having some other things in considerations, but as you can see, the core patterns are very similar to RUP.

Final Thoughts

The Rational Unified Process is a great software development that inspired a lot of processes used widely in many organizations, but it can be a killer in smaller projects, that’s why OpenUP and AUP exist, they get rid of the complexity and robustness that the original process has, making it more simpler and only doing the work that is enough, following other principles. It’s important to keep in mind that you use what you need in the environment you are in.