בשביל מה אני צריך כלי לניהול בדיקות? 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?