תראו כמה מסמרים! Look at all these nails!

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

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

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

A famous proverb states that if all you have is a hammer the everything looks like a nail. What is also true but less frequently heard is that when you don't have a hammer in your toolbox, you miss out a lot a nails. 

Eight months ago, I went to one of the local selenium meetups organized by Adam Carmi (Co-Founder of Applitools) and Oren Rubin (Founder of Testim) where I've heard Dave Haeffner that recommended to incorporate Browsermob proxy into Selenium tests (By the way, if you are working with Selenium and have not yet heard of Dave, you probably want to register here to his weekly Selenium tips). So, I did some reading and decided to give it a try. I did a quick proof-of concept and then went struggling to try and stitch BMP to our project (Library conflicts can cause all sorts of insidious problems) - Finally, after several hours of work that spread over several months - as there is always something more urgent to do than an independent pursuit of an idea - I managed to run our tests through a proxy. 

The next step was to show off to my team - I spent around 15 minutes (including the learning curve) and added a simple check: for every request checked the HTTP response status and printed all the unexpected ones. As a result I found out that some pages are asking for resources without reason (the reason for that is buried under layers upon layers of legacy code - so we have decided to leave it as is). 

At any rate, what I did or didn't find is the least interesting thing around here, the more interesting phenomenon was that once we accepted the new capabilities that we now had, we suddenly started having all those new ideas of things we now can and should do - all of them are valid and valuable checks that we did not previously thought of - on top of the improvements we intended for our existing tests, there were some new tests we came up with just because we now could easily do them with our new and shiny tool. Previously, we have not thought about them because we had other things laid out in front of our eyes. We had selenium API that is all about DOM elements, we had database checks that are focused around what is written where, and we were checking our logs as well. We are improving our work with them constantly, but in the meanwhile we missed (and are still missing) a whole world around us. 

For me, this experience was very educating. I can definitely use this as a reminder to me that there are always more areas to look at - metadata, memory consumption, the actual usage of the software in the real world, and a million other things. Expanding our capabilities in what was previously a blindspot has almost instantly improved our testing and our ideas - I see no reason it won't do the same for you. 

בחישה קצרה בקלחת Trying to stir things a bit

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

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

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

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

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

נראה לאן זה יוביל.  

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

Last week I got a meeting summon with a title "Periodic check-up with HR" (or something along those lines) - once every 6 months, or a year, or whenever they get around to do this, our HR "business partners" (I have no idea what does this mean, but this is the official title for the HR person that is my contact point for everything under the general HR domain) try to meet every employee in order to see how things are, whether there are any complaints, requests or things that bother them. Pretty nice of them, isn't it? At any rate - a 30 minutes talk with no goal other than to listen. So, in the worst case scenario - I would have spent half an hour while someone was listening to me vent some steam. I certainly won't say no to that. 

I came to this talk with the same message I get to every meeting with someone that is either part of, or have a direct channel to, upper management.  I'm unhappy about the attitude towards testing as a profession in our company. Even though I know that inside the team our contribution is recognized and appreciated, and even though as a tester I am able to significantly influence "my" product, once we get to the department level, I feel as if we are missing a lot that can and should be done. For instance, one can point on the fact that different test team have different skills level. not just a different skill-set, that is reasonable to have, as the products are different, but the basic capabilities of the test teams is different. One team is simply better than the team next to it in the same building. There are differences in the expectations set for the different teams and even in the minimum requirements when recruiting a new junior team member. In addition, there is no-one around that fills a role of a "testing expert" testers learn from. In short, even though actual testing is appreciated, it doesn't seem as if anyone considers it to be a profession that one should invest and get better in. Adding to that the fact that most of our teams are working in a Scrum-but, I really don't understand why am I part of a "QE department", or what do I gain from that.  

So, each time I find myself having this type of conversation with anyone that has anything to do with upper management ("upper" being a relative term here, from the viewpoint of the corporation I'm working in, they are probably considered as mid-level management) I try to advocate for the idea that something needs to be fixed - either abolish the concept of "QE department" and remove the bureaucratic hassle caused by having two departments managing each team, or add some value to being part of a dedicated testing department - Have some unified standards to testing, a common test approach or shared goals, testing-centered training - anything. 

While talking about this subject and trying to understand better what is it exactly I'm missing, one of the things that came up was that I don't see anyone around that seems interested in what's going on in any sort of a testers community - no one seems to be consuming any sort of professional content - books, blogs, podcasts, local meetups, nothing.  Currently I know of two persons that want, and do an effort to participate in a strong testing community - my direct manager and myself (though, to be fair, my department's director does read at least some professional texts, which is more that I can say about the rest of the testers around).Then, the HR business partner suggested something - Since I'm already spending time reading, why won't I share interesting things I find with the rest of the testers?

Frankly, I have thought of this idea several times, and decided that I don't want to be one of those annoying guys that sends spam to a large group of uninterested people. At this point she suggested an idea I have not previously considered - create a new mailing list that will be dedicated to the subject. This way only those who opted-in will receive what I share, and it may encourage others to share as well. 

And so I did - after a surprisingly short affair with our India based IT support, I was got my mailing list, and sent an invitation to all of the QE department. Now, all I have to do is to wait for people to join (despite a very low initial interest shown, I suspect that my director will be applying some sort of pressure on certain persons to join). One way or the other, I suspect it will be a useful experiment to conduct - either I will succeed at creating some sort of professional interest in testers around me, or I'll know that no-one around me cares enough even to passively listen. At any rate, if we accept James Bach's approach, this will be a step for me becoming a testing expert, at least in my local environment (For those that don't have the time to listen to a one-hour lecture, Bach's claiming that one of the criteria to being a testing expert, and probably the most important of them, is to have the reputation of one). 

So, let's see where will it take me. 

תיעוד בדיקות - למה זה טוב?What's the purpose of test documentation?

Today's post is a response to something I read online. Since the writer of that article probably doesn't read Hebrew, I will change the regular order and start this time with the English version.

In her post, Nicola Owen presents an interesting question: What's the purpose of test documentation? Her answer to this is simple - Test documentation is meant to communicate information.
Out of this simple statement she then continues on to examine the possible audiences of such communication efforts and provides an interesting insight to the way each audience is changing her mindset and focus points while writing the documentation.
However, while very interesting, I could hear my inner voice revolt. "I don't document test cases in order to communicate! at least not only for that" . So, I took a moment or so to stop and think "what do I use test documentation for?" and what was it in "communicating information" that got me ticked off?
Before I start, I would like to clarify a point that was a bit ambiguous for me - what is "test documentation"? It might be just my poor control of English that led me to understand it this way, but I differentiate "documentation" from "documents". The first is a term borrowed from the programming context, where it usually refers to the comments that explains what is being done in that weird piece of code just next to it. The latter is a bit more general and refers to any type of document produced during any of the testing phases. So, "documents" will contain everything - test plans, requirements, bugs, detailed test cases and possibly also my grocery store latest receipt (ok, that might be stretching it a bit too far). Test documentation, however, are mostly the step-by-step description of test cases performed, along with their run status. One might also debate whether filed bugs are part of it (Which, as far as I was able to judge, are referred to in the original post) but in order to keep things simple, I will exclude them.
Anyway, to the list of what I do with test documentation:

1. Communication with my future self or with my testing teammates.
   Yes, even though it's not the only thing I do, it is still very important for me. Those documents will later help me to recall how to use a feature I have not used for a year, or recall which configuration parameter controls what functionality and sometimes even whether some peculiar behavior of the system is intentional or not.
   Communicating outside of the test team is usually not done with test documentation but rather with an oral discussion, or filed bugs (that may or may not contain steps to reproduce the issue, according to the specific context of this bug). 
2. Organizing and formalizing data - I don't work well with fine details, I can focus on them from time to time, but I need to sit down explicitly and rephrase them in order to truly understand them and not be distracted by the bigger picture. Forcing myself to write down every tiny details drawn my attention to it: I notice what data is being written to which table in the database, which lines are relevant in the log files and I formalize a way to use the software. When I do that, I get more familiar with the software I am testing. 
3. Think a bit more about my tests - This is probably strongly related to the previous bullet: I can't recall the last time I wrote my test cases and did not find something that needed changing or that should be added to the test. 
4. review and control over what I am doing - yes, it is a bit similar to the communication part, only I do not intend to pass information, but rather to verify that I have covered everything I intended to cover and did not forget anything important as I was performing the tests. 

From those goals I derive my way of writing the test steps: Since I will be using them as a reference in the future, or someone new to the team will use them to learn about this feature, I write extensive descriptions that rely on the reader being generally familiar with the system, but otherwise will be very detailed, sometime up to the point of "Copy/Paste" commands.
As I use test cases in order to rethink my testing and to review the gaps I may have left, I also add to each step a title explaining its intention and providing me with a short way of understanding the step, or test case.

Finally, I would like to note that while writing test cases is one of the most hated tasks in our team, writing them down is proving useful again and again and again.


Edit - I just got to read this post I really liked it, because it emphasizes an important point that I only half mentioned in my third bullet - while writing down a test case I often find some bugs just because I stopped to think about it.
-----------------------------------------------------------------------------

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

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

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

ולהלן הרשימה: 

1. תקשורת עם עצמי העתידי ועם שאר צוות הבדיקות. כן, למרות שזה לא כל מה שאני עושה, מסמכי הבדיקות ישמשו אותי בעתיד כשאנסה להיזכר איך בדיוק להפעיל משהו, או כשאנסה להבין אם התנהגות מסויימת נעשית בכוונה או לא. תקשורת עם גורמים מחוץ לצוות הבדיקות לא נעשית דרך מסמכי תיעוד הבדיקות אלא במקומות אחרים - באגים שאנחנו פותחים, מסמכי תכנון בדיקות, או סתם לקום ולומר מה שיש לנו לומר. 
2. ארגון מידע - הפרטים הקטנים מבחינתי תמיד היו משהו חמקמק מאוד - אני מסוגל להתמקד בהם מדי פעם, אבל בדרך כלל אני רואה את התמונה הגדולה. כשאני מכריח את עצמי לשבת ולכתוב את הדרים ברזולוציה נמוכה - אילו ערכים יכולים להיכנס לאיזה משתנה, לאילו טבלאות במסד הנתונים דברים נכתבים, איך בדיוק להפעיל כל דבר - אני מקבל תמונה שלמה הרבה יותר של מה שאני בודק ולפעמים גם מגלה קשרים במקומות שלא בהכרח ראיתי אותם קודם. 
3. חשיבה מחדש על מקרי הבדיקה - זה קשור מאוד למה שקורה בסעיף 2: אני חושב שלא הייתה פעם אחת בה ישבתי לכתוב את צעדי הבדיקה - ולא משנה אם זה קרה יחד עם ביצוע הבדיקה, מייד אחריה או חודש אחר כך - ולא גיליתי עוד מקרה בדיקה שכדאי שאכסה. 
4. בקרה על מה שאני עושה - כן, זה קצת דומה לתקשורת, אבל אני נעזר במערכת ניהול הבדיקות שלנו כדי לוודא שמה שתכננתי לעשות אכן בוצע ושלא שכחתי שום דבר תוך כדי ביצוע הבדיקות עצמן. 

מהמטרות האלה נובע גם אופי מקרי הבדיקה שאני כותב - הם יהיו מפורטים למדי: משתני סביבה, טבלאות במסד הנתונים, התנהגות צפוייה וכיוצא באלה, אבל הם גם יכילו כותרת שתסביר מה המטרה של כל צעד.

והערה קטנה לסיום:

בסופו של יום - למרות שכתיבה של צעדים מפורטים היא אחת המשימות ממנה כולם משתדלים להתחמק, הערך של ביצוע הפעולה הזו מוכיח את עצמו בכל פעם מחדש. 

נוסף בעריכה - 

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

בשביל מה אני צריך כלי לניהול בדיקות? What do I need a test management tool for?

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

מה שהניע את התהליך אצלי אי שם ב2013 היה השוואת כלי ניהול בדיקות שקראתי בבלוג של עדי מור, בעקבותיה החלטתי לנסות ולהיפטר מהכלי שהשתמשנו בו והרגיז אותי מאוד - HP Quality Center (אנחנו עדיין משתמשים בו, בגרסה 10.0 שעדיין כתובה בactiveX ונראית כאילו מיטב טכנולוגיית שנות התשעים הושקע בה). ישבתי והשקעתי קצת זמן בחיפוש כלים, תחת מגבלה אחת - ההנהלה דרשה שהכלי ישב על שרתים שלנו ולא איפשהו בענן. 

תוך כדי חיטוטים וחיפושים הופתעתי מאוד לגלות שבסופו של יום, QC הוא אחד הכלים הטובים ביותר שראיתי. מתוך חמישה או שישה כלים, היחיד שהיה בר השוואה אליו היה QAComplete של SmartBear.  

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

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

1.  קודם כל, ניהול דרישות. מבחינתי, חשוב שיהיה לי מקום בו אני יכול לשמור את הדרישות של כל המוצר שלי כפי שהן כרגע. זה עוזר לי להתמצא, עוזר לי לחשוב על בדיקות ועוזר לי למצוא בדיקות ישנות שאולי קשורות למשהו. ממערכת ניהול הדרישות אני מצפה לדברים הבאים:
1. הירארכיה. היכולת להגדיר מודול שלם כדרישה ואז לפצל אותו לתתי דרישות. 
2. קישור לבדיקות  - די טריוויאלי. 
3. קישור לדרישות אחרות - המודל ההירארכי של עץ דרישות הוא חשוב, אבל בדרך כלל ישנם קשרים שאינם בתוך אותו העץ. נניח, אם מחייבים לקוחות על שליחת SMS, מודול החיוב מושפע ממודול שליחת SMS.
4. דיווח מצב - האם יש בדיקות שמכסות את הדרישה? האם הן רצו? עברו? מה מצבן של כל תתי הדרישות? מה מצבן של כל הדרישות בגרסה? 
5. סינון, או, בלע"ז - פילטור. היכולת למצוא דרישות לפי מסננים שונים (כמו מספר גרסה, סוג דרישה, קשר לדרישות אחרות וכו'). 
6. חלוקה לסוגי דרישות שונים - אצלנו חשוב לנו לזהות דרישות אבטחה ודרישות ביצועים, נוסף על הדרישות הפונקציונליות. לא מצאנו עדיין צורך בסוג דרישות נוסף, אבל במוצרים אחרים דברים כמו "חוויית משתמש" או "עמידה בתקנים" יכולים להתאים גם הם. 
2.  חיפוש בבדיקות קיימות - אחד הדברים המרכזיים בהם מערכת ניהול הבדיקות תורמת לעבודה היומיומית שלי היא כשאני משתמש בה כדי למצוא מידע לגבי פיצ'רים שנכתבו מזמן. לפעמים קורה שדווקא בתוך תסריטי הבדיקה אני מצליח למצוא תשובות לכל מיני שאלות שצצות. 
3. כתיבת בדיקות נוחה - אחד הדברים שהכי כואבים לי בשימוש בQC 10.0 הוא שזה ממש מרגיז לכתוב תסריטי בדיקות. הנה כמה דברים שיכולים לעזור:
1. ממשק גרפי נוח - זה נחמד כשהמסך נראה יפה, וגם מקשי-קיצור עוזרים מאוד. עם זאת, גיליתי שנוח לי יותר לכתוב במבנה של צעדים ולא בטקסט חופשי. 
2. החלפת טקסט - לפעמים יש דברים שמשתנים תוך כדי פיתוח. למשל - שמות משתני קונפיגורציה. אם שינינו את "isEnabled" ל"isActive", אני לא רוצה לעבור בדיקה, בדיקה ולשנות את הטקסט. פונקציונליות כמו "החלף הכל", או כמו טבלה שממפה משתנים לטקסט הופכת את החיים לקלים יותר. 
3. העתק\הדבק ושכפול - בדרך כלל, כשאני כותב תסריטי בדיקה לאותו פיצ'ר, אני מוצא שצעדי האתחול דומים מאוד, וחלק מהפעולות דומות מאוד. העתקה נוחה של תסריט, או של כמה צעדים בתסריט היא הבדל משמעותי. 
4.   קישור בין צעדים - קורה לי לפעמים שאני כותב "התוצאה צריכה להיות כמו התוצאה בצעד 3", כדי לחסוך מעצמי את הצורך לתקן עשרים מקומות אם התוצאה הצפוייה משתנה. אבל מה שקורה אז הוא שבין צעד 2 לצעד 3 נכנס צעד נוסף ומשנה את המספור. עכשיו אני צריך למצוא את כל המקומות בהם הפניתי לצעד 3 ולהחליף את ההפנייה לצעד 4.
   דוגמה שנייה לצורך הזה הוא כאשר אני רוצה לומר "חזור על צעדים 5-9 עם משתמשים מהסוגים הבאים...".  
4. דו"חות - בסופו של יום, ההנהלה רוצה את הכלי כדי לדעת כל מיני דברים כמו "כיסוי לעומת תכנון", "מספר כשלונות", "חומרת התקלות שנמצאו" ומגוון דברים אחרים.  אני לא אתעקש על הגדרת דו"ח בעצמי אם הדו"חות המובנים בכלי עונים על הצרכים שלי, אבל זה בהחלט יכול להיות משהו שימושי.  
5. הרצת בדיקות - בעיקר כדי למלא את הדו"חות בתוכן, חשוב לי לדעת אילו בדיקות רצו, אילו עברו ואילו נכשלו. 
1. קישור הרצה לגרסה. - אני רוצה להיות מסוגל להריץ את אותה בדיקה על כמה גרסאות שונות ולראות את הסטטוס הרלוונטי לכל גרסה. 
2. משתני סביבה - לפעמים בדיקה נכשלת רק כשהיא רצה עם מסד נתונים של אוראקל.
3. משתני בדיקה - לפעמים, באותה סביבה יכולים להיות כמה משתנים (למשל - סוג משתמש). אולי בדיקה של login נכשלת רק עבור מנהלי מערכת?
4. עריכת הבדיקה מתוך מסך הריצה - כי כמעט תמיד, תוך כדי הרצה צצים דברים שצריך לתקן. 
6. קונפיגורביליות - גם בתוך החברה שלי, צוותים שונים ירצו שהמערכת שלהם תיראה קצת אחרת. עוד שדה, פחות שדה, כן חובה\לא חובה.  
7. התממשקות עם כלים אחרים. מבחינתי, הכלים המרכזיים איתם אני רוצה להתממשק הם Jira, בו אנחנו מנהלים את המשימות והבאגים שלנו, וVersionOne, שם אנחנו מנהלים את הסיפורים, את הספרינטים ואת הbacklog שלנו.
   בקטגוריה הזו אני גם סופר את היכולת לייבא נתונים מכלי ניהול הבדיקות הנוכחי שלנו. 
8. התממשקות עם אוטומציה - זה לא מאוד קריטי לי כרגע, כי האוטומציה מנהלת לוגים ודו"חות משלה, אבל אם יש API נוח שמאפשר לי לקחת בדיקה ולעדכן אותה באופן אוטומטי, זה כנראה לא יכול להזיק. יכול להיות שזה דורש תחזוקה גבוהה מכדי שזה יהיה רעיון טוב, אבל אם הכלי מאפשר לי לגשת אליו מתוך האוטומציה, בשפה בה היא כתובה (ולא, כמו שעשו QC עד גרסה 11, להכריח את המשתמש לעבוד עם אובייקטים מוזרים בvbscript) אני אראה זאת בחיוב.
9. ייצוא נתונים - כי בסופו של יום, כלי ניהול בדיקות לא צריך להיות חתונה קתולית. 

זהו, פחות או יותר. עכשיו נשאלת השאלה - מה שכחתי?

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

I'll start with a short disclaimer - I do, indeed, need a test management tool. Even though I am familiar and quite agree with the claim that "Test cases are not testing" (There is also a written paper here), I find that, at least in my environment, there is some added value to writing test cases (documentation, proof for the future me that something was checked, a way of measuring some sort of "coverage" and some other stuff as well).
 Last week my director dug up a comparison I made between two such tools and rethink whether we want to switch our current tool, For me, this is a great opportunity to think about my expectation from a test management tool. 

What had originally started my quest back in 2013 was this post from Adi Mor's blog. Following her footsteps, I decided to try and get rid of the annoying tool we were (and still are) using - HP Quality Center (we are using version 10.0, that still uses activeX and looks as if the best technology available in the 90's was used in it's construction). I invested some time comparing different solutions I could find, with one limitation - The system had to be on-premise and not somewhere in the cloud. During my search, I was surprised to find out that QC was actually one of the better tools out there. Out of five or six tools, the only comparable product I could find was SmartBear QAComplete. 

This time, we might not be tied to on-premise solutions only, and if this will be the case, I might have a candidate in mind, but sadly they don't offer a free trial for me to play with, so I'm not sure that it answers all my needs. 

Anyway, since I can't really find my notes from back then, this post won't be a comparison, but rather a list of my requirements from such a tool, ordered (roughly) by priority:

1. First of all, requirements management. For me, it is important to have a place where I can keep my product's full requirement-tree. It helps me find my way around, helps me think and helps me find old requirements that might be relevant to a new feature (as well as find old tests covering an almost forgotten requirement that just now someone from support has asked "why does our system behave like that?"). I expect the following properties: 
1. Hierarchy. I want to be able to define "this is a sub-requirement of that. both of those are not a "module" (which may be something bigger). 
2. Link to test cases - pretty obvious. If I spent time writing test cases, I want to be able to find them (Otherwise I wouldn't take the time to write them down). 
3. Linking to other requirements - sometimes I want to say "this requirement is related to that one over there, even though they are not in the same part of the tree, or even in the same module. For instance, if I charge my customers for sending SMS messages, then the requirement "when attempting logging-in, send a user with one-time password via SMS" will affect the billing requirements. 
4. Status report - Are there any test cases covering the requirement? have they been run? passed? 
5. Filtering - by version, by type, by a custom field - I want to be able to find requirements easily. 
6. Marking requirements type - In our place, we use security and functional requirements, as well as performance. in other contexts there might be use for other types. 
2. Search text in existing test-cases - one of the main reason we write test cases is that we found it a useful way to keep a knowledge base - sometimes the only way to find an answer, or to recall how to use a long forgotten system (we have a few of those) is to search for a test case that describes the specific area. 
3. Convenient to write test cases - this is one of the pains we are experiencing with QC 10.0 - it's really annoying to write test cases. here are some things that can help: 
1. An easy-to-use GUI, it helps if it looks good, and hotkeys are a great helper. I also discovered that I prefer structured steps over just a free-text box
2. Search  & replace - Imagine you are writing some test cases. being a nice person, you keep mentioning the name of the parameter that should be turned on or off. Then, the parameter name is changed. going over the all of the places where you have used it can be a real fuss. 
3. Copy/Paste  & cloning - Sometimes, there are similar test cases. if it's easy to copy and paste test steps, it makes my life easier. If I can clone a test and change the details I want - it makes my life easier. 
4. Linking between steps - Being lazy, I often write stuff like "the expected results are the same as in step 2". which is great, but then step 2 becomes step 4 after two more steps were added before them. If excel can keep track of cells in a formula, can a test management tool do the same? 
4. Reports - By the end of the day, my managers (and sometime myself too) just want to see the overall picture - Have I covered my requirements? Have the tests been run? How many bugs were found? Generally speaking, how are we doing?  A strong set of built in reports can probably answer all of my questions to a satisfactory level, But being able to create my own reports is also a nice thing. 
5. Running tests - and by "running" I mean "marking the tests as passed or failed. This should be meaningful and easy. It is important mainly in order to fill the reports, but that's something too. 
1. linking a version\build to the run - if I have several versions, I may want to run the same test for all of them, I wouldn't want the results to leak between versions (that is - if I re-run a test and now it passes, I care less for the fails that were fixed. If I fail in one version, but then I run the test on the previous version and it passes, I still want to see the fail. 
2. Linking to environment configuration - sometimes a test will fail only when using oracle DB. we should know that. 
3. Test parameters - some time, a test is run many times with slight variations. For instance, the system I test has several dozens of customers. Sadly, many of them have special configuration. A simple test may fail for one customer only because someone made a mistake when tweaking this customer's configuration. I want to be able to say "for this test case, I want to maintain separate tracks for the values in *this* field. 
4. Editing the test case script from the run screen - because almost always I will spot mistakes, or changes that should be done, when I am running the test. 
6. Configuration - Even in my company, different teams will want different things - extra fields for one team, a set of default values for another.
7. Integration with tools - Jira and versionOne are the tools we are working with. I also refer here to the ability to export data from our current tool. 
8. Integration with automation - Or, as the folks call it - a decent API. it's not critical for me at the moment, but in the long run I would love to connect my automation to my test management tool.
9. Exporting data - 'Cause, you know, choosing a tool isn't a catholic wedding. 

Now, have I forgotten something?

הרקדן האוטומטיThe automated dancer

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

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

בקיצור, בפעם הבאה בה אתם רואים מישהו משתמש במינוח "בודק אוטומציה", קחו פטיש פלסטיק וחבטו לו בראש.

(For the non-Hebrew speakers in the audience, The title refers to a song from the 70's that somehow was not forgotten in the mists of time)

So far, the few posts I had written were triggered by an actual experience I had and got me thinking about something, or helped me understand an interesting point. This time, however, my main argument is that someone is wrong on the internet. This time, I have encountered the question (roughly translated) : "How can I become an automation tester". This question annoys me in several manners altogether.

Probably the first thing that annoys me is that I encounter this question a lot. It's almost always "how can I advance to automation?", "How can I acquire automation skills?". It is almost never "How can I become a better functional tester?", better in embedded systems testing, in user experience testing etc. One exception for this is performance testing (another might be security testing, but I'm leaving this out, since most security testers I've encountered defined themselves as "security consultants"), which I see frequently enough. The reason for that, sadly, is obvious - employers are paying more for those type of testing. For automation, since they are used to pay programmers higher salaries, and for performance testing, since it actually seems like something that requires expertise (and testing isn't being perceived  in such a way usually. I understand it, but this understanding annoys me even more.
Another reason that annoys me is that this question is usually "how can I move advance my career to automation?" and while this is an advancement in terms of pay and, sadly, also prestige, so does being a successful lawyer. The issue is that unlike other fields of expertise in testing, there isn't really a path that can lead someone from being a "manual tester" to being hired as tester that writes automation. For instance, I can catch up on security testing by involving myself in the security related features in my product, practicing a bit, reading a bit and being useful most of the time, I can't really learn how to program properly without investing a lot of effort in it, on my spare time. Not that it can't be done - it can, and does - but rather that the amount of effort is not that far from learning a new profession. The bar for starting to contribute is simply too high for one to contribute while learning.
A third reason, which is a bit petty, is that unlike advancing from junior to senior tester, there is nothing in "advancing" from tester to automation writer that means that one is a better tester. A performance tester is better in testing the narrow field of performance (narrow only in comparison to the entire field of testing that is, performance testing can be an astoundingly wide field), but a tester that can write automation is by no means better at testing anything. Programming is a skill that can assist greatly in testing, but so can SQL, or strong domain knowledge - possessing any of these skills doesn't make one a better tester.

But, finally, the main reason I find "automation tester" to be annoying is that using this term is setting a wrong connection between programming skills and testing. IMHO, there isn't, and shouldn't be, anything like "automation tester". Writing code is a skill that can help a software tester, and I will even say I consider it to be an important skill for a tester, but possessing this skill isn't something that justifies creating a new category of testers. I have yet to hear anyone refers to themselves as "SQL tester", even though some testers don't know SQL and don't use it in their work - this skill is too common to define a category. In a similar manner, some understanding in code (or, "in a scripting language", like some recruiters who wish to  pay less than a programmers wage like to phrase it) is so common today as is the requirement to participate in writing some automated checks, that the line between a tester that writes automation to one that doesn't is getting really blurry.  And, if that isn't enough, there are some very strong tools out there (such as SoapUI, or selenium IDE which is a less than perfect example) that provide just about everyone with some amount of automation capabilities.

So, next time you hear anyone referring to an "automation tester", take a squeaky hammer and smack them on the head.

OWASP are cool

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

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

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

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

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

אלו הדברים המצויינים שהיו.  מטבע הדברים, היו גם כמה נקודות שאהבתי פחות.

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

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

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

ותודה רבה לOWASP על מפגש שהיה באמת מצויין. 

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

This week I attended APPSEC-IL, a conference that was organized by the Israeli branch of OWASP and deals, naturally, with software security. From my standpoint, this conference had three main advantages: First of all - it was interesting. once the talks were published, I was able to find something that seemed interesting for almost every time-slot (which is no mean feat, if you take into consideration that there were at most two talks per time-slot). Second - it was not far from where I live and work (around 40 minutes drive, traffic included). Third - the conference was free. 

Those three properties made it really easy for me to invite my colleagues to participate (I could even say truthfully  "come, there will be free food") and saved me the need to worry about convincing too many people to go and creating a mess to our director that has a limited "personal development" budget that probably can't send everyone to a conference. Also, those properties made it possible for me to hope that some of my team will attend (spoiler - they didn't). 

My impressions from the conference are pretty good. I got to listen to some talks that exposed me to a world very different than my own (one of those was the talk Erez Metula gave on security in the world of IOT).Other talks that remained in a subject I was more familiar with still had a lot to teach me about new things to worry about (One I particularly enjoyed was Netanel Rubin's talk: "too big to fail - breaking wordpress core" that presented an impressive scenario of privilege escalation). 

If we'll add to that the great keynote talk that was presented by Jeremiah Grossman (Founder and CTO of WhiteHat security) who cam all the way from distant Hawaii to give his talk. He presented some interesting figures about the money invested in software security and the amounts invested in insurance against security breaches. He asked a simple question: Why are software security solutions being sold "as is"? Why aren't they providing some guarantees or a "return policy" in case a customer was breached despite using those solutions properly? 

This question sounds very simple at first glance - if you can't guarantee that your product delivers, why should anyone pay for it? just about any other product - software or other, has some sort of a return policy. However, after giving it a little bit of thought, I'm not sure this question is nearly as simple as it sounds. In fact, I don't see a way that such a commitment won't turn out to be a long list of exceptions, limitations and nuances, A little bit like those nasty, long incomprehensible terms and conditions you sign when buying Insurance. The reason for that is that there are so many ways to get in and cause some havoc, and no company (at least, to my limited knowledge)  covers all the types of security hazards that exist in the big bad worlds outside. Attacks, most unfortunately, won't stick to one vector but would rather use whatever they can. Could a company specializing in web applications security commit that your product won't be hacked by one of the employees? Could it protect against someone breaking to the physical server room? Or from an attack that targets the manufacture line of some silicone chips used by your system? If you are using AWS, could they protect you from a successful attack on Amazon's infrastructure?  And what happens if some of those attacks are compromising something out-of scope for that company in order to uncover a defect that is covered (e.g.: taking down a physical encryption machine in order to force the application to use less secure encryption). In short, despite Mr. Grossman's claim that his company is offering not only a refund, but also cover the first half-million dollars that the customer lost after a successful attack, I remain a bit skeptical about the adoption of this practice wildly and effectively (in fact, I am really curious about the fine letters in WhiteHat's contracts). 

Besides those, as is customary in some conferences, there were some nice giveaways - I got a T-shirt, a sponge ball, and a book! There is even a fair chance I'll read this book (In fact, there is a copy lying in our office, and the chapter I read from it was very informative and useful). 

Those were the things I enjoyed. As things happen, there were some minor things I enjoyed a bit less. One of them was the location. On one hand, the conference rooms were really great, with enough room to accommodate comfortably the 550+ participants in the main auditorium, with comfy chairs and electricity sockets for those who came prepared ( I left my power cable at home). On the other hand, the corridor, where all sponsors had their booths, and were people were during recess, was very crowded. Moving in the corridor involved stepping on a toe or two, pushing a bit and being pushed. 

Another thing for me was the schedule - with 8 talks per track, there was very little time left to meet new people. As one of the purposes of this conference was to strengthen the community (At least, this was declared by OWASP-Israel's chairman, Avi Douglen), I think the conference could have done a bit more in this field. I think that some workshops, or any other activity that can be conducted with up to 20 participants could be more effective in getting people to know each other. 

And one other thing I missed gravely was the lack of tester visibility in the conference. There were product owners, developers, "security people" and all kinds of consultants. But, it you don't count the PenTesters (And I don't count them since they usually prefer the title "security consultant"), I felt as if I was the only tester around. I'm sure that's not the case, but it still feels this way. In some of the talks the audience was asked "how many here are developers? product managers? security people?" no one asked on testers or on QA. This pains me a bit, especially since the connection between software security and testing is so natural (And, you don't have to take my word for it. you read the book "Threat modeling: designing for security" by Adam Shostack and find a similar saying in one of the latest chapters.  

So thank you OWASP-israel for a great conference.

most of the Iceberg is underwaterרוב הקרחון נמצא מתחת למים

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

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

ביחד עם הבדיקות האלה, אנחנו גם בודקים תיקונים אחרונים לבעיות, אם יש כאלה. הפעם, בעקבות הדרכה שעשינו על אחד הפיצ'רים, ביקשו מאיתנו להקטין את קבצי הלוג. מצאנו כמה שורות שחוזרות על עצמן והעברנו אותן לרמת דיבאג. לכאורה - הכל אמור לעבוד כמו שצריך. 

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

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

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

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

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

Our work methodology is probably best described as "Scrum-but": We work side by side, but have distinct separation between testers and developers, We are targeting user stories by priority, but most of the time the developers will continue to the next user story when there are still testing tasks, and we work in two weeks sprints, but release something to production only once in a couple of months. 

This latter "but" has one nice side effect - there are many tasks that need to be done during installation day. Sadly, some of them cannot be done automatically. It may be a new configuration parameter defining an environment property or a password, it can be creating a signing certificate, or contacting a 3rd party to provide us with its public key or just something that should be done only once and was not worth automating. In order to make sure that we do not miss anything on installation day, we create a step-by-step installation guide and then invest a week in testing it. In the last two or three times I took this task on myself, and each and every time I came across something we forgot, or even need some last minute fix. The main advantage I gain in performing the upgrade tests is that it makes it easier for me to wear my OPS hat, and thus notice stuff we missed the first time we tested it - be it procedural limitations (e.g.: in order to keep all machines in sync, OPS keep all files in a source-control server, so we cannot set a requirement to keep the same file with different content. at least, not without providing them enough time to come up with a solution). In this case, I noticed that even without actually doing any work, one of our logs swelled up and took a lot of disk space. Just to be certain - I asked around what is a reasonable log size, and could 1GB per day be acceptable for a while. They said they prefer their logs around 20 MB, so we out got our axe and went woodcutting. 

What was done was simply to move some repeating lines to debug log level, which is normally turned off in production, thus shrinking the logs.
In theory, all should work fine. the change is not risky, and should solve our problem easily. Only it did something else - it turned my focus to the log files, and to the number of times I saw the same line being printed. Cleaning up the extra lines, it was easier for me to see that we are still printing a lot of data over an almost idle process. When I checked this up with the relevant developer he first responded (as he does almost always) "Impossible". I let him vent out a bit of steam (it took me a while to learn this, but in his case, the best way I can make him accept a problem is show it to him, and move aside while he stares at it) and then we understood that the problem was a bit more complex than we first assumed. The lines we were seeing were printed during the process initialization, where some data that should be loaded only once and then cached was being loaded repeatedly. Or, as the experts phrase that: "oops".
After a short investigation we fixed the problem, but I learned two things that I will have to remind myself from time to time.
The first is that in addition to the functional requirements I normally care for, there are always some operational requirements that I keep finding by chance (either when we get lucky and spot this requirement before the code goes live, or when it goes live and we get complaints and a request for fixing stuff).
The second, which should be reiterated every now and then since it is so easy to ignore, is that I see mainly symptoms. Even though I got really good in guessing root cause and impact of various bugs, all that I have are what I see on the surface and a (good?) guess. Usually, when a bug is odd, or dodgy (and sometimes even when it's simple and straightforward), what I see is just the tip of the iceberg, and further digging in is required to uncover the full impact of the actual bug.
I'm not sure yet how to do that, but this is something I want to remain aware of and look for also in the future. 

The protocols of the Elders of Zion הפרוטוקולים של זקני ציון

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

בסופו של דבר, הוחלט על פיתוח גרסה חדשה לפרוטוקול. הודעות יצאו לעיתונות, ומסתבר שלא מעט אנשים גם התחילו לעבוד. 

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

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

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

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

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

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

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

The product on which I'm working does, in essence, two things: It fills a role within a rigid protocol (that is not controlled by us), and it provides our customers a variety of administrative tools to manage the software's behavior. The protocol, which is the core of our product, was released some 15 years ago, and has not changed much since. The world, unfortunately, has changed quite a bit, and several issues with the protocol (ranging from support of "smart" devices, through inherent security problems and to complaints from the field) became more important as time went by. Somewhere around January this year, the development of a new protocol was announced - some notifications were sent to the press, and apparently, some teams began working. 

A while ago, a draft of the protocol was sent to some key players and some meetings were held with relevant stakeholders. We were invited to one of theses meetings (and by "we" I mean our product manager and our Dev lead), and so I got to look at the draft of the new version of the protocol, and even send some comments, which proved to be very interesting for me. 

Initially, I got to the reading task in a way very similar to the way I get to any requirements document reading (regardless if this document is 150 pages longs, as was the case here, or if this "document" is a short conversation with a developer discussing what we want to do): I start reading, assembling a picture of what is being described as I go. Once I have even a sketchy image sitting in my mind, I try to superposition it on "reality" and see how well does it play with the existing components in our system and the flow of events as I have experienced it. Additionally, once in context, I can more easily spot weak points that might go wrong, find ambiguities and missing or wrong requirements. 

As I was reading and doing that, I added my comments to a the provided table for feedback (After all, the great bureaucrats has produced a lengthy protocol draft, what's one tiny table for them?). Formalizing the comments helped me notice one comment did not actually belong there, not even under "general" label. I could pinpoint the problematic page, paragraph and diagram that were problematic, but when I got to "proposed change" and to the comment justifying the change, I understood that I was not pointing a problem in the protocol, but rather a behavior I knew would make life more difficult for our product. At this point, the penny has dropped, and I realized two things: 

First - Unlike a piece of software I can always look at and ask for a retroactive change, once the protocol is released and becomes official - it is set in stone. No one can change it until the next version of the protocol. If we remember that this specific protocol is defining behavior for an entire industry, we see that this leaves a lot of power in the hands of anyone that can affect it (what? no, I'm not mischievously rubbing my hands. It only looks this way... behind you! a three headed monkey!)

Second - In addition to the "regular" testing\review that looks for honest mistakes, I need to put on another pair of glasses and look out also for  my company's interests: Both the points where someone has shifted the current balance towards them a bit more, or points where a small change could be beneficial for our product (and so we might want to try and push in that direction a bit). True, this isn't a testing work per-se, but it was just as interesting (and pretty similar).

Another question that rose was how to present those points I found wearing my other spectacles - Sending them in the official feedback document won't necessarily drive the desired change, as those comments are justified mainly by "My product likes it better this way", and those reading the comments belong to another company, with a different perspective and different interests. In some of the cases, the comments might not even represent the interests of some of our competitors that fill the same role in the protocol (though most of the time, our interests in the protocol align). 

I decided to leave this question to the team taking part in the meeting, since some feedback is more easy to convey in person, so I attached those comments separately for their use. Speaking with them afterwards, I know they chose to raise some of them during the meeting. 

To sum it up - Despite protocols being rather tedious, it was a very interesting exercise for me, and I look forward to the next phase (which will probably happen in a few months at least).  

עבודה שחורהWorking in the dirt

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

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

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

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

בנוסף, יצא שסיימתי לכתוב את הפוסט כמה דקות לפני כניסת ראש השנה - שנה טובה לכולם!

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

I assume that every software tester has faced here and there the following situation: Sometime you stumble upon a bug. it might be related to what you were currently testing, or it might not be, at any rate - it is something important enough to invest some time in investigating it. It turns out to be a bit complicated, but once you understand what has caused this to happen you can hear yourself saying "I would have never *intentionally* try testing this scenario!"
Such a case happened to me (again) this week - I was going over some changes in a rather simple part in our over-complicated system: it reads a line from a table in our database, formats it nicely and sends it to a designated server. couldn't be simpler, right?
As it happens, we have one problem with this process - it's not fast enough. It works kind of o.k. under the normal state of affairs, but if for some reason, this process was down for a while, or we have a busy day, this process has a hard time catching up. So, what do you do when you want something to work faster? The easiest answer is - you multi-thread and hope it works. One of our developers took up the task, and after several attempts came up with a nice idea - each thread will "lock" a time window and handle all the work that should be done there.
In the process of getting to this solution, we went through another one that didn't quite work as we hoped, and by the time we got to this implementation we were already working on this task for three weeks instead of the planned 3 or 4 days we assumed the original fix would take us. And, as every new implementation is, this one didn't work perfectly the first time (including a cute OBOB), so after toying with this for a month or so, we finally ditched it for higher priority items. When we got back to this feature after over a month of dealing with those higher priories, I noticed that the automation checking this is failing. Three days later we found the issue - apparently, I had some junk in my database that caused the time-window locking mechanism to fail, sending the process to sleep for a day.
Now, in retrospect, I think there were some ways I could go hunting specifically for this type of bug. However, the locking mechanism was not the priority target of my tests (I was more interested in the potential throughput), it was tested before and seemed reliable enough at the time, so I did not invest too much effort on checking every edge case. I got lucky.
The way I got lucky sent me thinking:  When I made my first steps in the testing world, I learned that at least in theory, each "test case", and especially those automated scenarios, has three steps - setup, where all the necessary preparations are being done, the actual test case, and then cleanup - where the test makes sure it will not affect other tests running after it. However, I stumbled across my bug when not cleaning it, and had I cleaned my data properly, I would not have found the bug at all.
So, I probably need to think about it a bit to understand how to implement it, but I rather like the idea of working in a "dirty" environment, after all - while a clean environment sure helps a lot in debugging, your production system won't run in sterile conditions, so why not test it with dirty data?, you might be able to find some interesting stuff.

And, is it happens, I finish writing just as the Jewish new year is approaching,
Have a great year!

הדברים הפשוטים, חלק 2The simple things pt. 2

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

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

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

בקיצור, יש המון בעיות אבטחה שקל למצוא, וצריכים רק לחפש.

אבל, לפני שניגשים לבדוק את תכונות האבטחה של מוצר, כדאי לדעת מה אנחנו רוצים להבטיח.

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

·           זיהוי - התוכנה מסוגלת לוודא שמישהו (אדם או תוכנה אחרת) הוא באמת מי שהוא טוען שהוא. 

·           שלמות - המערכת יכולה להבטיח שמידע לא השתנה באופן לא חוקי ולא הושחת בשום אופן, לא בזמן העברת המידע ולא בזמן שהמידע היה מאוחסן.

·           אי יכולת הכחשה - אף אחד לא יכול לבצע פעולה ולומר "אני לא עשיתי את זה" כי המערכת מסוגלת לספק עדות מהימנה לביצוע הפעולה על ידי הגורם הרלוונטי. 

·           סודיות - מידע מגיע רק למי שמורשה לגשת אליו.

·           זמינות - המערכת זמינה למשתמשים הלגיטימיים שלה בכל זמן בו היא אמורה להיות זמינה.   

·           הרשאה - המערכת מוודאת שפעולות נגישות רק למי שמורשה לבצע אותן.

במייקרוסופט הגו סדרה של דפוסי איום שמקבילים לתכונות האלה, כדי לעזור לנו לחפש חולשות, הם אפילו המציאו ראשי תיבות כך שיהיה קל לזכור:
STRIDE:
Spoofing - התחזות
Tampering - זיוף. 
Repudiation - הכחשה.
Information disclosure - הדלפת מידע. 
Denial of Service - שלילת שירות. 
Elevation of privilege - העלאת הרשאות (אם למישהו יש רעיון לתרגום טוב יותר, אשמח לשמוע עליו)/

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

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

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

ועכשיו, לדוגמאות:  

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

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

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

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

Not long ago I wrote a post about a security report we got (or got smacked with, as some would claim) and I suggested that every tester should think a bit about the security when testing an application. One thing I didn't do enough, mainly since I didn't want the other post to be too long, is to emphasize one simple point:

When most people think about "security tests" they immediately start imagining the complex stuff implied in today's movies. You know, the scene where that super sophisticated hacker is using cool tools, hackers like this guy. And how could you defend against such smart people without being an equally smart security expert?

The reality, of course, is very different. Yes, from time to time you hear about such attacks (did anyone say Stuxnet?), but more often than not there are security vulnerabilities that are far easier to exploit, and simpler attacks. Can an employee in the company access confidential data without anyone knowing about it? Can a user change the clock settings on his PC in order to gain unlimited trial time for your software? Can an admin user see personal data about the users managed by him? Maybe this data isn't required in order to do his work?

So, to cut things short, there are many easy-to-find security problems, and you have only to look. But, before starting to wander around in that dark forest, perhaps it is best to describe the security properties that we want to ensure in the program. Usually, when measuring software security, we speak about six properties (there are some other lists, but I like that one), and sost security related attacks will hinder one (or more) of these properties.

·        Authentication – the ability to identify someone (or some process) is who he claims to be.

·        Integrity – The system's ability to ensure that data, either in transit or in storage, was not changed by an unauthorized entity or was corrupted.

·        Non-Repudiation - No one can perform an action and then claim "I didn't do it", since the system is able to provide credible evidence both action and actor (what was done, who did it)

·        Confidentiality – Information is available only to those allowed to see it.

·        Availability – the system can be used by its legitimate users any time where it is expected to work.

·        Authorization – The system will allow a user to perform only actions that are permitted to that user.

The nice fellows in Microsoft came up with a series of threat patterns that targets each item in the above list, and even gave us a cool acronym to remember it (this, by the way, is the reason the list above is ordered in such a way): STRIDE.

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of service

Elevation of privilege

One thing I will not deal with here is the property called "safety" – the property that gives us confidence that the product won't blow up in someone's face. It's not that it is not important, it's just that it is relevant only to certain types of products, and I don’t understand much in this issue.

Anyway, after we are all a bit more comfortable around software security properties, I want to wrap things up by presenting three cases out of the report we got. My intent in quoting them is to show how simple they are and how easily they can be found.

I want also to note that while some of these may look negligible, or even silly, they all have a significant cost to our product – both in terms of effort we had to invest to fix these things in a schedule that meets our client's expectations, and in terms of reputation of our product: when I see such vulnerabilities I assume that those who wrote the software didn't care much about information security, and that's not something we want our customers to think.

So, that in mind – to the list:

1.    A user can perform an action that shouldn't be available to him:
In our system we have a group admin user that can create other users. All users created are in the same group as that group admin. However, when the group admin edits the user's properties, he can change its group to a different one.
The nice thing about this vulnerability? It does not require "hacking" of any sort, just legitimate user actions.

2.    Reflecting input back to the user:
we had a nice error message when a user could not login – it was something in the line of "Login attempt failed for user X"
Now, imagine a scenario where we get the username "X, please call 1-800-1234567".The user will see that in his error message and will call the attacker, that will now try to extract the password from the user. Changing the username from X to "X, call me" is fairly simple to achieve by injecting a simple JavaScript to the user (thus achieving a "man in the browser" attack) or routing the browser traffic via a proxy.

3.    Not checking for permissions on server side:
Really, this was what embarrassed me most. It's in the first page of just about any guide you'll find on dealing with implementing secure software.
What we had was a simple scenario – in a certain user in our application had the permissions to view a page, but not to edit it. The edit button was properly removed, but if someone would click "view" and then stop before sending the request (using a tool such as fiddler) and change "view" into "edit", we would grant access to the edit page.