Saturday, November 14, 2015

תיעוד בדיקות - למה זה טוב?

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. בקרה על מה שאני עושה - כן, זה קצת דומה לתקשורת, אבל אני נעזר במערכת ניהול הבדיקות שלנו כדי לוודא שמה שתכננתי לעשות אכן בוצע ושלא שכחתי שום דבר תוך כדי ביצוע הבדיקות עצמן. 
מהמטרות האלה נובע גם אופי מקרי הבדיקה שאני כותב - הם יהיו מפורטים למדי: משתני סביבה, טבלאות במסד הנתונים, התנהגות צפוייה וכיוצא באלה, אבל הם גם יכילו כותרת שתסביר מה המטרה של כל צעד.

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

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

Friday, November 6, 2015

בשביל מה אני צריך כלי לניהול בדיקות?

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?