You are browsing the archive for 2012 Juni.

Avatar of anna

by anna

Labels

21. Juni 2012 in Allgemein

What is the label function?
The label function improves your opportunities to describe your bug more concise than before. A good labeled bug gives our client good details about a bug’s type and location the at first view.

It is very simple to label a bug:
Just enter a label in the label field while writing your bug report. You can choose your label freely. There are no restrictions with regard to the chosen labels. Just choose labels used by other testers or create your own appropriate label.

Here are some examples for good labels:  
$$$ bugs that can cause costs
GUI graphic errors (Graphic User Interface)
Picture & Video problems with picture or video
Usability suggestions for improvement
Email bugs with email (e.g. confirmation email)
Link bugs with links (e.g. broken links)
Contact bugs with contact formular etc.
Security bugs that affect security
Navigation errors in navigation
Registration errors within the registration process
Product choice problems with the product choice (e.g. a product cannot be
deployed to the shopping basket)

Ordering procedure problems with the ordering procedure (e.g. order cannot be submitted)

ATTENTION:  

Due to our standards of quality there are two new labels that are obligatory to use.  This is what they stand for:

rewrite Only the project manager may use this label! If you find a bug (you can also search for it) with this label, you are allowed to resubmit this bug in better quality. So examine the bug reprot carefully and improve it, so that it meets our standards.  

improved This is the label that you have to label your bug with, if it was submitted earlier by an other tester and you improved it. Also do not forget to add the original bug’s ID in a comment to your bug report.

Tags:

Avatar of anna

by anna

Screenshots

21. Juni 2012 in Allgemein

Why do we need to add screenshots to our bug reports?
A well written book does not need any pictures. But why do bug reports need them?
Your bug reports contain only little text so it is difficult to understand your steps taken until the bug appears. Sometimes it is hardly possible to reproduce the error although the bug has a good description. Therefore a screenshot is needed.

The easiest way to make good screenshots is to use the free Firefox screenshot add-on FireShot.
You can use one of the following links to download the program:
https://addons.mozilla.org/de/firefox/addon/fireshot/
https://chrome.google.com/webstore/detail/mcbpblocgmgfnpjjppndjkmgjaogfceg

After the installation your browser displays following icon:

Which functions does FireShot support?
FireShot has many funtions: You can record your full screen or just a section, you can edit your screenshot and so on.
The best way to make a good screenshot is to choose a section of your screen, record it and add an annotation via edit function.

If you found a bug just click on the symbol
Choose the option “Capture selection and…” and clock on “Edit”.
Afterwards you can choose a part of your screen with your mouse. You will hear a sound of a camera and a new window will open.
In this new screen you can edit your screenshot and add descriptions.
You can use the “Pointer” or “Shape” to highlight important sections of the screenshot.

 

The screenshot is ready now!
Good screenshots are obligatory for acceptance of your bug.

Tags: , , , ,

Avatar of anna

by anna

Bug, bug, bug… What is a bug?

20. Juni 2012 in Allgemein


Simply said: A bug is a system fault.
Bugs may appear on websites, programs or applications. However, they always cause the same feeling: Users, as well as developers are obviously annoyed.
There is a huge variety of bugs: graphical errors or broken links are typical errors, but there are many more bugs that affect functionality, security or other areas of  web pages or a programs in a negative way.

A bug rarely comes alone…
Their appearance is numerous. Developers are doing their best to avoid creating bugs by accident and simultaneously try to search and eliminate occuring bugs, but they always have one big problem: They always have the same point of view. They pay attention to the crucial areas of web pages and programs and neglect “less important” things. But in the end those bugs may be even more annoying to the user.
And that is why we need you: We need your point of view!  

 
What belongs to spelling?
Beside system faults that affect functionality or the graphical interface, there are many spelling or grammar mistakes that can be found on websites or  softwares.
It makes no difference whether it is simply a missing comma, a strange syntax or wrong word usage, non of them is a bug, as they are not affecting the functionality of web pages or programs. Spelling and grammar mistakes have to be submitted as such.
Finally it is your job to write a good description about where the error appeared and outline the steps taken. Additionally you have to add a screenshot and the label “spelling error”.

What about usability?
Usability neither belongs to bugs nor to spelling error. A usability error is not a bug, but a lack in user-friendliness, so when you submit a usability error, make a suggestion for improvement. 

 

Tags: , , ,

Avatar of anna

by anna

Bug Categories

20. Juni 2012 in Allgemein

Why do bugs have different categories?  
One bug is not like another. There are small bugs, there are big bugs.
Your task is to identify bugs, group them and assign them to three different categories: Low, High and Critical.

What is the difference between these categories?  


The difference lies in the severity of the errors and the urgency to eliminate them.
Low: Our client should fix this bug but it is no problem if our client decides not to do so. This type of bug does not affect the functionality of a website or a program.
High: This bug should be fixed by our client but there is no hurry.
Critical: This type of bug has to be fixed by our client immediately.

Do I need to consider specific methods for categorizing bugs?  
Generally, you have to take the perspective of our client. You have to ask yourself the following questions:
Is the bug so crucial that I could lose customers? e.g: Am I losing customers because they cannot complete their ordering procedure in my online store? Does a bug keep my customers from booking a flight on my website?  With no doubt this is a Critical bug!
A graphical error located in the upper left of the web page has to be classified as “Low”, particularly if it is hardly visible.
But what about a graphical error in the logo of the company? Such a graphical bug can be classified as “High”, because this may reduce a company’s trustworthiness.
To sum up:

Bugs are too different to give general instructions to categorize a bug appropriately.
Finally a small hint with respect to the final categorization:
Our client decides about the category at the end. Downgrades and upgrades are possible!

Tags: , , , ,

Avatar of anna

by anna

How to submit a bug- the bug form

20. Juni 2012 in Allgemein

Who decides whether a bug will be accepted or not? – The team leader, the customer?

No! The quality of your bug is crucial! If you do not submit your bug correctly, often we cannot reproduce the bug and have to reject it. In order to get payed, you should really submit your bugs meticulously.

That’s how it works:  

A Bug needs a meaningful titel. The first thing, the team leader and the customers sees, is the bug titel, so choose it wisely. It should not be too long, but precisely describe your bug in a few words, so that we instantly know what kind of bug you found. To guarantee that, each title should cover the following: type of bug and where it appeared.

The URL you insert should be the one you find in the browser, while your on the site with the bug. You simply have to copy and paste it then.

Very important are the steps taken to understand the bug. Those who work sloppy here, risk to lose their bug, because it is not reproduceable.

When naming the steps taken, always start with same step: “Go to the homepage.” It should be possible to find the bug starting from the homepage.

The more steps you name, the easier it will be to reproduce the bug and the more positive you can be that the team leader and customer will find your bug. But cut it short.

You can state the expected, as well as the actual result in a few short sentences. In this part you can explain your bug more in detail.

The label function is used to group the bug. You can find a list of label functions in an other blog entry. As all bugs are different, you can also insert new label functions.

You will be asked to categorize you bug. The categories are: Critical, High and Low. Please keep in mind that critical means that the bug needs to be fixed immediately. Find more information in the blog entry “Bug Categories”.

Finally name the browser you used and do not forget to upload a screenshot!

 

Tags: , , , , , , , , ,

Avatar of anna

by anna

Das Bugmeldeformular- Wie melde ich einen Bug richtig?

19. Juni 2012 in Allgemein

 

Wer entscheidet darüber, ob euer Bug angenommen wird oder nicht? -Der Teamleader, der Kunde?

Nein! Entscheidend ist die Qualität eurer Bugmeldung! Wenn die nicht stimmt, kann der Bug häufig nicht reproduziert werden und wird abgelehnt. Es lohnt sich also eine saubere Bug-Beschreibung abzugeben.


Un so funktioniert’s:
Ein Bug braucht einen aussagekräftigen Titel. Der Titel ist das erste, was man von eurem Bug sieht, wählt ihn also sorgfältig. Er sollte nicht zu lang sein, sondern in wenigen, prägnanten Worten klarmachen, um was für einen Bug es sich handelt. Der Titel muss die Fragen WAS? und WO? beantworten können! Meldet ihr einen Usability-Bug, wollen wir in eurem Titel nicht mehr die Worte “Usability” oder “Verbesserungsvorschlag” lesen. Außerdem sollte sich der Titel von anderen Bugtitel abheben.
Die URL die ihr einfügt, ist die, die bei der Seite, die den Bug enthält, im Browser steht. Alles was ihr tun müsst ist “copy and paste”.

Ganz wichtig sind die Schritte zum Nachvollziehen des Bugs. Wer hier schlampig arbeitet, riskiert den Bug wegen Nicht-Reproduzierbarkeit zu verlieren.
Starten sollt ihr immer mit demselben Schritt: “Gehe zur Startseite”. Es muss also möglich sein, den Bug von der Startseite aus zu finden und zu reproduzieren.
Je kleinschrittiger ihr vorgeht, desto sicherer könnt ihr sein, dass die Bugkontrolleure (Teamleader und Kunde) euren Bug auch finden. Schreibt hier bitte keine Romane, sondern kurze, klare Aussagen.

Das von euch erwartete, sowie das tatsächliche Ergebnis schildert ihr bitte in ein paar kurzen Sätzen. Hier könnt ihr erklären, warum genau dies ein Bug ist.
Die Label-funktion dient dazu den Bug besser zuzuordnen. In unserem Blog findet ihr eine Auflistung möglicher Labels und wann ihr sie verwenden solltet. Natürlich könnt ihr auch gerne neue Labelfunktionen hinzufügen, denn nicht jeder Bug ist gleich.
Die Einstufung eures Bugs erfolgt in den Kategorien Low, High und Critical. Beachtet bitte, dass critical bedeutet, dass der Fehler umgehend behoben werden muss, weil er eine Gefahr für das System darstellt, oder die Hauptfunktion der Seite schwer beeinträchtigt. Lies dazu im Blogeintrag zur Bugkategorisierung nach.

Zum Schluss gebt ihr den Browser an, auf dem ihr getestet habt und denkt daran eure Screenshots hochzuladen!

Hier nochmal das Bugformular in der Übersicht:

Tags: , , , , , ,

Avatar of anna

by anna

Bug Categories

19. Juni 2012 in Allgemein

 

Warum haben Bugs unterschiedliche Einstufungen?


Bug ist nicht gleich Bug: Es gibt große Bugs, es gibt kleine Bugs. Es gibt nette Bugs, es gibt fiese Bugs – um es kurz zu halten: Jeder Bug ist anders.

Eure Aufgabe ist es die einzelnen Bugs zu unterscheiden und in Kategorien einzuteilen. Dabei teilen wir die Bugs in drei Klassen auf: Low, High und Critical.

 

Was unterscheidet die einzelnen Kategorien voneinander?  

 

Der Unterschied liegt in der Schwere der Fehler und die Dringlichkeit diese zu beseitigen.

  • Low: Dieser Bug kann vom Kunden behoben werden. Es ist jedoch nicht schlimm, falls er das nicht tun sollte, da die Funktionalität der Seite bzw. des Programms nicht beeinträchtigt ist.
  • High: Dieser Bug sollte vom Kunden behoben werden.Dieses muss aber nicht sofort geschehen.
  • Critical: Dieser Bug muss sofort vom Kunden behoben werden.

Was ist bei der Klassifizierung zu beachten?  


Grundsätzlich müsst ihr euch bei der Klassifizierung eines Bugs in die Lage unseres Kunden versetzen und euch die Frage stellen:
Ist der Fehler so schwerwiegend, dass ich als Anbieter Kunden verliere?  

Konkret könnte das heißen:
Verliere ich Kunden, weil der Bestellprozess im Onlineshop nicht abgeschlossen werden kann? Kann ein Flug nicht gebucht werden?
Das fällt definitiv in die Kategorie „Critical“.
In die Klasse „Low“ wird dann ein kleiner Grafikfehler ganz oben links in der Ecke einer Homepage fallen. Vor allem, wenn dieser gerade mal einen Millimeter groß und kaum sichtbar ist.
Ist jedoch ein Firmenlogo vom Grafikfehler betroffen, könnte dies der Seriosität der Webseite schaden und kann vielleicht als „High” klassifiziert werden.
Leider kann für die richtige Einstufung der Bugs kein Allgemeinrezept gegeben werden, da die Bugs wie auch unsere Kunden zu verschieden und individuell sind – es ist also euer Feingefühl gefragt.
Noch ein kleiner Hinweis zum Schluss:  

 

Unser Kunde entscheidet letzten Endes über die Einstufung der Bugs und dementsprechend werdet ihr auch bezahlt. Down und Upgrades eurer eingereichten Bugs sind somit möglich und die endgültige Einstufung obliegt nicht unserer Hand.

Tags: , , , ,

Avatar of anna

by anna

Bug, Bug, Bug… Was ist eigentlich ein Bug?

19. Juni 2012 in Allgemein

 

Ganz einfach gesagt: Ein Bug ist ein Fehler im System.

Er kann auf Webseiten, in Programmen oder in Anwendungen auftauchen.

Dabei löst er jedoch bei allen Benutzern wie auch bei den Entwicklern das gleiche Gefühl aus – man ist sichtlich genervt.

Die Welt der Bugs ist bunt und vielfältig. So gibt es neben den klassischen Grafikfehlern oder fehlerhaften Verlinkungen eine breite Palette an anderen Fehlern, die die Funktionalität, Sicherheit oder andere Bereiche einer Webseite oder eines Programms beeinträchtigen.

 

Ein Bug kommt selten alleine…

So vielfältig sie in ihrer Art und Weise erscheinen, so vielfältig tauchen sie auch in ihrer Anzahl auf.

Auch wenn sich die Entwickler größte Mühe geben Fehler zu vermeiden und vorhandene Fehler zu finden und zu beheben, haben sie immer wieder das gleiche Problem:

Sie haben immer die gleiche Sicht auf das gleiche Programm. Sie achten häufig immer auf die gleichen Dinge und vernachlässigen dabei für sie „unwichtige“ Punkte, die aber für den Endverbraucher ein hohes Maß an Unbequemlichkeit bedeuten.

Deswegen brauchen wir eure Sicht auf das zu testende Produkt: Jeder von euch hat eine andere Vorgehensweise sich durch eine Menüführung durchzuklicken oder Sachen auf einer Webseite zu finden. Dadurch ist garantiert, dass sich auch kleinere, versteckte Bugs auffinden lassen.

 

Was gehört zu Rechtschreibung?

Sei es ein fehlendes Komma, eine verknotete Satzstellung oder die verschlafende Umstellung auf die neue Rechtschreibung: Fehler ist Fehler. Nur können diese Fehler natürlich nicht als gravierender Bug eingereicht werden. Sie sind manchmal äußerst störend, aber beeinträchtigen normalerweise nicht den Webseiten-Betrieb oder die Funktion eines Programms.

Alle Rechtschreib- oder Grammatikfehler sind daher unter “Rechtschreibung” einzureichen und mit einem Screenshot, sowie dem Label “Rechtschreibfehler” zu versehen.

 

Was gehört dann zu Usability?

Unter “Usability” werden eure Verbesserungsvorschläge hinsichtlich der Benutzerfreundlichkeit eines Produkts gesammelt. Diese gehören weder zu den Bugs, noch zur Rechtschreibung.

Hier könnt ihr also qualitativ hochwertige Kommentare einreichen, welche unserem Kunden bei der Verbesserung seines Produkts helfen können. Ein Usability Vorschlag ist also Kritik und Verbesserungsvorschlag in Einem.

Tags: , , , , ,

Avatar of thomas

by thomas

testCloud Academy: Test Cases

5. Juni 2012 in Allgemein

In diesem kurzen Video stellen wir euch die neue Test Cases Funktion vor. Ihr seht wie man einen Test Case bearbeitet und wie man einen Bug meldet.