Software testing

As an occasional poetry/tales writer, I tend (except in certain times) to reread my works before marking them as concluding. Not only to check spelling or logical mistakes, but to check the quality of them. Well, software developing is the same.

Software testing is crucial for functional software. Why? Because we tend to make mistakes. If we were able to write flawless code, then we might not need testing. But given that only Jeff Dean may be like this, we, the mortal programmers & engineers, must test.

Testing helps us finding bugs and fixing them. Bugs are those little errors in the code, which may be unnoticed at first. But, when you notice them, they are a big headache. So, detecting them during development is extremelly better than detecting them during production.

There are two big types of testing: static and dynamic. The first one consists on reading the code, checking out documentation, asking others to review your code. Basic stuff. However, dynamic testing is more complex. Dynamic testing consists in the opposite of static testing: do not read. Work. Try. Experiment.

Some examples of dynamic testing are:

  • Alpha & beta testing: give your project to a limited number of users. They will find bugs for you, because users are the worst enemy of programs.
  • Destructive testing: try to break the program. If you succeed, then you must fix it.
  • Regression test: when you modify the code a lot, test, because it will probably fail.
  • A/B testing: given two inputs which are different, see how both outputs change.

As for the levels of testing, we can find:

  • Unit testing: as it name suggests, it focuses on units, simple modules, each small brick of the big building.
  • Integration testing: it focuses on the integration between units.
  • Component interface testing: it focuses
    flickr photo by Allxan. https://flickr.com/photos/allxan/4010503035 shared under a Creative Commons (BY-NC) license
    Continue reading "Software testing"

Software design patterns

Nature is formed by patterns. As my data structures teacher, Dr. Méndez, keeps saying in our class: “PATTERNS!”. So yeah.

Software desing patterns consist in, as you may think, patterns when designin software (what a great reasoning). But why is this important? When designing with patterns, you have some advantages:

  • Code reutilization: by following the same pattern, one can always have a starting base, instead of starting by scratch.
  • Standarization: using patterns, code becomes simpler to read, easier to understand and, if another developer continues the work, he/she will have a lot less problems with it.
  • Already-working solution: if one pattern works, then it might work with another project.

Software design patterns can be classified into the following:

  • Creational: focused on the creation of objects and the manipulation of them. Examples:
    • Builder
    • Object pool
    • Prototype
  • Structural: focused on relationships between entities. Examples:
    • Adapter
    • Bridge
    • Decorator
  • Behavioral: focused on the behavior of and within objects. Examples:
    • Iterator
    • Publish/subscribe
    • Template
  • Concurrency: focused on multi threading. Examples:
    • Active object
    • Reactor
    • Thread-specific storage
flickr photo by Avital Pinnick https://flickr.com/photos/spindexr/6678273769 shared under a Creative Commons (BY-NC-ND) license
flickr photo by Avital Pinnick https://flickr.com/photos/spindexr/6678273769 shared under a Creative Commons (BY-NC-ND) license

Let’s be open source

The term “open source” refers to something people can modify and share because its design is publicly accessible.

Anyone can work on it

Basically, open source means that anyone can modify, upgrade, enhance, or use a piece of software. Although it was mainly introduced in a computing branch, the term has taken many other set of values.

Why is it preferable?

There are four basic benefits from using open source coding.

  • There is more stability because development never ends, and with it, testing is always present. Many points of view are exposed.
  • There is more control on the software. The user has complete control.
  • Training to become a better developer.
  • People consider it more secure someone out of the main team can spot a mistake and correct it

Beyond software

As it was previously mentioned, open source has taken a lot of interpretations. Collaboration methods of working mainly. It is not only on software anymore. Companies, schools, and everyone is implementing this way of thinking, developing projects, and accomplish tasks.

Open source in LEGO

Resources

https://opensource.com/resources/what-open-source


Test me!

“Testing is the process of evaluating a system or its component(s) with the intent to find whether it satisfies the specified requirements or not.” (TutorialsPoint, 2016)

Software needs to be tested to determine if all requirements were met. If there are any errors, bugs, mistakes, or gaps in the system.

Who does testing?

The more the better. Different points of view are required in this process: Normally, there is a software testing team; however, software developers, managers, and users also participate.

It is important to implement this phase throughout the development.

Why? To save time, reduce costs and errors.

Testing never ends

This means that there is always some improvement to the system; therefore, testing is needed to see if there is something to be improved.

Types of testing:

There are lots of testing types including compatibility, performance, usability, security, recovery, comparison, stress, unit, load, regression, system, etc.

Most known testing types are alpha testing which is done at the end of the development phase, where the software is almost complete; beta, where end-users are the ones testing the system supposedly finished; and black-box which tests if the system covers requirements.

Video:

Complete tutorial:

https://www.tutorialspoint.com/software_testing/index.htm


Let’s talk about GOF baby!

So here you are again. If this is your first time, welcome to my blog, and congratulations for trying to learn something new.

What am I talking about?

Software Design Patterns, which are solutions to typical problems that software developers face during development. Trial and error was the method in which these solutions were obtained. A lot of time has been invested in Design Patterns.

What is GOF, and why is it important?

GOF or Gang of Four is the name of the crew that began this movement. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published their book Design Patterns – Elements of Reusable Object-Oriented Software in 1994. Their method in two basic methods of OOP (objected-oriented programming):

  • Program to an interface not an implementation
  • Favor object composition over inheritance

For more information visit tutorialspoint

Video:

Short explanation on theory of design patterns in JAVA

Resources:

https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm


Software Architecture

I have already written a post about software design. Why writing another one? Well, mainly because software architecture isn’t the same as software design. Sure, archictecture is part of design. But actually the architecture is itself an area so deep that it needs to be talked about in another post. So, here is it.

Software architecture consists in the basics of software. It defines basic functioning and communication of the components, as well as the components themselves.

Some advantages of software architecture are:

  • Separation of concerns: this allows to have different people working on different areas.
  • Quality: defining a good architecture actually helps in improvising quality.
  • Conceptual integrity: helps getting a general vision of what the software do.

Why is this important? As I have mentioned in other posts, in small projects or prototypes, architecture can be not that important. As soon as the project begins to grow, order is not an option. It is a necessity. Therefore, I consider it a good practice to define an architecture at the beginning. Now: this may sound too much like waterfall method, but that’s not what I’m trying to say. Software changes. If the architecture you developed does not fit your requirements anymore, change it. Don’t be afraid of changes.

flickr photo by Will Scullin https://flickr.com/photos/wscullin/3770016707 shared under a Creative Commons (BY) license
flickr photo by Will Scullin https://flickr.com/photos/wscullin/3770016707 shared under a Creative Commons (BY) license

Software architecture

La arquitectura de un sistema describe los componentes principales, sus relaciones (estructuras) y cómo interactúan entre ellos. Estos se representa en un número de componentes que deben cumplir ciertas funciones.

Esta nos da una un abstracto para gestionar la complejidad del sistema, establecer una comunicación y coordinación entre los componentes de éste. Se define una solución estructurada para conocer los requerimientos técnicos y operacionales.

Existen cuatro tipos de arquitectura:

  • Arquitectura de negocios
  • Arquitectura de aplicaciones
  • Arquitectura de información
  • Arquitectura de tecnología

El proceso de diseño de la arquitectura:

  • Entender el problema: es el paso más importante porque según este se define el diseño del sistema.
  • Identificar los elementos y sus relaciones.
  • Evaluar el diseño de arquitectura.
  • Transformar el diseño de arquitectura.

¿Qué es la arquitectura de software?

La arquitectura de software se describe como la organización del sistema, donde el representa un número de componentes que tienen como objetivo cumplir cierta función.

También se puede tomar con todo el fin de la palabra arquitectura porque sirve como un conjunto reglas que el sistema debe seguir y hay varios estilos que pueden seguir los creadores los cuales son:

  • La arquitectura de negocios.
  • La arquitectura de aplicaciones.
  • La arquitectura de información.
  • La arquitectura de tecnología.

Pero todos deben cumplir con ciertos patrones:

  • Indicar los componentes que pueden comunicarse entre ellos y con las reglas que deben seguir para poder lograrlo.
  • Mejorar la calidad del código y su reutilización para dar solución a problemas frecuentes.
  • Describir una forma de configurar los componentes para que se puedan comunicar entre ellos.

Es muy bueno saber las distintas arquitecturas que existen para poder empezar un proyecto de la mejor manera posible, pero no solo eso también se tiene que saber lo que puede llegar a lograr lo que estas creando y por eso la arquitectura de software se me hace algo importante que todos deben saber para poder llegar al límite de lo que estas llegando y si se puede más.

Referencia


UML (Unified Modeling Language)

Models help us by letting us work at a higher level of abstraction. A model may do this by hiding or masking details, bringing out the big picture, or by focusing on different aspects of the prototype.

Modeling is an Essential Part of large software projects, and helpful to medium and even small projects as well. A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, physical models) play in the building of a skyscraper.

UML (Unified Modeling Language) is a standard notation for the modeling of real-world objects as a first step in developing an object-oriented design methodology. Its notation is derived from and unifies the notations of three object-oriented design and analysis methodologies:

  • Grady Booch’s methodology for describing a set of objects and their relationships
  • James Rumbaugh’s Object-Modeling Technique (OMT)
  • Ivar Jacobson’s approach which includes a use case methodology

What is SRS?

SRS, or Software Requirements Specification is a comprehensive description of the intended purpose and environment for software under development. The SRS fully describes what the software will do and how it will be expected to perform.

An SRS minimizes the time and effort required by developers to achieve desired goals and also minimizes the development cost.

What should the SRS address?

a) Functionality. What is the software supposed to do?

b) External interfaces. How does the software interact with people, the system’s hardware, other hardware, and other software?

c) Performance. What is the speed, availability, response time, recovery time of various software functions, etc.?

d) Attributes. What are the portability, correctness, maintainability, security, etc. considerations?

e) Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment(s) etc.?