Monthly Archives: May 2014

Posted:
May 8, 2014
Comments:
0 Comments

Scrum

Scrum is a framework for project management, normally present on Agile Software Development.

Scrum is based in an article “The New Product Development Game”. In the article, authors suggest a new approach to product development using the rugby approach.

This framework is based on constant periods of time, called Sprints, to develop the features. Usually take 2 to 4 weeks.

The structure of the Scrum framework is composed of three roles, six meetings and four artifacts: The team is divided into three roles:

  • Product Owner: Person responsible for maximizing the value of work;
  • Scrum Master: Person responsible for ensuring that the team works and is productive;
  • Team: Members of the team that are self-sufficient to do their job.

There are six types of meetings:

  • Sprint planning: The team meets with the product owner to select the tasks for the sprint;
  • Daily meeting: The team meet every day, usually lasting 15 minutes, in order to update the Burndown chart and every team member responds to three different questions: “What have you done since yesterday?”, “What are you planning to do today?” and “Any impediments/stumbling blocks?”.
  • Sprint reviews: The team demonstrates the functionality to the product owner made during the sprint.
  • Sprint retrospectives: The team searches for new ways to improve the process and product.

In SCRUM, four types of artifacts are produced

  • Product Backlog: An ordered list of prioritized project features, from highest to lowest. It is dynamic and can be modified at any time as needed during the project lifetime
  • Sprint Backlog: A set of features taken from the product backlog (from highest to lowest priority) that team is committed to execute in the sprint. These features are divided into small tasks that are assigned to the team members.
  • Burndown charts of the sprint and delivery: It is a graphical representation that allows the verification of the tasks status.

ScrumExplained-3

Posted:
May 8, 2014
Comments:
0 Comments

Testing Phases

The software testing can be dividing into four levels (unit, integration, system and acceptance). In each level, different approaches are used and different characteristics are tested, if you want you can check V-model.

In this post I will only give you an short overview about the level, I will introduce more details in a future post.

Before I start explain the level, I need to point that test level are represented using a pyramid because for healthy software testing approach you need to respect  balance between the tests.

Test levels

Unit test

The unit tests have the purpose of finding faults in units of software. The units can be a class, a function, an object, or even just a method or procedure.

This is the first level of the test to be executed in the application, in which the white-box method approach is usually used.

 

Integration test

The integration tests are intended to test the internal interaction and communication between the various components of the Software.

At this level of testing, the most common errors found are related to the transmission of data between these components:

  • Interface misuse: Bad interface usage of a component calls for another component and makes an error in the use of its interface
  • Interface misunderstanding: The component sends the request and misunderstands the specification of the interface of the component receiving the request and makes assumptions about its behaviour. The called component does not behave as expected which then causes unexpected behaviour.
  • Timing errors: These occur in systems that use a shared memory or data. When a system requests data, it can be outdated or inexistent.

The integration tests are mostly black-box but sometimes can be white-box.

 

System tests

The system tests test the system as a whole, where the hardware and software are integrated. The main objective of this level of testing is to ensure that the system behaves according to specifications.

In this level, for the first time, the non-functional requirements of the product are tested.

These tests are black-box.

Acceptance tests 

Acceptance tests are the last tests to be conducted before it is sent to production. The application is tested in an environment where it will be used.

These tests are black-box.

 

Posted:
May 8, 2014
Comments:
0 Comments

Basic definition Model based testing (MBT)

Idea:

The main idea is describe your software in a model, for that you can use, for example, UML or finite state machines.

Advantages:

  • The tester will have a more global vision of product, which helps to identify non tested areas and problems with requirements
  • The most of the tools for MBT generate the test from model. This is advantages because sometimes it was a small change in your model, like new step was introduced, but will affect several tests. Imagine a coffee  machine that now you need to confirm that your order is correct, it is just one more stage but will affect several tests.

Disadvantages:

  • Complexity of model, sometimes is really difficult write your software as a model.

     

Posted:
May 8, 2014
Comments:
0 Comments

Basic definition Behaviour driven developer (BDD)

Idea:

The main idea is describe your software using examples, for a coffee machine a good example is I want coffee with level 3 of sugar.

Advantages:

• Ubiquitous language, this means all stack holders in your project are able to read your test
Disadvantages:
  • This methodology is only applicable for acceptance testing. In my personal opinion, it can be use for system tests as well.