• Home
Posted:
Nov 23, 2014
Comments:
0 Comments

Emulator and Simulator definition

The mobile testers sometimes don’t have access to real devices, it means they have to use simulator or emulator. Well, the Apple has simulator and Android offer an emulator.

The genymotion is commercial simulator for Android, I had use in the past and I think it is really good.

The most important question is: What is the difference between simulator and emulator:

Simulator: The simulator behaves in a similar way but doesn’t respect all the rules. For mobile testing it means simulate the behavior of the device but using the computer memory and cpu as you know is much greater than the real device.

Emulator: The emulator emulates both software and hardware, however not all the hardware can be emulated e.g. accelerometer, multi-touch and phone calls. For me one of big problems of emulator is consume a lot of resources on your computer, It means that sometimes your application will look slower in emulator than in real device.

 

Sources:

https://developer.apple.com/library/ios/documentation/ides/conceptual/iOS_Simulator_Guide/TestingontheiOSSimulator/TestingontheiOSSimulator.html

http://developer.android.com/tools/devices/emulator.html

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.
Posted:
Apr 1, 2013
Comments:
0 Comments

Defects classification

The most used defects classification is severity and priority.

So, What severity and priority:

  • Severity: Is the impact that the defect has on the system
  • Priority: Is the order in which defects need to be solved

I will explore this topic in a future post 😉

Posted:
Mar 28, 2013
Comments:
0 Comments

Agile testing

The software test plan in project development using agile is different to the plan used in traditional development methodologies (example: WaterFall).

The tester usually reads the requirements and defines the test plan but the ideology of agile project is creating more functionality instead of documentation. Therefore, the existing documentation may not be enough and the tester needs to communicate with the developer. An objective of the agile development is greater communication between people involved in the project.

Another problem is the timeline; the development is executed by sprint. The sprint is usually done in a short time and it is necessary to plan, develop and test the functionality. The functionality is only considered implemented when tested. In an ideal system the development of the test should be the same as the testing time, but when the development is delayed, the time test is compressed.

In agile development, it is possible for the test not to be executed by an independent team but by any developer who is given the role of tester of certain functionality. The only restriction is that the developer has no involvement in that functionality of the test. The approach of not having an independent team for the execution of the test has the advantage that the developer becomes more sensitive to the testability of the code. In other words, when the developer produces code, he remembers details necessary to allow the application to be tested.

The agile testers have ten principles; they are represented in the image below.

I recommend the book Agile Testing: A Practical Guide for Testers and Agile Teams.

h

Posted:
Mar 27, 2013
Comments:
0 Comments

Web-testing

Web testing is an interesting challenge because Web interfaces are very dynamic.

Web Testing represents a big challenge to the developer too, which include:

  • Impossibility of controlling the number of users ;
  • The website needs to be available 24-hours per day;
  • The website is modified with more frequency;
Posted:
Mar 22, 2013
Comments:
0 Comments

Automated Test

When a company decides to have automation test they need to have some ideas in mind:

  • They don’t have an immediate benefit from automation
  • The automation of all tests are not applied or wanted because in an automation process some classes of errors are lost;
  •  It is not possible to convert a manual test to an automated test without analyzing the test
  • The tester needs time to plan the test;
  • The initial time to select and learn the tool used in the process.

The reason the keep this post in mind is that automated tests only have benefits when executed many times.

The advantages of using this strategy is:

  • Reduced test execution time and cost – The test can be executed automatically and the tester only needs to program or start the execution and analyze the results.
  • Increased test coverage on each testing cycle – Automated tests can allow testing teams to execute far more tests than using the manual test approach.
  • Increased value of manual testing effort: The automated test is never better than a manual test for finding errors. This cannot replace the tester as they only execute routine tasks so the tester can concentrate on finding new errors. An example of a regular type of an undiscovered error by the automation testing tools is usability.
  • Reduced manual work: The test automation reduces repetitive manual work.

In automated testing there is an initial higher cost (effort) compared to the manual test, but as time progresses, the cost of an automated test is much lower than in manual testing.

 automatedTest

For me, it is unbelievable when I hear people saying that manual testing is obsolete and they want all tests to be automated. The paradox of this type of thinking is that when we are always testing the same thing, we end up testing nothing and in fact we are regressing by not using other methods of testing. We cannot forget that the testing tools are blind even if there is another defect on the side, they will not be able to identify it. I believe in automation testing of course but always with a small part of manual testing.

Posted:
Mar 16, 2013
Comments:
0 Comments

Bug Life Cycle

Hi guys,

Today I’m going to talk about a bug’s life cycle.

No QA likes to have defects in the code but unfortunately they do appear :(.

The life cycle of a bug is the journey of this little creature from its discovery to its elimination. The Life Cycle has some variations from organization to organization and it is generally influenced by the defect-tracking tool used.

Typically the bug life cycle has the following four phases: New, Open, Resolved and close.

 

New:

When the tester or a stakeholder finds a defect, a new bug is created on tool. It means that the bug has not yet been approved.

 

Assigned
Most companies don’t consider this phase as it is incorporated in the Open phase. In this phase the development leader confirms the veracity of the defect only.

 

Open: In this phase, verifying the veracity of the defect if necessary (refer Assigned phase). The developer reads the bug description and debug software to identify the bug that is causing the failure.

 

Resolved: The main objective of this phase is identifying that defects have been resolved and they can be retested.

 

Closed: After the bug is successfully retested, the bug is closed.

bugLife

During the bug life cycle is important understand the following terms:

  • Retest: QA activity, when the qa validate that bug was fixed. If the bug was fixed the bug state is change for resolved, if not the state is change for open.
  • Closed loop: QA activity, where the tester tries to understand what happened to the bug has found in production
  • Postponed: The team lead or product decides that bug doesn’t have sufficient priority to be fix right now.
  • Deferred: The defect isn’t a defect or is duplicated.
  • Regression: Normally, it is when you fix a bug and the bug returns.