Wie kann sichergestellt werden, dass sich Entwickler keinen Code einschleichen, der nicht Teil der Anforderungen ist?

Abgesehen von Code-Reviews durch einen anderen Entwickler und indem Sie darauf vertrauen, dass Ihre Entwickler nichts Schändliches oder Dummes tun, gibt es eine Möglichkeit, sicherzustellen, dass ein Build bei der Freigabe für die Produktion oder sogar QA keinen zusätzlichen Code enthält, der nicht vorhanden ist Teil der zugewiesenen Anforderung?

Automatisiertes Testen. Es wird nicht sichergestellt, dass sich versteckte Funktionen in Ihren Code einschleichen, aber Sie werden sicherstellen, dass das, was gerade funktioniert, nicht kaputt ist.
Ich rieche ein XY-Problem. Sie haben Problem X und denken, dass Y es lösen wird, aber Sie sind sich nicht ganz sicher, wie Sie Y lösen sollen. Sie fragen uns also nach Y, aber Ihr eigentliches Problem ist X. Was ist Ihr X? Was ist das eigentliche Problem, das Sie zu lösen versuchen?
Geht es um Vergoldung?

Antworten (5)

Es gibt eine Menge, was Sie tun können, um sicherzustellen, dass der Code das tut, was er tun soll, aber abgesehen davon, dass Sie den Leuten vertrauen, die ihn entwickeln (einschließlich ihrer Prüfer), gibt es im Grunde keine Möglichkeit, sicherzustellen, dass er nicht mehr tut .

Aber auch in jedem anderen Job kommt es auf dieses Vertrauen an. Auf einer gewissen Ebene muss man den Menschen vertrauen. Wenn Sie dies nicht können, suchen Sie sich andere, denen Sie vertrauen können .

Die Verwendung eines Behavior Driven Development (BDD)- oder Acceptance Test Driven Development (ATDD)-Ansatzes bedeutet, dass der Code selbstdokumentierend ist. Die Einführung von Funktionalität über die ursprünglichen Anforderungen hinaus wäre also für jeden offensichtlich, der auf die Codebasis achtet.

Was einen „zusätzlichen Code“ ausmacht, ist eine viel schwierigere Frage. Es ist durchaus möglich, dass Code hinzugefügt wird:

  • Zur indirekten Unterstützung der Anforderungen (z. B. Helferklassen)
  • Refactoring und Verbesserung der Qualität der Codebasis
  • Um die Erweiterbarkeit des Codes sicherzustellen
  • Umgang mit nicht-funktionalen Anforderungen (Leistung, Sicherheit usw.)

Nur jemand, der eng mit dem Entwicklungsteam verbunden ist, wird wahrscheinlich die Bedeutung des gesamten hinzugefügten Codes verstehen.

Unerwünschte Funktionen können zu einem erheblichen Sicherheitsrisiko für Software werden. Das Fehlen von Architektur, Design, formalen Anforderungen, Spezifikationen, Testfällen und Infrastruktur kann aus einem harmlosen Osterei eine massive Datenschutzverletzung machen. In einigen Organisationen ist dies ein Entlassungsdelikt.

Eine Codeüberprüfung wird empfohlen, ist jedoch für größere Anwendungen mit begrenztem Budget nicht ausreichend. Positives Testen, wie es von den meisten QA-Testern praktiziert wird, wird es schwer haben, unerwünschte Funktionen zu identifizieren. Eine solche Funktionalität fehlt per Definition in den Softwarespezifikationen oder resultierenden Testfällen.

Statische Codeanalyse (SCA wie Fortify, Veracode usw.) erkennt „toten Code“, d. h. Code, der während der Datenflussanalyse nicht ausgeführt wird. (Dies geht weit über das Kompilieren hinaus.) Anschließend können Sie die Ergebnisse überprüfen, um festzustellen, was passiert und was zu tun ist. SCA findet auch andere Bedenken, die ebenso schwerwiegend sein könnten.

Dynamische und integrierte Codeanalysen wie Fuzzing könnten unerwünschte Funktionen in der Anwendung erkennen.

Um diese Frage produkt-/projektunabhängig zu beantworten, darum geht es bei den Qualitätsprozessen, insbesondere der Qualitätskontrolle. Produktinspektionen vor der Lieferung, um zu überprüfen und zu validieren, dass sie die Anforderungen und Lieferkriterien erfüllen. Dabei sollte es keine Rolle spielen, ob es sich bei dem Produkt um eine IT-Lösung, ein umgestaltetes Badezimmer oder eine Eiswaffel handelt. Inspizieren Sie das Produkt, üben Sie es aus, verwenden Sie eine Checkliste und unterzeichnen Sie es oder nicht.

Ich habe verstanden, dass Sie nach einem Entwicklungsprozess Ausschau halten, bei dem im Code keine zusätzlichen Funktionalitäten gefordert werden sollten, außer denen, nach denen gefragt wird.

Lassen Sie mich versuchen, hier einen einfachen Ansatz aufzuschreiben

  1. Anforderungs-Workshop – Sobald das Anforderungsdokument vom Kunden abgezeichnet wurde, vereinbaren Sie ein Anforderungs-Workshop-Meeting mit dem Anforderungsanbieter / IT-Experten (Entwickler) / Testingenieur – Dies trägt dazu bei, sicherzustellen, dass es ein gemeinsames Verständnis mit drei Interessengruppen gibt

  2. Arbeitsstrukturplan – Richten Sie nach dem Anforderungsworkshop eine Phase für den IT-Experten ein, um eine Arbeitsstrukturstruktur für die gegebene Anforderung bereitzustellen und vom Prüfer überprüft zu werden – Dies hilft dem IT-Experten, sich auf die Anforderung zu konzentrieren und Abhängigkeiten zu analysieren.

  3. Testszenarien – Richten Sie nach dem Anforderungsworkshop eine Phase für den Testingenieur ein, um Testszenarien bereitzustellen und vom Anforderungsanbieter überprüft und abgezeichnet zu werden. Die gleichen Testszenarien werden von IT-Experten im Rahmen von Unit-Tests ausgeführt - Dies hilft allen Teams, sich einig zu sein

Am besten,