Stefan's Bastelkiste

Some hardware test run very long, like 2 000 000 cycles or more in reliability or life tests. Obviously these tests run for months and have to be monitored. It's not nice to loose 10k cycles because one of the units decided to stop for some reason on Friday@1705h. Or one unit stopped 10 min after the one manual check a day (because normally they run for weeks without a problem).

The classic way is to do check all the units manually and maybe several times a day too and even on weekends. This is kind of time consuming since you can easily have like 20 units running at a time and to be honest it's not that interesting to do too.

But if you happen to have a nice interface to ask the units for their states and even give them commands to do stuff e.g. some XML based SSH network connection, you can automate a lot of this checking.

And with some additional coding you can get

• a nice daily status email
• a web page with the current status (updated every 30 min, we do not want to stress the units too much)
• an emergency email on Friday@1730h with logs of the troubled unit so you can decide if you should do a remote check and just restart something or have to return to the office or wait until Monday because it's completely burned down.

This saves time which can be spent on different (more challenging) tasks.

Test Objekte sind die Firmware und teilweise Hardware der verschiedenen hergestellten Varianten der LTO Tape Libraries für diverse Hersteller. Die Bandbreite reicht von 1U Geräten mit 8 Bändern und 1 Laufwerk bis zu 7x6U Stacks mit 560 Bändern und 42 Laufwerken. Diese Datenspeicher haben die unterschiedlichsten Schnittstellen und zahlreiche Funktionen.

Schnittstellen:

• SCSI, über Fiber Channel und SAS
• Remote Management Interface (Web Page), über Netzwerk für Konfiguration, Steuerung und Status
• Operator Control Panel, Benutzerschnittstelle direkt am Gerät für Konfiguration, Steuerung und Status
• REST, für Konfiguration, Steuerung und Status z.B. in der Produktion oder Monitoring
• Hersteller spezifische Schnittstellen
• Remote Test Interface, für Test Automation (SSH/Serial)
• Neuere Modelle basieren auf Embedded Linux oder älter auf Nucleus RTOS.

Funktionen:

• Hauptfunktion ist der Zugriff auf die Bänder per SCSI für Backup Application und der per SCSI (Backup App) gesteuerte wechsel der Bänder je nach Konfiguration z.B. tägliches oder monatliches Backup, Kapazitätsgrenzen einzelner Bänder.
• Daten Verschlüsselung
• Partitionierung der Hardware in logische Libraries z.B. eine logische Library per Abteilung
• Benutzermanagement mit verschieden Zugriffsebenen, lokal oder LDAP
• Status Monitoring, aktiv per SNMP traps und Email oder passiv per lokalen Logs, SNMP, rsyslog,CVTL
• und vieles mehr

Aufgaben als Tester:

• Erstellen von Test Cases basierend auf Requirements und Spezifikationen, (Helix ALM)
• Mehrstufiges Review von Test Cases von anderen Team Mitgliedern, (Helix ALM)
• Automatisierung von Test Cases in Abhängigkeit von Komplexität und wahrscheinlicher Wiederholungsfrequenz. (Robot Framework, RIDE, Selenium)
• Durchführung von Smoke-, Acceptance-, Regressions-, Nicht Funktionalen- und Funktionalen-Test, Dokumentation der Ergebnisse
• Im Fehlerfall Analyse und Dokumentation. (Helix ALM)
• Retest von behobenen Fehlern
• Erweiterung der Testmöglichkeiten der Firmware durch Entwicklung von Keyword Libraries für Robot Framework. (Python, Eclipse, Visual Studio Code)
• Qualitätssicherung der automatisierten Test und Robot FW Libraries durch Code Review (SSCM)
• Unterstützung lokalen und internationalen Test Teams

Unterstützung externer Test Labore ( EMV, Shock & Vibe)

• Organisation, Aufbau und Konfiguration der für den Test erforderlichen Geräte (Server, Library, Drives)
• Erstellung der Dokumentation des Aufbaus
• Erstellung der Anleitungen für die benötigten Operationsmodi des Testaufbaus
• Unterstützung der externen Tester per Fernwartung und vor Ort

Aufgaben für die Administration und Überwachung aller Test Umgebungen des Test Centers

• Bereitstellung und Konfiguration der Netzwerk Infrastruktur
• Bereitstellung der Server und Services mit unterschiedlichen Konfigurationen u.a.
  • Active Directory
  • File-Server (Windows, Samba)
  • FTP-Server
  • Email-Server (Postfix, Exchange)
  • LDAP-Server (OpenLDAP, Active Directory)
  • HTTP (Apache, Lighttpd)
  • rsyslog
  • Kerberos
• Bereitstellung von virtuellen Windows Desktops mit Test Tools (Windows 7-10, Webbrowser in verschieden Versionen)

Projekte:

• Unterstützung von Kollegen durch Entwicklung von neuen grafischen Test Tools (Python, wxPython, tkInter) und Weiterentwicklung bereits existierenden grafischen Test Tools (C#) nach ihren Anforderungen.
• Optimierung der Reliability und Life Tests durch Entwicklung von automatischen Monitoring und Reporting Tools (Python)
• Automation vom Reliability Tests durch Entwicklung der Anbindung des Prüflings und einer Siemens Logo (SPS)
• Anbindung von physikalischen Benutzer Interfaces an die Test Automation, durch Entwicklung eines Prototypen des Hardware Interfaces, des REST Interfaces und der Robot Framework Library (Python, Raspberry pi)
• Aufbau kostengünstiger langzeit Überwachung von Temperatur und Video des Test Labors basierend auf Python, SNMP, Raspberry Pi

As you may know the to be tested software can depend on external service like SMTP or LDAP. Using the production environment is not the best idea, since there are very different goals on a goal sheet for an IT-guy and a tester.

Therefore someone (me) has to take care of it and provide all the required servers, desktop, services and tools.

To test our tape libraries we need e.g. SCSI, Email-, LDAP-, HTTP, CA-, vendor specific encryption key server like ESKM or SKLM, Active Directory, file servers and data to actually backup for the system integration with different Backup software vendors..

Almost every service can have a multitude of different configurations and performance for most of these systems is not the highest priority or if you choose the right version (Postfix vs. Exchange) they do not need a lot of resources.

A good way to share your certainly limited resources is virtualization.

This way it is easy to run like 6 Linux email servers with different security configuration with 1.5 GB RAM and 10 GB HDD including web mail. Others like the key servers need Windows and min 4GB RAM and you need like 3 Version and replication and and and... Or you need different version of IE or FF or Chrome

VMware, KVM, Xen are your friends.

Another big benefit of virtual machines are snapshots, you have a setup working server/desktop with all the needed tools an services. Freeze it with a snapshot and when a tester has managed to break it, simply reset it and it's working again.

Currently I'm a Software Test Engineer

Our test team is testing these tape libraries

Therefore I write, review and execute manual and automated tests case. These tests cover interfaces like web, REST, SCSI and some proprietary once. For the tests we need an environment which I do manage too.

For automation we use mainly Robot Framework, since the software we test runs on specialized hardware I had to extend robot framework with libraries for our libraries So I had to start wirte them myself and soon was joined by other team members. Now we have about 40 libraries with a lot of keywords, maybe 500-1000. And of cause we have to adapt and expand them continuously since there is always a new feature and changes in the next release.

Having these libraries made it possible to easily write some tools to make tedious tasks faster, more reliable and last but not least simpler for the testers. E.g. sending status mails around or collecting logs of long term reliability and live tests or just automate the constantly reoccurring task with 9 steps which has to be done for every second test case.