שבזמן נתון, ה-SUT, עובד תחת: - קינפוג* מסויים - בסביבה מסוימת -בסימולציה של מידע מסויים מה שחשוב לזכור: צריך להחליט מראש איזו קונפיגורציה תבחר, ולתעד את מה שנבחר, את התוצאות, ואת מה שלא נבחן. *קינפוג - נתינת ערך לפרמטרים, קונפיגורציה של המערכת
1.The process of executing a program with the intention of finding errors.
2.The purpose of testing is to discover errors. Testing is the process of trying to discover every conceivable fault or weakness in a work product.
3.Process of evaluating a system or a component to determine whether the product of a given development phase satisfies the conditions imposed at the start of that phase.
הערה: כשכתבתי את הפוסט הזה ואחרים, לא הייתי מודע ל-Agile למיניהם. כך יוצא שהפוסט הזה אנכרוניסטי. הוא תמיד יכול לעזור במקרה שעובדים ב-Waterfull או לקבל רעיונות, אבל רק שתדעי שהוא לא מייצג את המצב הנוכחי.
יש שני סוגי תהליכי פיתוח ראשיים. אני לא אומר שיש הרבה מקומות שעובדים בדיוק בשיטה זו או בשנייה, אלא שאלו שני דגמים לוגיים ויש להם הרבה ניואנסים. הראשונה היא מודל מפל המים. שם הפיתוח הולך צעד-אחרי-צעד: דרישות, עיצוב, יישום, אינטגרציה ובדיקות. השנייה נקראת המודל הספירלי, ר' תמונה. כאן יש פיתוח של שלב א', בזמן זה שלב ב' מפותח וכו'. אני אדבר על תהליך סטנדרטי, שמהווה בסיס נח להתחיל איתו, ותואם בגדול את המודלים שפגשתי במציאות. יש להדגיש שהזרימה היא לוגית וב"מציאות" יש אינטראקציה בין הגורמים השונים לאורך כל חיי הגרסה. שלב א' - החלטה על הפיצ'רים שיש להוסיף למוצר: אחריות: אנשי השיווק. 1. מסמך דרישות של השיווק. תפקידם הוא להכיר את הלקוחות הקיימים ו/או הפוטנציאליים של המוצר, להבין את צרכיהם, ולספק דרישות אשר יובילו למוצר המסוגל לתת מענה לדרישות אלה. הדרישות של השיווק נקראות לעתים MRD, כלומר marketing requirement design. אלו דרישות כלליות ביותר, שאומרות שאנו רוצים להוסיף למוצר יכולות כאלה וכאלה. לא מענין את השיווק איכן יממשו את היכולת החדשה, כמה זה מסובך וכמה זמן זה יקח, לפחות לא בשלב הראשון של הצבת הדרישות. 2. בסיום כתיבת המסמך יש ישיבת רוויו, ביקורת, בה המסמך מוצג ע"י כותביו. זה המקום של כל הגורמים להתעדכן ולתת הערות. שלב ב' - תכולת הגרסה:אחריות: אנשי השיווק 1. קבלת EE, efort estimation, על כל פיצ'ר. 2. החלטה על תכולת הגרסאות בהתבסס על: EE - אם הפיצ'ר פחות חשוב וזמן הפיתוח ארוך אפשר לדחות. וכמובן דרישות הלקוח, סיכויי הקבלה בשוק, עד כמה השוק צמא לזה וכד'. שלב ג' - אפיון טכני:אחריות: מהנדס המערכת. נכתב אפיון טכני ע"פ ה-MRD, אלא שכאן זה לא ברמת "יכולת לשלוח מיילים" לדוגמא, אלא: שרת המייל יוצב ב-DMZ ויתחבר לשרת X. המסמך גם נקרא SysRD או SysRS תלוי בחברה בה אתם נמצאים. הוא יכלול גם תרשימי זרימה, לוגיקה וכד'. בסיומו הוא מחולק לאנשים הרלוונטים, כולל ממערך הבדיקות. בד"כ אנשי פיתוח, מהנדסי מערכת, לקוחות במקרים מסוימים, מנהלי תהליכי איכות וכד'. כבר כאן אפשר ורצוי לשלוח הערות. לאחר מכן יש ישיבה בה עורכים בחינה של המסמך, תוך כדי העלאת בעיות הקשורות אליו, דברים חסרים, עודף, משמעויות מערכתיות וכד'. כאן, בשלב ג', התפקיד של מהנדסי הבדיקות מתחיל. על מהנדס הבדיקות לשלוט במסמך, להבין את הסיכונים שיש בו (לניהול סיכונים אקדיש פרק מיוחד, כרגע הכוונה ליישומים מורכבים או בעלי חשיבות גבוהה) ולהתריע, ולראות איך כל תוספת תשפיעה על המערכת, ולגלות סתירות לוגיות, נקודות לא ברורות או מפורטות עד הסוף וכד'.במילים אחרות, כאן שלב הבדיקות החל. אמנם אלו בדיקות של מסמך (או אפשר לקרוא לזה מעיין dry run) אך החשיבות כאן היא אולי מהקריטיות ביותר, שכן כל גילוי של באג כאן יחסוך לחברה עשרות מונים מאשר הגילוי במעבדת הבדיקות שלא לדבר אצל הלקוח... לאחר מכן מהנדס המערכת מתקן את המסמך ושולח לכולם לאשרור. בסוף השלב הזה צוות מהנדסי הבדיקות כבר מוכן להתחיל כתיבה של מסמך הבדיקות. שלב ד' - מסמכי פיתוח: אחריות: מהנדסי תוכנה. זהו כבר אפיון ברמה של פונקציות שישתנו, באילו טבלאות ייכנס המידע, אילו פרמטרים משפיעים על היישום ומה הם ערכי ברירת המחדל ועוד. המסמכים נקראים SID. לאחר שהושלמו הם יעברו ביקורת טכנית. מהנדסי הבדיקות בסוף השלב הזה אמורים לסיים את כתיבת מסמכי הבדיקות ולעבות אותם בהתאם למסמכים אלו. גם את מסמכי הבדיקות יש להעביר לביקורת הגורמים הטכניים (פיתוח, מהנדסי מערכת, על כך בהמשך בהרחבה). שלב ה' - הפיתוח: אחריות: מנהל הפיתוח. שלב ו' - בדיקות המוצר: אחריות: מנהל הבדיקות. קבלת המוצר ובדיקתו, עד אשר הוא עובר את ה-exit criteria שהוגדרו מראש
כשאנו מקבלים מוצר תוכנה, נראה לנו ממבט ראשון, מבלי להיות מומחה לתחום, שהיה מישהו שעיצב אותו, מישהו שפיתח אותו, מנהל שיווק ומנכ"ל, ואולי גם יזם. לא בטוח שהמשתמש הממוצע חושב שיש צוותים שבודקים אותו. מצד שני, כשאנו משתמשים בתוכנה הזו, בין אם היא תוכנת עסקים רצינית ובין אם היא משחק, אנו מצפים לכך שהיא תפעל כראוי, ואפילו דורשים זאת. כלומר לא תעשה משהו שהיא לא אמורה לעשות, ותעשה את כל מה שהיא כן אמורה לעשות. בעצם, רף הסבלנות שלנו הוא די נמוך. בעידן בו ניתן למצוא כמעט כל סוג של תוכנה, ולכל תוכנה מתחרים רבים, אחד מהמדדים החשובים שלנו לבחירת המוצר היא האמינות שלו (יחד עם פשטות, עיצוב גראפי, כמות המשתמשים בעולם והפונקציונליות הקיימת). אם התוכנה מתקרשת (קורסת, מ-crash) לנו כל כמה דקות, הכפתורים לא מבצעים את המוטל עליהם, היא נעה באיטיות מרגיזה, פשוט נוריד את המוצר המתחרה. כאן נכנס לתמונה מערך הבדיקות. עליו מוטל לבדוק את המוצר טרם הגיעו לשוק ולוודא פעילות תקינה לשביעות רצון הלקוח. תהליך הבדיקות הוא בעצם (או אמור להיות) הדבר הכי קרוב שיש בין כתלי החברה שדומה ללקוח. תפקידנו למצוא את הבעיות שלקוח ממוצע אמור להיתקל בו: בעיות פונקציונליות, בעיות של מהירות תגובה, בעיות בשימוש מסורבל וכד'. מצד שני על צוות הבדיקות לצאת מנקודת ראות של המשתמש הממוצע ולהיכנס לנושאים בחשובים שמשתמש הקצה בד"כ אינו מבין בהם ולא כלום, אבל במקרה שתקרה תקלה זה יפגע בו מאוד: עניניי security של המוצר, שימור מידע ועוד. בעולם כזה תפקידו של הבודק הוא קריטי. הרבה פעמים הוא זה שמונע זליגה של לקוחות. חיי הבודק אינם קלים:
הוא נמצא תמיד קרוב לסוף התהליך, וכשהפיתוח לוקח את הזמן כי ה-"דד ליין" רחוק, זהו אינו המצב בחדר הבדיקות, והוא בד"כ צריך לספוג את קיצור לוחות הזמנים. לכן עליו להשתמש בכלים כמו ניהול סיכונים ועוד.
הוא צריך למצוא כשלונות של אחרים וכשאינו מוצא זה הופך להיות הכשלון שלו.
עליו להכיר את המערכת כולה, בניגוד למפתחים.
לעתים להלחם במערכת בכדי לקדם פתרון של באג שלא נראה חשוב (בד"כ בשימושיות של המוצר).
עליו להיות פעם משתמש קצה, פעם איש אבטחה ועוד.
למרות זאת זהו תפקיד שאני שמח למלא. ההשפעה שיש לי על המוצר המוגמר, גילוי של באגים חשובים אך חמקניים, הצורך להכיר את כל המערכת ולעמוד בלחצים פשוט עושה לי את זה.
המונח : SEO: Search Engine Optimization לפי בבילון: תהליך בחירה של מילות מפתח כדי להעלות את הדירוג של אתר מבחינת התוצאות האורגניות בעמוד תוצאות של מנוע חיפוש .
מה ה"חוקים" של גוגל?
הרבה מהמידע שלהם בנוגע לאלגוריתם החיפוש נשמר בשו-שו. אין מה לעשות מול זה.
כסף לא קונה מיקום, רק פרסומות קונות מיקום בחלק של הפרסומות.
לפי הפרסום הרשמי לוקח לגוגל לסיים סבב של אתרים כששה עד שמונה שבועות. כלומר שינויים מהותיים יתעדכנו בפרק הזמן הזה
לא תמיד יאנדקסו את האתר שלך, הם אינם יכולים לחזות אילו אתרים יאונדקסו ואילו לא (הם, אלה שכתבו את המנוע לא יודעים? מעניין).
מה אפשר לעשות בכדי לזרז ולודא שאתרך נכנס?
לא בטוח שאפשר לוודא.
הכנס את ה-URL שלך כאן: http://www.google.co.il/intl/iw/add_url.html
הכנס מטה-תגים לאתרך: כותרת, תיאור, מילות מפתח.
גוגל אינו אוהב תג תיאור זהה ביותר מדף אחד.
גם התג הקידוד של UTF8 חשוב, גוגל אוהב אותו.
והדברים הברורים: כמה שיותר לינקים לאתר מאתרים אחרים, כמה שיותר כניסות. כלומר יש כאן מצב קלאסי של מילכוד 22: גוגל יקדם אתגם אם יש לכם הרבה מבקרים, אבל הרבה מבקרים יגיעו אם תקודם בגוגל.
מומלץ לא לנסות "לעבוד" על המערכת. גוגל עלול וסביר שיעלה עליכם ואז לא תופיעו יותר בכלל. כן לגיטימי שכל חבריכם יכניסו לינקים שלכם אצלם וכו'.
איך אני יודע שאני עושה את מה שצריך, ומה קצב האינדוקס? לאחר יצירת החשבון שלך בגוגל, לחץ על הלינק הבא: כלי ניהול האתרים של גוגל היכנס לחשבון, הוסף את אתרך (תצטרך להוסיף לפי ההוראות תג שבעזרתו גוגל יודא את בעלותך על האתר). לאחר זמן מסויים תתחיל לקבל אינפורמציה קריטית לגבי איך שגוגל רואה אותך, ואלי שגיאות עליך לתקן באתר (למשל יותר מדי מילות מפתח וכד').
איך אני יודע כמה נכנסו לאתר? שוב, השתמש בכלי מוסכם (גלומר שיכובד ע"י הכל כקריטריון לכמות ה"היטים"): גוגל אנליטיקס
טיפים נוספים:
אם יש לך יותר מאתר אחד, למשל ישראלי ואמריקני, כדאי לקנות שני דומיינים, למשל: www.mysite.co.il www.mysite.com עדיף שאחד יפנה ל-sub domain בשני, נניח שכל מי שיקליק על: www.mysite.co.il יגיע ל: he.mysite.com ופרסם את הכתובת הזו: he.mysite.com הסיבה: יותר אנשים יבקרו בדומיין אחד וכך יגדל כוחו וציונו בגוגל. אם האתר השני חדש יותר הוא כבר יתחיל בציון של האתר הקיים. אגב מי שיקליק www.mysite.co.il לא יתרום לך מבחינת הנקודות למרות ההפנייה.
אם עברת דומיין, גוגל עלול לעכב אינדוקס של הדומיין החדש. הסיבה היא שהוא יודע שיש תוגן שדומה לתוכן של הדומיין החדש בדומיין הקודם, והוא "חושד" בגנבת זכויות יוצרים. אחרי זמן מסויים הוא כבר "מבין" שהאתר הישן סגור ואז הוא יאנדקס את החדש. אין לי מידע לגבי השארת שני האתרים באוויר...
הייה נגיש: כתובת אתר קצרה (שלא כמו בבלוג הזה) ומתאימה. האם יש למשתמש אפשרות למנוי RSS, מייל? האם הוא יכול לפנות אליך? כפתור הוספה למועדפים. אפשר למצוא כלים כאלה כאן ועוד דברים, מתאים בעיקר לאתרים לא מקצועיים.
"שמועות": - אתר ותיק מקבל עדיפות. - יש מילים שעלולות לעכב אינדוקס, כמו "פורנו" וכד'. לא נראה היגיוני - הקליקו סקס ותבינו למה. - אם תוכן זהה מופיע בכמה אתרים הוא לא יקודם.
