צה"ל צה"ל כבר באיםYou're in the army now

מדי פעם, כשאני שוקל את האפשרות של רילוקיישן ותוהה אם אני באמת רוצה להתחיל להתאמץ כדי לגרום לזה לקרות, אחד השיקולים הראשונים שקופצים לצד של "בעד" הוא המילואים. העובדה שצו מילואים יכול להגיע בכל זמן נתון ובהתראה די קצרה להחזיר אותי לתקופה הכי גרועה שהייתה לי בחיים (ונקווה שלא תהיינה גרועות ממנה) מכבידה על החיים שלי באופן הרבה יותר משמעותי מאשר הייתי רוצה.

בכל מקרה, בדיוק הייתי עכשיו במילואים. ומה שאני עושה במילואים מכריח אותי לעבוד עם מערכת צי"ד. למרות שהיו מגוון גורמים מעכבים, כמו מחסור בשעות שינה, העובדה שלא יכולתי לשבור יותר מדי דברים וכמה משימות אחרות שהייתי צריך לעשות, לתת לי לשחק עם תוכנה גורם לי לחשוב על איך צריך לבדוק אותה. 

מטבע הדברים, בבלוג פומבי אני לא הולך להיכנס לפירוט של הפונקציות השונות, כי אין לי מושג ירוק מה מסווג ובאיזו רמה, כך שאשאר עם מה שניתן למצוא באינטרנט גם בלעדי. במקום לדון בתכונות ספציפיות, אני רוצה לציין דבר אחד אליו שמתי לב - הדרישות שלי ממערכת כזו, כמו גם סדר העדיפויות, שונה לגמרי מאשר מה שאני רגיל אליו במערכת איתה אני עובד בחיי היומיום. לכן, השאלה עליה אנסה לענות כאן היא "מה הם הדברים שחשוב לבדוק כשניגשים לתכנן בדיקות למערכת ניהול קרב?". הרשימה ארוכה להחריד, והבחירה שלי אינה היחידה (למעשה, לפני שאתם ממשיכים, נסו לחשוב - מה היא הרשימה שלכם?) אבל להלן עיקרי הדברים: 

• פשטות - במערכת ישתמשו הרבה מאוד חיילים, רובם המכריע אינם גאוני מחשבים, ולרובם המכריע יש משימות לא פשוטות גם ככה. אם הם יצטרכו להשקיע יותר מדי זמן במערכת הזו, הביצועים שלהם לא ישתפרו ולמעשה המערכת כולה נכשלת. 
• עמידות - אפשר לבנות מערכת מדהימה, אבל צריך לזכור שחלקים נרחבים של המערכת יסבלו מתנאים קשים - בעיקר טלטולים, גשם ואבק, אבל סביר להניח שמדי פעם הם יספגו מכה מנשק שסוחב חייל. 
• יעילות - המערכת צריכה לשפר את יכולות החיילים שמשתמשים בה ולאפשר להם לקבל החלטות נכונות יותר בצורה מהירה יותר. 
• סינון מידע - בשדה קרב יש המון מידע - כל צוות וכל יחידת אויב מייצרים לפחות נקודת מידע אחת, תוכניות, פקודות, ניתוחי שטח, תחומי אחריות, אזרחים והשד יודע מה עוד. ברוב המקרים, לכל אחד יש צורך במידע אחר - סוללת התותחים צריכה לדעת לאן מותר לה לירות ולאן אסור, גם מפקד גדוד וגם מפקד אוגדה צריכים לדעת אילו כוחות נמצאים בגזרה שלהם ואיפה נמצא האויב, אבל בעוד שמג"ד צריך לדעת הכל עד לרמת הצוות הבודד, האוגדונר צריך תמונה כללית יותר, יחידות המרפאה צריכות לדעת איפה נמצאים הפצועים, מה מצבם ואיך ניתן להגיע אליהם ולכל יחידה או תפקיד יש צרכים אחרים מהמערכת. כדי לעבוד באופן יעיל, המערכת חייבת לאפשר למשתמשים בה לסנן את המידע המיותר בקלות. 
• אבטחת מידע - כמו תמיד, אבטחת המידע מתחלקת למגוון תחומים, במערכות צבאיות חשוב במיוחד לשים לב אליהן:
• סודיות - התקשורת בין המערכות השונות חייבת להיות מוצפנת כך שהאויב לא יוכל לדעת מה קורה. יותר מזה: המערכת צריכה למנוע מצב בו אויב מסוגל להתחבר בעזרת מערכת שנפלה בשבי. כמו כן, כדאי מאוד שהמערכת לא תשדר אותות על בסיס קבוע, כי שידורי רדיו אפשר לאכן, וחבל לחשוף את מיקום הצוות.
• זמינות - בשדה קרב, האויב ינסה להתקיף כל מה שניתן, כולל את רשת התקשורת של הצבא שמולו. המערכת צריכה לדעת להתמודד עם הפרעות אלקטרוניות, עם פצצה שנופלת על חלק מהמכשירים (מה שאומר - בלי שרת מרכזי, כן?) והשד יודע מה עוד. 
• מידור - זה לא רעיון טוב לחשוף את כל התוכניות של כל הצבא לכל חפ"ש שמחובר למערכת, יש דברים שצריכים להיוודע רק לבעלי תפקידים מסויימים. 
• ניידות - להוסיף לצוות חי"ר קילו או שניים של ציוד זה איכשהו נסבל, אבל אם הם צריכים לסחוב איתם מערכת של עשרים קילו זה פשוט לא ריאלי. בתוך היכולת הזו אני כולל גם את היכולת לפרוש את רשת התקשורת בשטחים חדשים - טלפון נייד הוא נפלא, אבל כדי שהוא יפעל צריך להקים כמות לא קטנה של אנטנות. מכשיר קשר סטנדרטי, מצד שני, לא צריך שום תשתית.
• פונקציונליות - נו, בסוף צריך להגיע גם לזה, לא? כדאי שניתן יהיה לבצע במערכת את מה שהיא מתיימרת לספק. אבל נכון - זה פחות חשוב מאשר הדברים שנמצאים למעלה. 
• עומס - בשדה הקרב יש מאות, אם לא אלפי יחידות. אם יש שרת, הוא צריך לדעת להתמודד עם כולן, ואם אין שרת, היחידות צריכות להיות מסוגלות להתמודד עם תיאום בין אלפי יחידות. 
• ביצועים - מערכת לניהול קרב מתמודדת עם עולם שלא מחכה לה. חמש דקות נוספות שלוקח לבצע פעולה יכולות להיות ההבדל בין היכולת להיעזר במערכת לבין הכורח לזנוח אותה. ביצוע פעולות צריך להיות מהיר מספיק. זה לא חייב להיות מהיר כמו מכונות שמתעסקות במסחר אלגוריתמי, אבל כדאי מאוד שפעולות שגרתיות יתבצעו באופן חלק מבחינת המשתמש. 

בקיצור, כיף גדול לא היה לי במילואים, אבל לפחות קיבלתי הזדמנות לחשוב על בדיקה של תוכנה מסוג אליו אני לא רגיל (ולהבין שתכנון טוב של מערכת כזו הוא עניין מורכב מאין כמוהו). 

--------------------------------------------------------

Now and then, when I consider trying to find myself a relocation option and wonder whether I really want to try such a thing,  one of the first arguments that I note at the "pro" side is military reserve duty. The fact that at any a summon can arrive and with a short notice pull me back to my worst period of life so far (and I really hope not to experience worse times) is burdening my life more than I would like (and more than I usually admit). 

Anyway, why do I spill my guts here? After all, this blog is about testing. the thing is, I was recently called to service. The thing I do requires me to work a bit with an ABCS (ABCS= Army Command Battle System, the link in the Hebrew version is different, since it directs to the actual system used in the IDF, but I didn't' find any description of it in English). Even though there were some inhibitors such as lack of sufficient sleep,or the fact that it was not OK for me to completely break the system (besides, it broke perfectly by itself ) as well as other tasks I had to do, giving me a software to play with is fun and will lead me to think about "how would I test it?".

Obviously, I'm not going to get into details about a military system in a public blog. Since most of the not-so-secret stuff in the IDF are classified as "you can tell it only to other Israeli citizens" and I am used to bundle up "not classified" with "not-so-secret", I won't trust my memory or instincts and will choose to err on the safe side. I do feel free, however, to link or to discuss things that already exist in the internet. Also, instead of discussing the particular features and behaviors of the system I worked on, I want to raise a question - What are the things you would test in such a system? A short reminder for those that did not read the Wikipedia page, or did not understand it, we are talking about a system used by both the troops in the field and all levels of command - wherever they may be.

The full list when coming to test such a complex system is huge, and even when trying to pinpoint "the most important stuff" there can be many answers (in fact, what is your list of "big items"?). At any rate, here are the main subjects I think are the most important to notice:

• Simplicity - The system will be used by a lot of folks, under stressful situations, and most of them are not necessarily computer wizards, and most of them have other complicated tasks without having to deal with this new system. If they will have to invest to much time or effort in the system, their performance will decline instead of improving, which is the whole purpose of this system to begin with. It has to be simple for all levels and types of use.
• Resilience - It's a battlefield, not a cozy test lab. The equipment will suffer from dust, rain, mud rattling around when carried, being accidentally hit by a piece of equipment carried by a soldier (Any soldier that has carried a rifle had accidentally hit something or someone with the barrel of his gun at least once. Most soldiers I know don't even notice this happening anymore unless some damage or pain is caused), and only the devil knows what else could befall the poor equipment on top of the issues I've already mentioned (one thing could be harsh weather conditions - from extreme cold to extreme heat).
• Efficiency - The system's whole purpose is to improve the soldiers capabilities and to enable them to take better decisions faster. 
• Filtering information - I would not normally consider this as a separate issue and would include it under efficiency or simplicity\easy of use, but after playing with the system in a rather limited stressed one fact to me - in the battlefield there are gazillion things that someone should know about. Every squad, and every enemy force generates at least one point of interest, battle plans, events, areas of responsibilities, various form of geographical analysis (for instance - what can be seen from a  certain point, or what should be the comm coverage of an antenna placed in one place) and even field intelligence items - all of these are crammed into one, not that large screen. Moreover, For any given soldier, most of the information is only a distraction. A cannon operator cares only about "where can my cannon shoot?" and "when and what to shoot?". Both battalion commander and a brigadier general cares about the location of their forces, the position of enemy forces and stuff like that, but while the former will need to know those things down to the single squad, and sometimes to the single soldier level, the latter can't afford this level of granularity and must look at the bigger picture.
  In short - in order to be usable, the system must allow filtering information, and since it is this important, it is worth being tested specifically for it. 
• Information Security - as always, this breaks down to several properties, according to your favorite acronym (STRIDE, CIA or any other acronym you may have encountered). The properties I would invest effort in trying to ensure are: 
•  Secrecy - Most of what is going on in this system is the jackpot of the enemy intelligence, so we better make some effort to keep them away from it. The obvious requirement is that all communication be encrypted so that no one would be able to tap into the communication channel, but the system must protect against situations such as a device falling captive, perhaps even with it's legitimate operator. Besides, it would be great if the system will not broadcast constantly, as most broadcasts can be triangulated, thus exposing the location of the forces. 
• Availability - It's a battlefield. The enemy will be attacking everything, the communication network included. A bomb dropped on a main server better not disable your system, and a station should be able to provide some basic functionality even when it cannot contact any other component of the system (which may happen if the enemy if jamming all radio broadcasts in an area).
• Compartmentalization - It's a bad idea to expose everything to any grunt that has connected to the system - some pieces of information should be available to certain people only. 
• Portability - I should probably find a better term for that, as I don't mean portability in the conventional use it has in software testing context. I mean the ability to carry the system along with the fighting forces. Adding a Kg. or two of equipment to an infantry squad is bearable, If they have to carry with them something that weighs 20 Kg. (~45 pounds) that would be rather difficult and irrational, and anything more than that would simply be impossible.
  Another thing I include here, which may deserve a bullet of its own, is the infrastructure required for the system to work - a cell-phone is great, but it must rely on a strong network of antennae that should be deployed. If the system is small and compact, but requires complex infrastructure work, the forces may end up having a small and compact piece of junk. 
• Functionality - well, we had to get to functional testing eventually, didn't we? while less important than the previous bullets (at least in my eyes), I would prefer to have my system working correctly. 
• Load - The modern army has hundreds, if not thousands of forces in a given battlefield, probably more in an entire war. The system should be able to deal with all the different stations - whether it is designed as a server-clients system or as independent stations communicating with each other. 
• Performance - Here I get close to the "nice to have", but this system operates in a highly dynamic world that does not wait for it. While it is not the performance requirement of an algo-trading system, and that of your day-to-day web page, an extra five minutes it takes to complete a complex request can be the difference between being able to use the system and having to ditch it. 

To wrap it all up, I didn't have fun during my reserve duty, but at least I got a chance to consider testing of a software very different from the one I'm working on in my daily job (and to be baffled by the complexity of designing such a system).