Glauben Sie, es ist eine gute Idee für Softwareingenieure, einige Zeit als Qualitätssicherungsingenieure arbeiten zu müssen? [geschlossen]

12

Ich glaube es ist. Warum?

  1. Ich habe viele Software-Ingenieure getroffen, die glauben, dass sie den QS-Ingenieuren in gewisser Weise überlegen sind. Ich denke, es kann helfen, diesen Glauben zu löschen, wenn sie für einige Zeit die Arbeit eines QS-Ingenieurs machen und erkennen, dass es sich um eine einzigartige und wertvolle Fähigkeit handelt.

  2. Je besser ein Softwareentwickler in der Lage ist, seine eigenen Programme zu testen, desto weniger Zeitaufwand verursacht sein Code, wenn er den Rest des Softwareentwicklungszyklus durchläuft.

  3. Je mehr Zeit ein Software-Ingenieur damit verbringt, sich Gedanken darüber zu machen, wie ein Programm brechen kann, desto häufiger müssen diese Fälle bei der Entwicklung berücksichtigt werden, um Fehler im Endprodukt zu reduzieren.

  4. Die Definition von "vollständig" durch einen Softwareingenieur ist immer interessant ... wenn er Zeit als QS-Ingenieur verbracht hat, passt diese Definition möglicherweise besser zum Designer der Software.

Hinweis: Ich mache den obigen Vorschlag unter Berücksichtigung eines kleinen Zeitrahmens, da ich weiß, dass es definitiv ein Rezept ist, diesen Entwickler zu verlieren, wenn jemand in einer Position arbeitet, die nicht der Position entspricht, für die er eingestellt wurde.

Was denkst du alle?

Macy Abbey
quelle
1
Mein erster Job war die Qualitätssicherung. Ich hasste es, aber ich verstand WIRKLICH die Bedeutung der Qualitätssicherung.
Job
Ich habe die Kreativität hinter QA erst richtig eingeschätzt, als ich Glenford Myers 'Klassiker The Art of Software Testing gelesen habe .
Macneil
5
Ich habe viele Software-Ingenieure getroffen, die glauben, dass sie allen anderen auf dem Planeten in irgendeiner Weise überlegen sind ;-)
Steven A. Lowe
Zu wahr, Steven.
Macy Abbey
1
Ich würde vorschlagen, stattdessen zu fragen, ob es eine gute Idee für Softwareentwickler ist, ein paar Qualitätssicherungsaufgaben zu erledigen, anstatt zu glauben, dass eine nicht identifizierte Entität sie dazu zwingen wird.
David Thornley

Antworten:

13

1. Ich habe viele Software-Ingenieure getroffen, die glauben, dass sie den QS-Ingenieuren in irgendeiner Weise überlegen sind. Ich denke, es kann helfen, diesen Glauben zu löschen, wenn sie für einige Zeit die Arbeit eines QS-Ingenieurs machen und erkennen, dass es sich um eine einzigartige und wertvolle Fähigkeit handelt.

Ein gutes Software-Engineering hat einen Hintergrund in Bezug auf Qualität, einschließlich Tests, Metriken und Statistiken. Jeder, der irgendeine Art von Softwareentwicklung betreibt, sollte sich bewusst sein (wenn er nicht damit vertraut ist), den Quellcode auf dem neuesten Stand zu halten und effektive Testfälle zu erstellen / zu pflegen. Mit der Zeit würde ich vermuten, dass jeder Softwareentwickler die verschiedenen Facetten der Qualität verstehen würde - Codequalität, Portabilität, Wartbarkeit, Testbarkeit, Benutzerfreundlichkeit, Zuverlässigkeit, Effizienz und Sicherheit.

Softwareentwickler konzentrieren sich möglicherweise auf einen bestimmten Aspekt des Lebenszyklus - Anforderungsentwicklung, Architektur und Design, Konstruktion, Test und Wartung. Unabhängig von Ihrem Fokus (entweder als Job oder in der aktuellen Phase des Projekts) ist es jedoch wichtig, sich an die Qualität zu erinnern.

2. Je besser ein Software-Ingenieur in der Lage ist, seine eigenen Programme zu testen, desto weniger Zeitaufwand verursacht sein Code, wenn er den Rest des Lebenszyklus der Softwareentwicklung durchläuft.

Das könnte stimmen. Einige Probleme werden jedoch am besten später in der Entwicklung gesehen. Beispielsweise können Leistungs- und Effizienzprobleme erst bei der Integration auftreten. Gute, solide Codes und effektive Komponententests sind nur der Anfang. Qualität muss mit den Anforderungen beginnen und den gesamten Weg durch die Wartungsaktivitäten verfolgen.

3. Je mehr Zeit ein Software-Ingenieur damit verbringt, sich Gedanken darüber zu machen, wie ein Programm brechen kann, desto häufiger müssen diese Fälle bei der Entwicklung berücksichtigt werden, um Fehler im Endprodukt zu reduzieren.

Das ist eine absolut wahre Aussage. Andererseits liegt es auch an den Anforderungsingenieuren, sicherzustellen, dass keine Konflikte in den Anforderungen bestehen, und an den Architekten, dass der Entwurf tatsächlich die Anforderungen erfüllt, und so weiter. Jeder sollte versuchen, Löcher in seine Arbeit zu stechen und dann mit den entsprechenden Leuten zusammenzuarbeiten, um sie schön und fest zu verschließen.

4. Die Definition von "vollständig" durch einen Softwareingenieur ist immer interessant ... wenn er Zeit als QS-Ingenieur verbracht hat, passt diese Definition möglicherweise besser zum Designer der Software.

"Vollständig" kann nur an den Anforderungen gemessen werden. Entweder sind die Anforderungen erfüllt und das Projekt ist abgeschlossen, oder es gibt unvollständige Anforderungen und das Projekt ist nicht abgeschlossen. Jedes andere Maß an Vollständigkeit ist nutzlos.

Thomas Owens
quelle
Danke Thomas, das ist eine sehr informative und nachdenkliche Antwort.
Macy Abbey
6

Hier können Programmierer für ihren Code zur Rechenschaft gezogen und aufgefordert werden, ihre eigenen Fehler zu beheben. Das und ein Verlust von Bonus und / oder Job.

Nicht, dass diese Erfahrung nicht helfen würde, aber wie weit können Sie mit dieser Denkrichtung gehen? Technischer Support, Verkauf, Beta-Benutzer, die Toiletten schrubben (das wäre eine demütigende Erfahrung).

JeffO
quelle
Stimmt, Jeff, aber ich denke, der erste Ansatz bringt ihnen nicht unbedingt die Werkzeuge bei, die sie benötigen, um effizientere / robustere Programmierer zu werden. Es macht aber Druck, was gut ist.
Macy Abbey,
Einer der Nachteile dieses Ansatzes besteht darin, einen Programmierer für eine gewisse Zeit zu verlieren, eine Woche ... zwei Wochen, einen Monat? Und ich denke nicht, dass es eine gute Idee ist, sie Jobs machen zu lassen, die sehr wenig mit ihrem aktuellen Job zu tun haben ... (Schrubben der Toiletten: P)
Macy Abbey
6

"... müssen als QS-Ingenieure arbeiten ..."? Du machst es widersprüchlich oder bestrafend.

Ich bin ein Softwareentwickler. Ich betrachte es als Teil meiner Arbeit, auch ein QS-Ingenieur zu sein, obwohl wir eine QS-Abteilung haben. Es ist meine Aufgabe, Software zu liefern, die bestimmte Aufgaben erfüllt, und dazu muss ich Komponententests schreiben und sicherstellen, dass die Software diese erfüllt.

Ich bin in Partnerschaft mit unserer QA-Abteilung. Mein Ziel ist es, ihre Arbeit zu erleichtern, genauso wie es ihre Aufgabe ist, mir dabei zu helfen, mein Ziel zu erreichen, Software zu liefern, die das tut, was sie soll, und damit mein Leben leichter zu machen. Ich betrachte sie als meine zweiten Augen und als ein Sicherheitsnetz, genau wie ich meine Unit-Tests durchführe.

Ich entscheide mich für die Entwicklung von Software und möchte Software entwickeln. Wenn ein Manager zu mir käme und mir sagte, dass ich das nicht machen könnte und QA machen müsste, würde ich ihnen sagen, dass sie einen neuen Softwareentwickler UND eine QA-Person suchen müssen, weil ich dort nicht arbeiten werde. Ich bin anal, wie es mit meinem Code sein kann, aber der kreative Prozess und das Programmieren von Rätseln / Herausforderungen sind für mich extrem wichtig. Ich würde lieber wieder Gabelstapler fahren, wenn ich keinen Code schreiben kann, weil es für mich eine absolute Hölle wäre, in einem Unternehmensumfeld zu sein, in dem ich nicht kreativ sein und so herausgefordert werden kann, wie ich bin.

Im Allgemeinen klingen die Optionen, die Sie präsentieren, sehr widersprüchlich und ich frage mich, ob Sie wirklich schlechte Erfahrungen mit einigen schrecklichen Entwicklern gemacht haben. Meiner Meinung nach muss sich ein Entwickler IMMER der Qualitätsprobleme und der Tests bewusst sein und sollte stolz genug auf seine Arbeit sein, dass er diese erst dann als abgeschlossen ansieht, wenn sie in ihren Komponententests so strenge Tests besteht wie die offizielle QA-Abteilung. Wenn ich einen Kollegen hätte oder in einem Team technologisch führend wäre und einen Entwickler hätte, der eine gewisse Vorliebe für die Qualitätssicherung gezeigt hätte, würde ich ihn wegen einer Einstellungskorrektur abschieben. Wenn beide Seiten der Software Delivery-Medaille nicht zusammenarbeiten und als Team agieren können, liegt ein echtes Kulturproblem vor. Ich würde dort nicht arbeiten wollen und die Personalabteilung sowie das obere Management müssten informiert werden.

der Blechmann
quelle
Hallo Greg, ich habe die Frage an einen Softwareentwickler gestellt, der auf dem Gebiet neu ist und den Wert der Qualitätssicherung nicht versteht und der nicht viel Erfahrung mit der Entwicklung einer Reihe klar definierter Akzeptanzkriterien hat. Der Grund, warum ich mich für "muss" entschieden habe, ist, dass wie Sie sagten, ich glaube nicht, dass sich viele Softwareentwickler dafür entscheiden würden, als Qualitätssicherungsingenieur zu arbeiten (als ihre einzige Pflicht), weil sie sich eindeutig dafür entschieden haben, Softwareentwickler zu sein. Ich schätze und teile auf jeden Fall Ihre Sicht auf die Haltung und Beziehung eines wirklich guten Softwareentwicklers zur Qualitätssicherung.
Macy Abbey
Glauben Sie, dass ein neuer Software-Ingenieur als QS-Ingenieur Ihnen dabei helfen würde, den Punkt zu erreichen, an dem Sie sich gerade befinden?
Macy Abbey
1
Absolut nicht. Stellen Sie sicher, dass sie verstehen, wie Teams arbeiten. Entwickeln Sie eine Haltung der Eigenverantwortung für Probleme; Kultur eine offene Atmosphäre, die Menschen dazu ermutigt, in Ad-hoc-Teams zu arbeiten, um Probleme zu diskutieren und zu lösen. Zu viele Menschen und Unternehmen fördern Wissenssilos und die Einstellung "Wir gegen alle". Ehrlich gesagt, das "Wir gegen alle" muss innerhalb der Firmenmauern verschwinden, weil es allen weh tut.
der Blechmann
2
@Macy Abbey, eine Taktik, die in Betracht gezogen werden sollte, könnte darin bestehen, Entwickler mit dem QA-Team zusammenarbeiten zu lassen, um die Testszenarien zu entwickeln. Die Komponententests könnten zusammen geschrieben und entworfen werden, oder das QA-Team könnte ihre Tests zum Ordner "tests" hinzufügen, in dem der Entwickler Komponententests erstellt. Einige Leute denken, es sollte eine Trennung zwischen Entwickler und Qualitätssicherung geben, aber das fördert die Konkurrenz. Wenn beide Gruppen ihre Augäpfel benutzen und gemeinsam Tricks testen, können sie die Bugs und fehlenden Features möglicherweise noch schneller ausfindig machen.
der Blechmann
@ Greg Danke Greg, das klingt nach einer guten Taktik. Ich glaube, Sie haben mich überzeugt, dass eine Mischung aus anderen Taktiken besser ist als das, was ich ursprünglich vorgeschlagen hatte.
Macy Abbey
5

Programmierer dazu zu bringen, als QS-Ingenieure zu arbeiten, ist ein Rezept, um Ihre besten Entwickler zu verlieren. Programmierung und Qualitätssicherung erfordern unterschiedliche Fähigkeiten und Denkprozesse.

Es ist jedoch wichtig, dass Ihre Programmierer in der Lage sind, ihre eigenen Arbeiten zu testen und zu validieren, bevor sie an das QA-Team übergeben werden. Entwickler und QA haben Zugriff auf verschiedene Tools, Kenntnisse und Fähigkeiten. Die Entwickler müssen in der Lage sein, ihren Code nach unerwartetem Verhalten zu durchsuchen, Einheiten auf Randbedingungen zu testen, Thread-Code auf Race-Bedingungen zu prüfen usw. Das heißt, Tests aus Entwicklerperspektive.

QA führen ihre Tests aus der Benutzerperspektive durch. Das Denken wie verschiedene Arten von Benutzern, das Erfinden seltsamer Randfälle und das Reproduzieren obskurer Probleme sind QS-Fähigkeiten.

Michael Shaw
quelle
1
Dank Ptolemaios, ich mache diesen Vorschlag mit einem kleinen Zeitrahmen, da mir bewusst ist, dass es definitiv ein Rezept ist, diesen Entwickler zu verlieren, wenn jemand in einer Position arbeitet, für die er nicht eingestellt ist.
Macy Abbey
Es ist nicht nur so, dass sie nicht in einer Position arbeiten würden, für die sie eingestellt wurden, sie wären auch nicht in einer Position, die sie als ihren Beruf gewählt haben und für die sie zur Schule gegangen sind. Das ist ein großer Schlag ins Gesicht für viele Menschen, die ihr Herz in ihre Karriere stecken. Für diejenigen, die einen Job nur als Gehaltsscheck betrachten, ist das in Ordnung.
der Tin Man
@ Greg: Diejenigen, die für den Gehaltsscheck dabei sind, werden es auch nicht mögen. Ihr Lebenslauf wird mit X + 1 Jahren Software-Engineering wertvoller sein als X Jahre Software-Engineering und ein Jahr QS, zumindest zu einem frühen Zeitpunkt. Ganz zu schweigen davon, dass Sie sowohl Ihre QA-Mitarbeiter als auch Ihre Software-Mitarbeiter bezahlen müssen, da niemand für einen Gehaltsscheck bereitwillig eine Lohnkürzung akzeptieren wird.
David Thornley
Das setzt voraus, dass Sie an einem Ort arbeiten, an dem qualifizierte QA-Leute weniger verdienen als Entwickler. Ich weiß, dass einige Orte dies tun, aber es spiegelt nicht meine Erfahrung wider - wenn ich die Gehälter von Menschen kenne, sind sie im Allgemeinen gleichwertig.
Testerab
1
In den ersten Jahren als Programmierer hängt Ihr Gehalt stark davon ab, wie viele Jahre Programmiererfahrung Sie haben. Wenn Sie also 2 Jahre C # und 1 Jahr QA haben, erhalten Sie ein 2-Jahres-C # -Gehalt und kein 3-Jahres-C # -Gehalt.
Michael Shaw
3

Nicht unbedingt - sowohl Programmierer als auch Tester müssen unterschiedliche Fähigkeiten haben. Nur weil Sie ein guter Programmierer sind, heißt das nicht, dass Sie ein guter Tester sein können (viele Leute verstehen das nicht, aber Programmierer zu sein, qualifiziert Sie nicht automatisch als Tester).

Ein großartiger Tester muss wirklich teuflische Fähigkeiten haben, in der Lage sein, Dinge zu tun, für die die Software nicht entwickelt wurde, aber vom Benutzer erwartet werden kann, dass er sie in der realen Welt ausführt. Das erfordert Geschick, Geduld, die Fähigkeit zu erkennen, was wo schief gehen kann, ein Verständnis für die Mentalität des Benutzers und so viele andere Faktoren.

Beachten Sie, dass ich die Wörter Programmierer und Tester verwende - aber wenn Sie ein Software-Ingenieur sind und sich noch nicht entschieden haben, ob Sie Programmierer oder Tester werden möchten, dann umfasst es beide Dinge und daher sollten Sie zumindest Erfahrung in beiden haben in den ersten Jahren Ihres Lebens, bevor Sie die Entscheidung treffen.

Das bedeutet nicht, dass Sie einen erfahrenen Programmierer für eine Weile testen lassen, um ihm zu zeigen, wie hart die QS-Ingenieure arbeiten.

Roopesh Shenoy
quelle
True Roopesh, obwohl ich denke, dass es definitiv einen Schnittpunkt zwischen den beiden Fähigkeiten gibt, bei dem die Arbeit als QS für eine kleine Zeitspanne die Geschwindigkeit erhöht, mit der jemand seine Testfähigkeiten verbessert.
Macy Abbey
1

Hier sind einige potenzielle Probleme, die ich mit Ihrem Vorschlag sehe:

1) Wenn Sie vorschlagen, dass Sie neue Software-Ingenieure für eine kurze Zeit in die QA-Abteilung entsenden, hat dies dann nicht den gegenteiligen Effekt? - Sie gehen möglicherweise davon aus, dass Sie als Neuling die Qualitätssicherung übernehmen und nicht verstehen, was Sie tun - schließlich hat das bei ihnen auch so funktioniert.

2) Eine Zeit lang ein sehr schlechter Tester zu sein, wird ihnen nicht unbedingt etwas Wertvolles beibringen. Aber es könnte sie später unbelehrbar machen, weil sie davon ausgehen, dass sie jetzt alles über das Testen wissen , weil sie einmal 6 Wochen in einer Testabteilung verbracht haben.

3) Da sie offensichtlich nur für kurze Zeit dort sein werden und die QS-Abteilung dies weiß, ist es auch wahrscheinlich, dass sie nur relativ anspruchslose, einfache Aufgaben erhalten, die wenig Aufsicht oder Verständnis erfordern, die sie jedoch beschäftigen . Dies wird nur 1 und 2 verstärken.

4) Wenn Sie 1, 2 und 3 vermeiden möchten, wie können Sie Ihre Testabteilung davon überzeugen, dass es sich lohnt, eine enorme Menge an Energie in das Unterrichten und Überwachen von Personen zu investieren, die nicht einmal am Testen interessiert sind? (Ich kann Ihnen sagen, dass die Zusammenarbeit mit jemandem, der nicht für seine Testfähigkeit ausgewählt wurde, beängstigend viel Zeit und Energie in Anspruch nimmt . Sie bieten dem Testteam für einige Wochen keine zusätzliche Ressource, Sie Sie bitten sie, einen ihrer erfahrensten Leute für ein paar Wochen zu verlieren, während sie Ihren Neuling unterrichten.

Trotzdem finde ich Ihr allgemeines Ziel, das Testverständnis neuer Software-Entwickler zu verbessern, wirklich fantastisch. Ich denke, dass Gregs Vorschlag es jedoch mit größerer Wahrscheinlichkeit erreichen wird - bringen Sie Ihre Entwickler- und QA-Teams dazu, eng zusammenzuarbeiten, und arbeiten Sie daran, alle Hindernisse zwischen den Teams abzubauen. (Ich arbeite derzeit in einem Unternehmen, in dem Tester und Programmierer im selben Team arbeiten. Es ist wirklich großartig, und ich möchte nie wieder in separaten Teams arbeiten.)

Wenn Sie immer noch daran interessiert sind, dass Programmierer eine Pause in der Qualitätssicherung einlegen - hier ein Vorschlag: Gehen Sie mit gutem Beispiel voran. Geh zuerst zu dir. Machen Sie es vielleicht zu etwas, das Mitglieder Ihres Teams tun können, wenn sie bereits gut sind, und möchten diesen zusätzlichen Vorteil erzielen, indem Sie jede Woche ein wenig Zeit mit anderen Teams verbringen, die sich auf überlappende Bereiche spezialisiert haben - Test, DBAs usw. Wenn Wenn Sie es so präsentieren, haben Sie mehr Erfolgschancen.

testerab
quelle
0

Ich hatte eine Art Karriereweg, der umgekehrt zu dem ist, was man normalerweise sieht. Ich begann als Software-Support für wissenschaftlich anspruchsvolle Physik und arbeitete dann in der Schnittstelle von Architektur, Programmierung und Algorithmen für eine Computerfirma. Danach habe ich einige Jahre lang die Leistungsoptimierung eines wichtigen technischen Codes durchgeführt, aber selbst diese Arbeit ging zu Ende. Jetzt, da ich mich dem Rentenalter nähere, mache ich die QS mit dem gleichen Code. Es ist eine Kombination aus Herausforderung und Plackerei. Wir haben einen wirklich scharfen neuen Mann, der zu 100% an Bugfixes arbeitet, und ich arbeite viel mit ihm. Es ist eine herausfordernde Position, und man kann dabei viel lernen. An diesem Punkt ist mein Hauptinteresse an beruflicher Entwicklung für meine Zwillingsjungen, die Comp Sci College-Neuling sind. Ich habe also ein neues Interesse daran, Dinge zu lernen (oder neu zu lernen), die für ihre Karriere relevant sind, insbesondere angewandte Mathematik. Ich habe jetzt eine andere Perspektive, da ich mich mit QS / Validierung befasse, während es im vorigen Vierteljahrhundert um Geschwindigkeit, Geschwindigkeit, Geschwindigkeit um jeden Preis ging.

Omega Centauri
quelle
Diese Anekdote scheint keine Antwort auf die Frage zu enthalten.
Andrew Medico
-2

Das Testen von Software ist eher ein destruktiver als ein konstruktiver Prozess. Aber Programmierer denken konstruktiv an ihr Produkt, um sicherzustellen, dass das Produkt pünktlich und im Budget fertiggestellt wird. Wenn Softwareentwickler denken, dass sie ihr eigenes Produkt zerstören, wer wird dann als nächstes das Produkt bauen? Daher muss jeder Teil des Softwareentwicklungszyklus von den Personen ausgeführt werden, die in jedem Teil des Entwicklungszyklus zugewiesen sind. Wenn Sie sich mit zwei oder mehr Fachgebieten beschäftigen, ist es sicher, dass Sie bei keinem von ihnen perfekt sein werden. Tun Sie also eine Sache, entweder Programmierer oder Qualitätssicherung oder eine andere Option, und seien Sie dabei perfekt.

Panjiyar Rahul
quelle