על חשיבותה של שגרה. Keep your routine!

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

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

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

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

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

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

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

Here and there I come across a recommendation that can be summed up as "try to vary the way you would usually do things in order to make you tests more effective" (For instance, one might check tip #71 in the linked PDF). Up until today, this sounded to me like a perfectly reasonable advice - if I change my habits I will get to places in the code where I have not yet visited before, what can be wrong in that, right? 

Obviously, such a reasonable and decent rule cannot simply be without a tiny "but.." tagging along, and today I stumbled upon a nice example of it. The story is as follows: I was testing a new feature on our product, the feature revolved around permissions granted to various types of users to some new area in our system. So I created the users I needed, an off I went to test the feature. 

Using the first user, everything seemed just fine. I gave it a little effort when I tried to get around some of the limitations, trying to see whether I can get anything interesting out of it. Then my phone rang, which lead to me sitting with a team member and helping him to understand an aspect of a task he was doing - Something I considered to be more urgent than my original task. 

Returning to my test 15 minutes later, I logged in a the second user, checked that things looked OK, when a thought crossed my mind - I did not see the new password selection page! Normally, when a user is created in our system by an admin (that's the only way to create a user of the type I wanted), the user is required to change its password upon the first successful login. 

Hold your horses now... am I certain I did not see the page? could it be I just filled up what was needed and then forgot? this piece of logic exists for years in our system, probably over a decade, and no change could have affected it. This is where my habits proved useful:   logout, re-login, o.k. - I wasn't imagining things. the password is still my regular 1st password for such users. retracing my actions a bit helped me find the one extra step I did to cause this issue. five more minutes and I was able to confirm that this issue exists in our system well over a year (and probably closer to ten years). Oops. Remember my thumb-rule about information security problems?
On my way home I gave some thought to this whole affair. I have nearly missed the fact that the change password page did not appear. Normally, I would have ignored such a glitch and assuming that since it's already the end of the day, I have probably filled the page without noticing, and besides - This was only a step in my way to what I really wanted to test. had the users existed before I wouldn't even bother going through this whole process. However, because I was performing my actions on sort of an auto-pilot mode this deviation from the standard pattern was very visible to me - it broke my routine.  Also, since I use the same passwords for first & 2nd passwords I was able to easily (and quickly) validate I wasn't imagining things. 
So - what is my conclusion of this short anecdote? While I still think that a versatile performance of similar tests can be a good thing, I learned to take new ideas with a pinch of salt: if up until today I was convinced that variation is always a good idea and the main reason I don't do it is just me being lazy and falling into habits, now I'm not sure I want to avoid routines all of the time as I have found that they help me to notice deviations from standard behavior.  In fact, the way I see it now (at least, until a better thought will spring to mind), I think it may be helpful to divide the actions I do while testing into two distinct groups: the feature I'm testing and all of the peripheral actions required for this test.  For the first part, I think trying to be as divers as possible is great. it uncovers new behaviors of the software and teaches me a lot more about the feature under test. For the peripheral actions - setup, cleanup, stuff that are just there on the corner of my eye, I think sticking with my routine is preferred. True, it might miss a bug or two, but I'm not testing my whole software at once. I will defocus and allow myself to be sidetracked if I'll stumble across something suspicious, but my main goal is to test the feature I was set out to test. I don't have the time to go looking for problems in *every* dusty corner of my application, so why not leave the variations to times when I'm performing tests on that part? This way I can see problems even though I do not concentrate on that particular piece of software. In addition, I think one can consider this routine as a sort of mise-en-place that will speed up your testing,