After 6 months automating tests with QA Team

0 comentarios

I've read several times in the last few months that there are companies removing Test or QA Teams in the organization. Something that was like a "seriously? It can't be as testing ensure the quality and quality is one of the most important thing if not the most in product development", but after a few months tuning the ALM I was involved I've started to understand what the comment "that company has removed QA" means. I have to say I didn't read more than comments about remove QA, I never red the reasons, probably because I didn't want to know as I thought on that as something unthinkable.

If we imagine the usual situation where there are teams developing the software and teams testing the software, some years ago those teams where located in different places even in the same office, but now companies are moving them together, QA team member next one or two or even three developers, keeping the communications faster and clearer which is one of the key of the QA - Development relationship.

6 months ago we started building our QA Team with our first member, sitting down next to Developers and understanding how company runs Development Lifecycle, and at some point our QA player started to write UI, Integration and Instrumentation tests, so he became to be part of Development Team but not developing code or fixing bugs, everything related to testing the code to be written or already written.

After few months running this experience we can say it has been great for both parties, developers and testers feel they are the same team and they are developing the same product, giving to that product the right quality. Now, we can say or understand QA Team Members are becoming part of the Development Team, removing the words QA Team, but behind the scenes QA is still present.
Read On

QA is not testing

2 comentarios

Let's say we are part of an Agile team, running sprints to develop a software product where developers, testers, product owners and scrum masters are collaborating to deliver new features or functionalities in each sprint. One the classic discussions are around testing within sprint or testing after the sprint, but let's have a quick look to both approaches.

Testing within the sprint could mean that developers write Unit Tests and Code as first thing in the sprint and deliver the new code to QA Team some days before the sprint ends to let run testing plan and see if new code is bugs free.

In the other hand, testing after Sprint ends could mean developers are focused in write the new functions and features while running the sprint and the code is released to QA Team once sprint ends, letting developers to run a new sprint.

My thought came to my mind when running running sprints following the first approach (testing within sprint) developers were always delivering new features to QA Team with a very tight time to run the testing plan. We made the decision to run testing plan at the beginning of the next sprint, which means developers would prepare a new release ready to test when Sprint ends and move to the next Sprint. This helped to let the Developers understand the release ready to test should be under proper testing (developer testing) as they are the owners of the work delivered, letting QA Team to be focused on ensuring the software works as the Product Owner defined.

With QA is not testing we say Developers proceed with the testing of the new code written, following TDD they test their code runs properly and put in the output the expectations for the given inputs. With this Development Testing in place, he QA Team will run testing plan rounds being focused in the functionalities, ensuring the quality of the product meet expectations.

Of course this is not a must, each team should find their path at any moment and look always to the results to see if they should tune their current process, an specific approach could work for a particular moment developing a particular product with particular team members, a change in the equation could produce a change in the approach followed, just keep looking yourself to keep moving to the great success.
Read On

My first Androide Library

0 comentarios

It is a pleasure announce my first Android Library, it is a simple JSON client with the goal to use in backend web services communications. Decody JSON Simple Client is a set of classes I've written and used in several Android applications and I want to share with the community, hopefully, it won´t be the first library.

Check the library in Github and let me know your feedback, also it would be great if someone is happy to help with new changes and features I have in the ToDo list, the library is currently looking for contributors.
Read On

Material design is here to stay

0 comentarios

If you listen "Material design" your head goes probably directly to Android 5.0 aka Lollipop, but it seems Material Design is more than a new version for Android devices / platform. it's a concept Google team wants to circulate or put ​in every interface.

Part of this ecosystem is the new framework for Web Developmentcoming from Google developers, it's called Polymer and it's basically a framework to create web components, it lets transactions between components, interactions, more details can be found in the demos section of the website, specially Topeka.

Other excample and inline with our developments is the Material Design implementation for AngularJS, which contains some nice components for user interface.

As an end of this article, it would be better give you more details reading the article analyzing the differences between Polymer and AngularJS.

Happy coding!

Read On

Mocking: El comienzo

0 comentarios

Hace cuestión de un par de meses preparé un pequeño texto para dar una escueta charla alrededor del concepto de mock y técnicas básicas de mocking, la idea era que un equipo de programadores tuviera un primer contacto para la creación de tests unitarios donde el codigo a probar tiene una dependencia con clases externas.

Claramente hay montones de artículos, textos, papers, tutoriales, ... en internet que cuentan el mismo problema que estamos tratando en este artículo, sin embargo, puede ser que siempre le pueda servir de ayuda a aquellos programadores que van a enfrentarse con el mismo tipo de problema, y otro ejemplo más siempre ayuda a comprender mejor cómo aplicar la solución.

Cuando como programadores nos enfrentamos por primera vez a la creación de tests unitarios para el código que estamos programando, uno de los problemas complicados es el de comprender cómo crear tests unitarios para aquellas clases que tienen dependencias con clases externas, ya que una de las primeras ideas que se nos ocurren es, la de probar conjuntamente la o las clases dependientes, a la vez que la clase que inicialmente teníamos en mente. Esto contradice la definición de test unitario, donde se pretende crear tests para una única unidad, en este caso hablamos de una clase sin tener que probar el codigo de clases dependientes. Si la clase sobre la que estamos trabajando y creando los tests unitarios depende de otras clases, por definicion sabemos el comportamiento de las clases dependientes, sabemos de antemano, por la definicion o especificacion dedicha clase la salida para una determinada entrada en cada uno de sus metodos que la componen.


Tomando como ejemplo de lo comentado el esquema anterior, nuestra idea es crear tests unitarios para la clase Navigator, la cual hace uso internamente de NavigatorFlow y NavigatorListener. Dado que inicialmente no hemos creado interfaz para NavigatorFlow (INavigatorFlow), la clase Navigator hace uso directo de NavigatorFlow, lo que obliga que al ejecutar los tests que escribimos de Navigator se ejecute el codigo de NavigatorFlow, lo que ademas de agregar complejidad a los tests unitario, estamos probando dos unidades en lugar de una.

Para evitar esta complejidad y hacer nuestras vidas mas fáciles como programadores, es preciso tener en cuenta a la hora de diseñar la jerarquia de clases, que creemos un interfaz para la clase NavigatorFlow y esta interfaz es la usada dentro de Navigator, de esta manera los tests unitarios que vamos a escribir serán menos complejos a la vez que nuestro codigo sera mas fáil de mantener y sencillo de entender por otros programadores.

Gracias a la creación de la interfaz INavigatorFlow, podemos en la clase que contiene los tests unitarios, definir un objecto mock (NavigatorFlowMock) usando dicha interfaz e inyectando dicho objeto mock en nuestra clase Navigator antes de ejecutar los tests unitarios. El objecto mock creado implementará la misma interfaz que NavigatorFlow (INavigatorFlow), lo que nos ayudara a definir la respuesta a la clase Navigator.

namespace MockingFirstExampleTest
{
    ///

    /// Unit tests for Navigator class.
    ///

    [TestClass]
    public class NavigatorTest
    {
        ///

        /// This is the instance of the class under test.
        ///
        private Navigator navigator;

        ///

        /// Mock object of NavigatorFlow.
        ///
        private Mock flowMock;

        [TestMethod]
        public void TestNavigateSuccess()
        {
            var input = "MyInput";
            var expectedOutput = input + input;

            // define expectations of the mock object
            flowMock.Setup(flow => flow.DoNext(input)).Returns(input + input);

            // call to navigate method
            var output = navigator.Navigate(input);

            // check expectations
            Assert.IsTrue(output.Equals(expectedOutput));
        }

        /// 
        /// Set up the common stuff for the unit tests.
        ///
        [TestInitialize]
        public void SetUp()
        {
            // create the mocks objects
            flowMock = new Mock();

            // instantiates the class under test
            navigator = new Navigator(flowMock.Object);
        }
    }
}
 

El código anterior define una clase de tests unitarios para la clase Navigator, dicha clase contiene una instancia a Navigator y otra que es el objeto mock de la clase NavigatorFlow (flowMock). En el método SetUp, el cual se ejecuta antes de cada test unitario, lo que necesitamos es instanciar el objeto mock e inyectar éste mismo en el objeto de Navigator.

Asimismo, en los test unitarios (TestNavigateSuccess) se configura el comportamiento del mock, en este ejemplo se indica que el objeto mock va a recibir una llamada a DoNext con una entrada determinada, y le indicamos la salida (Returns) de dicha llamada. En este caso estamos haciendo uso de una librarías de mocking existente, hay montones de librerías que nos facilitan la vida para aplicar estas técnicas, además, se pueden definir varias salidas y distintos comportamientos en nuestros objetos mock, solo es necesario conocer la librería que vamos a usar. También es posible crear el objeto mock sin librerías pero nos obligará a escribir algo de cødigo en una clase aparte, sin embargo, hay circunstancias donde es mejor esta práctica que el uso de una librería.
Read On