Wenn Sie zufällig den Film „Alles auf einmal“ gesehen haben, hier ist seine monatliche IT-Version. Wir haben ALLES über Qualitätssicherung und Softwareentwicklungstrends von ÜBERALL zusammengetragen, damit Sie ALLES AUF EINMAL lesen können.
Wir haben auch ein paar tolle Neuigkeiten. Wir haben Ihr Feedback erhalten, wie wir die Kommunikation in einem professionelleren Umfeld einfacher und bequemer gestalten können, ohne dabei den informellen Charakter zu verlieren. Deshalb haben wir beschlossen, eine LinkedIn-Gruppe zu gründen, die sich mit Software Testing Talks beschäftigt. Jetzt müssen Sie nicht mehr bis zum Beginn des nächsten Monats warten, um eine weitere Ausgabe von STT zu erhalten. Holen Sie sich diese sofort aus der Gruppe und diskutieren Sie alle wichtigen Ereignisse mit Gleichgesinnten.
In diesem Zusammenhang möchte ich Sie auch daran erinnern, dass aqua im Juni eine Reihe neuer interessanter Funktionen vorgestellt hat, wie die Massenausführung von Testfällen, KPI-Warnungen, neue Synchronisierungen und vieles mehr. Um zu sehen, welche Funktionen und wie sie funktionieren, lesen Sie unseren vollständigen Artikel von unserer Produktmanagerin Kate Hornysh.
Zurück zu unserer Zusammenfassung, was uns vorgelegt wurde:
- Ist dieser Fehler groß genug?
- Wir sprechen nicht genug über das Onboarding von QS-Spezialisten
- Login – Logout oder der typische Tag eines QS-Testers
- Es macht Spaß, Tester zu sein!
- Was ist der Unterschied zwischen Qualitätssicherung und… Qualitätssicherung?
- 4 Gründe, warum Tester Freiheit statt Kontrolle brauchen
- Handschrift in der Qualitätssicherung
Ist dieser Fehler groß genug?
Die Einteilung in verschiedene Fehler kann selbst für erfahrene Tester überwältigend sein. Stellen Sie sich nun vor, Sie sind ein Junior-Tester und Ihr QS-Leiter sagt Ihnen, dass der Fehler, den Sie gerade gefunden haben, eigentlich kein Fehler ist. An meiner Stelle wäre ich wirklich verwirrt. Aber die Wahrheit ist so, dass nicht jeder gefundene Fehler ein Fehler ist. Warum? Hier ist ein guter Thread zu diesem Thema und eine bessere Antwort:
Wenn es kein Fehler ist, wie soll man es dann nennen?
“Meine Entwickler haben mich gebeten, den Begriff ‚Bug‘ für den Fall zu reservieren, dass ich einen Test nicht bestanden habe, weil die Funktionalität nicht funktioniert.“ Ich stimme dem zu. Aber wie nenne ich dann all die anderen Dinge, die behoben werden müssen – wie Grammatikfehler, UX-Probleme, Validierungsfragen usw.?
Als Referenz verwenden wir Azure Devops, und ich melde Probleme mit einer Anforderung als untergeordnete Aufgaben zu dieser Story. In einer untergeordneten Aufgabe schreibe ich also „Fehler: xyz mit unterstützenden Informationen und schicke ihn dann zur Behebung an die Entwicklung zurück.“
Ich denke, diese Antwort ist wahrscheinlich die beste von allen:
>>> sehen Sie sich diesen Thread in der Reddit-Community r/softwaretesting an
Hier ist ein anderer Thread mit einer ähnlichen Anfrage und der Frage, ob Grammatikfehler als Bugs angesehen werden sollten:
Bugs vs. Stilfragen vs. Vorfälle
“Hintergrund: Ich habe vor Kurzem den Beruf gewechselt, um bei einem Unternehmen, das 2 Websites (hauptsächlich Saas) hat, als QS zu arbeiten. Ich bin der einzige QS für 7 Entwickler, die auf die Teams verteilt sind. Als einziger QS habe ich keinen Mentor, der mir die Best Practices der korrekten QS beibringt, also lese ich alles, was ich finden kann, habe aber immer noch das Gefühl, dass ich wahrscheinlich etwas verpasse. Das Unternehmen verwendet Azure Dev Ops, bei dem ich manuelle Testfälle für jede Story schreibe, während die Entwickler den Code schreiben. Dann teste ich jede Story.“
Frage: Ich führe einen Test durch und stelle fest, dass er zwar funktional die Akzeptanzkriterien erfüllt, aber Styling-Probleme aufweist (z. B. stimmt die Farbe des Rahmens nicht mit einer anderen Stelle der Seite überein). Würde dies im Sprint als Fehler protokolliert werden?
Was ist mit Grammatikproblemen (z. B. Zeichensetzung)? Würde eine Geschichte dadurch durchfallen? Entscheiden Sie oder PO, ob es jetzt oder später behoben werden muss? Nennen Sie es einen Fehler oder gibt es eine bessere Terminologie?
Wie wäre es, wenn sich etwas seltsam verhält, das mit der Geschichte zusammenhängt, aber kein Akzeptanzkriterium ist. Vielleicht verlangt die Story, dass ein Kästchen angekreuzt wird, und es wird auch angekreuzt, aber es gibt eine seltsam lange Verzögerung. Nennen Sie alle diese Fehler und protokollieren Sie sie im Sprint? Oder übergehen Sie die Story? Oder trifft jemand anderes diese Entscheidung für Sie?
Ich schätze, ich versuche hauptsächlich herauszufinden, was meine Entscheidung im Vergleich zu den Entwicklern und dem PO ist, und ich versuche, dabei den richtigen Fachjargon zu verwenden.”
Aus meiner Erfahrung heraus fand ich diese Antwort am relevantesten. Erstens sollten Sie immer mit Ihrem Team besprechen, wie Sie entdeckte Probleme kategorisieren. Und zweitens sollten Sie sich eigene Tags für die Fehler ausdenken, die Ihnen bei der Navigation durch den Prozess helfen:
>>> sehen Sie sich diesen Thread in der Reddit-Community r/softwaretesting an
Tipps: Wenn Sie aqua ALM verwenden, können Sie den Typ Ihrer Fehler über die Funktion „Benutzerdefinierte Felder“ definieren.
Wir sprechen nicht genug über das Onboarding von QS-Spezialisten
Es ist nicht das erste Mal, dass ich Beschwerden über mangelndes Onboarding für QS-Tester höre. Was sie damit sagen wollen, ist, dass die Arbeitgeber einem in der Regel sofort etwas zum Testen geben. Man hat keine Gelegenheit, in das Produkt einzutauchen, die Dokumentation zu studieren oder sogar sein Team kennenzulernen. Ich finde das ziemlich unfair. Seit jedoch immer mehr Tester offen über dieses Problem sprechen, scheint es eine Tendenz zu geben, die Situation zu ändern.
Onboarding neuer QS-Teammitglieder und wie man sie zum Erfolg führt
“Ich arbeite für ein Startup-Unternehmen, das kürzlich von einem viel größeren Unternehmen übernommen wurde (wir werden als ‚unabhängiges‘ Unternehmen oder vielmehr als Abteilung des übernehmenden Unternehmens weitergeführt). Mit anderen Worten, wir bekommen mehr Geld, aber wir haben immer noch die Kontrolle darüber, wie es mehr oder weniger ausgegeben wird. Wir werden unser Team in jeder Hinsicht aufstocken, einschließlich weiterer QS-Ingenieure. Zum jetzigen Zeitpunkt bin ich die ranghöchste Person im QS-Team, aber ich bin noch dabei, meine Rolle zu lernen, und habe keine Erfahrung mit der Verwaltung und Einarbeitung neuer Teammitglieder. Derzeit habe ich einen Interim-QS-Manager, der eigentlich ein Mitglied des Entwicklungsteams ist. Dieser Entwickler hat 20 Jahre Erfahrung in der Softwarebranche und hat in der Vergangenheit mit QS-Teams gearbeitet. Er gibt mir Hilfestellung, kann aber einfach nicht alle schweren Aufgaben bewältigen und gleichzeitig mit seiner Arbeitsbelastung Schritt halten. Er hat mich gebeten, zu dokumentieren, was ich an einem bestimmten Tag mache. Ich habe keinen formalen Prozess. Ich habe Dinge, die ich mache, aber ehrlich gesagt habe ich keinen guten strategischen Ablauf für meine Arbeit. Ich brauche nicht unbedingt Hilfe dabei, wie ich den Leuten sagen kann, was ich mache, da ich der Einzige bin, der das weiß. Ich möchte wissen, welche Informationen für Neueinsteiger am hilfreichsten sind. Auch ich bin ein Neueinsteiger, aber ehrlich gesagt war es jedes Mal, wenn ich eine neue Stelle in einem neuen Unternehmen angetreten habe, ziemlich dürftig, weil ich in der Regel der erste QS bin, den das Unternehmen je eingestellt hat, daher hatte ich noch nie eine wirklich ausführliche Einarbeitung für QS-Ingenieure, wo auch immer ich bisher gearbeitet habe.
tl;dr – Welche Informationen über die Unternehmen, für die Sie gearbeitet haben oder arbeiten, waren am Tag 0-1 am hilfreichsten und vorteilhaftesten zu wissen, die Sie in Bezug auf ein reibungsloses Onboarding, das Verständnis des Systems/SDLC des Unternehmens oder irgendetwas dazwischen am weitesten gebracht haben?”
Leider hat dieser Thread noch keine umfassende Antwort erhalten, aber es ist eine gute Gelegenheit für Sie, es zuerst zu machen.
>>> Sie können Ihre Meinung in diesem Thread r/softwaretesting mitteilen
Login - Logout oder der typische Tag eines QS-Testers
Ich glaube, es gibt eine typische Routine für alle Tester auf der ganzen Welt, mich eingeschlossen. Meistens ist es so, dass man sich bei allen Programmen anmeldet, seine E-Mails abruft, eine Besprechung hat und sich dann aus all diesen Programmen abmeldet. Für einige Tester sieht ihr typischer Tag jedoch etwas anders aus als für mich.
Wie sieht ein typischer QS-Tag in Ihrem Bereich aus?
“Ich bin seit etwa einem Jahr in der Qualitätssicherung tätig und bin mir nicht sicher, ob das eine gute Lösung ist. Ich frage mich nur, was ich von der Anfangs- bis zur Führungsebene in verschiedenen Bereichen erwarten kann.”
Und hier sind Beispiele für die untypische (oder vielleicht zu typische) Routine einiger Tester:
>>> sehen Sie sich diesen Thread in der Reddit-Community r/QualityAssurance an
Was ist der Unterschied zwischen Qualitätssicherung und… Qualitätssicherung?
Dies ist definitiv eine laufende Diskussion. Wir alle wissen, dass es verschiedene Arten von Tests, Techniken und Methoden gibt, aber es wird nicht allzu viel über die Arten der Qualitätssicherung im Allgemeinen gesagt. Kann die Bewertung der Arbeit von Callcentern als QS angesehen werden? Ich weiß es ehrlich gesagt nicht. Basierend auf der Hauptdefinition von Wikipedia wahrscheinlich ja: „QS ist die systematische Anstrengung, die unternommen wird, um sicherzustellen, dass das an den Kunden gelieferte Produkt den vertraglichen und anderen vereinbarten Erwartungen des Kunden in Bezug auf Leistung, Design, Zuverlässigkeit und Wartbarkeit entspricht.“
Menschliche QS Callcenter vs. technische QS-Codierung?
“Ich bin ein wenig uninformiert – ich bin in der Qualitätssicherung eines Callcenters tätig und muss die Qualität der Service-Kollegen in meiner Abteilung auf der Grundlage ihrer Interaktion überprüfen und benoten. Was unterscheidet diese Art der Qualitätssicherung von der QS, die ich auf dieser Plattform sehe und die nur aus Codierung zu bestehen scheint? Ich versuche, mehr über die Codierungsseite zu erfahren, aber die Stellenbeschreibungen scheinen alle so vage und beschreibend zu sein? Kann mir jemand einen Hinweis geben? Ich möchte mehr über QS für Menschen lernen…”
Diese Antwort bestätigt meine Theorie und die nächste Antwort gibt einen guten Einblick, warum wir Tester oft „QS-Ingenieure“ und nicht nur „QA-Tester“ nennen:
>>>sehen Sie sich diesen Thread in der Reddit-Community r/QualityAssurance an
Es macht Spaß, Tester zu sein!
Wissen Sie, ich bin kein großer Fan davon, mich über die Langeweile eines Jobs zu beschweren. Ich glaube, dass man in jeder Art von Arbeit etwas Faszinierendes und Unterhaltsames finden kann. Besonders, wenn wir über das Testen sprechen — man kann immer etwas Neues finden 🙂 Und ich stimme ihm, es kann manchmal langweilig sein, aber nehmen Sie „den Spaß an einigen ‚explorativen‘ Sitzungen Zeit.“
>>> Weitere Antworten finden Sie hier
Ich bin sehr stolz auf mich, weil ich zufällig zwei sehr coole Threads auf Twitter gefunden habe.
4 Gründe, warum Tester Freiheit statt Kontrolle brauchen
Mikromanagement bringt nie etwas Gutes in die Arbeitsumgebung, aber aus irgendeinem Grund ist diese Praxis immer noch vorhanden. Besonders auffällig ist dies in der Gemeinschaft der Tester. Ich habe immer wieder von Misstrauen seitens des Managements gegenüber der von ihnen geleisteten Arbeit gehört. Und ich stimme wirklich mit allen Gründen in diesem Beitrag überein, warum es so wichtig ist, seine Mitarbeiter nicht zu sehr zu kontrollieren.
>>> Schauen Sie sich diesen Thread hier an
Handschrift in der Qualitätssicherung
Zahlreiche Studien zeigen, dass man sich Informationen beim Lernen am effektivsten merken kann, wenn man sich Notizen in Notizbüchern macht. Ich werde nicht ins Detail gehen und nur auf den Artikel verweisen, aber diese Methode steigert die Gedächtnisleistung des Gehirns. Und wie die Praxis zeigt, eignet sich diese Methode hervorragend für Lerntests. Übrigens ist es auch sehr hilfreich, wenn Sie bei echten Prüfungen Ihre eigenen Notizen verwenden. Wenn man zu faul ist, sich eigene Notizen zu machen, kann man die verwenden, die Lisi gemacht und auf ihrem Twitter gepostet hat. Ich habe ehrlich gesagt ein paar für mich behalten.
>>> Alle handgeschriebenen Beiträge können Sie in diesem Twitter-Thread hier sehen
Ich hoffe, dass Ihnen unsere Juni-Auswahl an Vorträgen zum Thema Softwaretests gefallen hat.
Treten Sie der LinkedIn-Gruppe „Software Testing Talks“ und der Reddit-Community „r/softwaretestingtalks“ bei, um unsere monatlichen Diskussionslisten direkt in Ihren Feed zu erhalten.
Ich würde mich auch über Ihr Feedback, Ihre Vorschläge oder Ideen zu den ‚Software Testing Talks‘-Blogs freuen. Zögern Sie nicht, mich auf Linkedin zu kontaktieren. Lassen Sie uns die Gemeinschaft der Tester vergrößern!
