מבוא· החלט· נתח· ארגן· שפר· סקירה· תחזוקה·
QA Homepage· עידכוני חדשות· מקורות אודות QA· QA קבוצת עניין· QA קבוצת עבודה· אירועי QA·
מאמר זה הינו חלק מעבודת קבוצת עניין של W3C לאבטחת איכות . אנא שילחו פידבק כללי לרשימת הדיוור public-evangelist@w3.org של הארכיון הציבורי או פידבק אישי לקרל דובוסט ב- karl@w3.org.
מחבר המאמר מודה לאנשים אשר הקדישו מזמנם להערות ורעיונות.
בין אם אתה מנהל, מפתח אתרים, מנהל שיווקי או מנהל תקשורת, או אולי אפילו ווב מסטר עצמאי, בודאי קראת על האינטרס בתקנים של הרשת ממקורות רבים. הבנת כי עמידה בתקנים תתרום לאתר הרשת שלך בחיסכון העלויות, בהקלת הניהול ובהגדלת הרווח, ולכן החלטת להחליף – ולשדרג את האתר שלך לעמוד בתקנים.
אולם לרוע מזלך לא מצאת מדריך המסביר את התהליך של היכן להתחיל, כיצד לארגן מעבר זה של האתר שלך להיות תואם תקנים. אתה עלול לחשוב שאם האתר שלך גדול במיוחד, לא ניתן לעמוד במשימה זו. אם אינך בטוח מהם התקנים של הרשת, אנו ממליצים שתקרא מה המשמעות האמיתית של התקנים של הרשת [WEB-QUALITY] , כיצד להשיג ולפתח אתר איכותי [REQ-WEBAGENCY] ומדוע אתר נגיש [WAI-PROFIT] הינו ריווחי.
השיטות שמוצעות במסמך זה הינן מתאימות לאתרים מכל הגדלים; זה יתאים לצרכיך בין אם אתה מנהל אתר עצמאי, אתר של עסק קטן או של תאגיד גדול.
אנו נדריך אותך דרך כל צעד בנפרד – כך שתוכל לבצעם בנפרד – מניתוח המצב הקיים באתר שלך ועד לארגון האתר מחדש. כל אחד מהצעדים הללו תוכנן כיחידה עצמאית, וכך ניתן לבצעם בזמנים שונים, ברמות שונות, ע"י אנשים שונים ללא קשר לניסיונם אך בהתאם לתזרים עבודה.
גדול או קטן, האתר שלך צריך לעבור הערכה ראשונית כנגד התקנים; ובודאי תמצא כי מספר לא מבוטל של דפי רשת אשר אינם תואמים לקריטריון האיכות אשר בחרת לאתר שלך.
זמן את צוותי התקשורת, טכני, שיווק והנהלה ביחד כדי ליצור רשימה של כל הדברים שהייתם מעוניינים להעריך ולבדוק באתר שלכם. בשלב זה אין צורך לקבוע קדימויות לגבי כל מה שאתם מעוניינים לתקן, אך אנו ממליצים לכם לפחות לבדוק התאמה לתקניות הקוד (HTML, CSS), תאימות הנגישות ותאימות לבין לאומיות (internationalization) של האתר שלכם. תמצא בהמשך המאמר הסברים על השיטות.
מאמר זה מציג שיטה לשיפור האתר שלך בהתאם לתקנים של W3C, אך אתה מוזמן להשתמש באסטרטגיה זו גם לדרישות אחרות בהם אמור לעמוד האתר שלך. אנו מציעים רשימה זו:
לפעמים לך או לצוות שלך אין את הכישורים או ההבנה אודות הבעיות באתר שלך; אם זהו המצב – בקש עזרה. הזמן מומחה בנגישות או ב"אינטרנסיונליזציה" כחלק מהצוות. למשל בקשר לנגישות (באיזו מידה יכולים אנשים מאתגרים לגשת לאתר שלך) , תוכל לבקש עזרה מעמותה מקומית, כגון המרכז לעיוור בישראל (עמותת נגיש לבדוק במייל) – ברוב המקרים הם ישמחו לעזור לך. אם הינך חלק מארגון גדול, הרי שרוב הסיכויים שישנם אנשים מאתגרים בחברה שלך. שאל את משרד כוח האדם והצע את השתתפותם בפרויקט זה.
עכשיו שאתה יודע מה אתה מעוניין לבדוק, אתה צריך להגדיר מהם הבעיות הקיימות כרגע באתר. דרך טובה לעשות זאת היא ראשית ליצור רשימה של כל ה- URI השייכים לאתר שלך. אין זה תהליך מסובך – תוכנה פשוטה שעוקבת אחרי קישוריות של לינקים (spider), ומוסיפה אותם לקובץ טקסט (שורה לכל URI) יספיק.
יתכן והטכנולוגיות שמשמשות את האתר שלך אינם נגישים ע"י מנועי spider ; זה כשלעצמו יכול להיות דרך לזיהוי מספר הדפים באתר אשר אינם נגישים. באופן בסיסי תרגיל זה יגלה הדפים שלא ניתנים לשילוב באינדקסים של מנועי חיפוש. משמעות הדבר כי אתה חוסם בצורה מעשית תנועה נכנסת לאתר שלך.
אחרי שהכנת את הרשימה, ניתן להשתמש ב- LogValidator [LOG-VALIDATOR] אשר הינו תוכנה שתוכננה באופן ייחודי לעזור לך בתהליך הבדיקה. ה- LogValidator לוקח רשימת URI ומנתח אותם על פי המודול אשר אתה בחרת לטעון כאשר אתה מתחיל את הבדיקות. (זה יהיה חלק מהעבודה של הצוות הטכני שלך, דון עמם כיצד להטמיע אותו לתצורה של האתר שלכם.) עבור כל URI, התוכנה תבצע סידרה של בדיקות ותיתן לך תוצאות בהתאם.
אחרי ניתוח ראשוני זה, יהיה ברשותך מפה של מצב האתר שלך, ותוכל לאמץ אסטרטגיה לארגון העבודה הנדרשת לתיקון הדפים השגויים. יתכן ותגלה מספר עצום של דפים אשר אינם עומדים בקריטריונים שקבעתם. לדוגמא, כל דפי האתר שלך עלולים להיות לא תקינים ב- HTML או XHTML. אך אל דאגה – אלה בעצם חדשות טובות! מדוע? מפני שאם אתה משתמש במחולל תבניות (templating engine) או במערכת ניהול תוכן (CMS) כדי ליצור את האתר שלך, המשמעות היא שיש לך בוודאות טעות בתבניות שלך.
הפיתרון פשוט; תקן את התבנית והרץ את הבדיקה מחדש; ייתכן ותמצא כעת פחות טעויות, אולי אף לא תמצא טעויות כלל. אם אינך זה שפיתח את מחוללי התבניות, בקש ממי שיצר את ה- CMS עבור האתר לתקן זאת בהתאם. בעתיד, כאשר יבוא הזמן לתכנן מחדש את האתר שלך, השתמש בהמלצות אשר במסמך רכישת תאימות תקנים לאתרי הרשת [REQ-WEBAGENCY ].
אם עדיין יש לך טעויות באתר שלך אחרי צעד זה, אל דאגה – מטרת מדריך זה היא לעזור לך לתקן אותם.
יתרון נוסף מהצעד הראשון הוא שאתה מקבל מושג ממשי לגבי כל דפי האתר שלך, כלומר שאם תרצה להזיז דף מסוים, או למחוק חלק מהאתר, יהיה לך מושג טוב יותר כיצד לכוון מחדש את המבקרים לדפים החדשים ומכאן לא להפסיד תנועה הבאה מקישורים חיצוניים (כגון קישורים הבאים מאתרים אחרים או מנועי חיפוש). זכור,URIsמגניבים אינם נשברים.
יש לך כרגע רשימה של כל דפי האתר אשר אינם תקינים, או שיש בהם בעיות אחרות או טעויות. זה לא משנה אם הרשימה ארוכה או קצרה, זה לא ישנה את השיטה המוסברת כאן. העיקרון הראשון פשוט: "אל תתקן! שפר – ארגן את העבודה שלך"
אין זה כלל הכרח שתתקן את כל האתר שלך בפעם אחת, משתי סיבות:
בנוסף, אל תנסה לתקן טעות מקטגוריה ספציפית בפני עצמה בעוד אתה מותיר את כל הבעיות האחרות עד אשר תסיים עם זו. לדוגמא, אתה מעוניין שהדפים שלך יהיו תקינים מבחינת ה- HTML, וכן שיהיו נגישים – תקן אותם בו זמנית. אם תתקן אותם אחד אחרי השני, במחזור עתידי של תיקונים, אתה עלול ליצור בעיות והדבר ישפיע בצורה שלילית על התוצאות הטובות של התיקון הקודם.
מסקנה: אל תתקן במכה אחת, ואל תתקן בעיות במחזוריות – שפר את התהליך שלך.
המפתח להצלחה בשיטה זו הוא להישאר מציאותי כאשר מדובר בהחלטות, ולהבטיח שההחלטות הללו יניבו תוצאות יעילות. אם אתה מעוניין לשפר את דפי הרשת שלך, אתה חייב להגדיר מסגרת זמן עבודה לכל הבעיות שהתגלו לכל עמוד ועמוד. תנסה על מדגם מדפי הרשת עם בעיות זהות לבעיות באתר שלך, והערך את תאימות הכישורים של אנשיך ומשאביך בתוך מסגרת תזרים העבודה של האתר שלך.
מרגע שהגדרת את כמות הזמן הנדרשת עבור מספר דפים, תוכל להחליט באופן מדויק יותר כמה משאבים וכוח אדם לצוות למשימה, כמו גם כמה דפים תוכל באמת לתקן ביום.
אנו ממליצים לבצע את התיקונים על בסיס יומי ולא על בסיס שבועי/חודשי. יהיה זה פשוט יותר עבור האדם שאחראי על משימה זו לקבוע את לוח הזמנים עבור תהליך זה, דבר שייקח פחות זמן לתקן על בסיס יומי מאשר שבועי. זה קל יותר ומקל מהעומס לתקן 5 דפים ביום מאשר 25 דפים ביום אחד בשבוע.
הנהג ישיבות קבועות עם הצוות שאחראי ליישם את המשימה; כדי לשמוע את דעותיהם, טיעוניהם וניסיונם. זה יעזור לך לקבוע אם הבעיות הכרוניות נובעות מה- CMS, או מתהליך שמשמש לעריכת דפי הרשת שלך. אתה תוכל לשפר את התהליך ואיכות הכלים בהם אתה משתמש בו זמנית.
לאחר זמן מה, ועם הניסיון שתקבל מהטמעת שיטה זו, אתה תוכל לקבוע אבני דרך. לדוגמא, 50% מהתנועה הנכנסת לאתר מגיעה לדפים העונים לקריטריונים שבחרתם. כאשר מטרה זו התממשה, תוכל למנף ל- 60% וכן הלאה. באשר תהיה הבחירה של מה לבדוק או מה להשיג, דאג שיהיה זה הגיוני וקטן; שיטה זו הינה בעשייה מתמשכת, אך תוך התקדמות ושיפור בר השגה.
כדי שיהיה זה פרויקט מוצלח באמת, אתה חייב לשתף כל מי שיש לו חלק בתהליך ההוצאה לאור במשימה זו. הבנת הכלים, השיטות שנמצאות בשימוש יעזרו לך לקבוע מה מקור הבעיות – האם זו בעיה בכלי, או האם יש בעיה עם האדם המשתמש בכלי? כאשר כלי עריכה (authoring) יוצר טעויות בדפים שלך, כדאי לאסוף את ההערות, ולנהל משא ומתן עם יוצרי הכלים כדי שהם ישפרו את התוכנה שלהם. בפרט זה נכון עבור חברה גדולה היכן שיש משתמשים רבים; זוהי דרך חכמה יותר להבטיח שיהיו שיפורים.
פרסם את השיפורים – לפחות בתוך הצוות, אם לא באופן ציבורי. זה יראה את ההתקדמות שלכם ויעודד את כולם להמשיך. אם זיהית את הבעיות אשר קיימות במערכת ההוצאה לאור, אתה יכול רק לשפר מכאן.
ה- LogValidator [LOG-VALIDATOR], אשר כבר הוזכר לעיל, יעזור לך לשפר את האתר שלך ע"י זיהוי הדפים הבעייתיים. בברירת המחדל, כלי זה תוכנן לבדוק בהדרגה את תקינות ה- HTML במסמכים. העיקרון על פיו הכלי עובד באופן בסיסי הוא ישיר במהותו: הכלי מקמפל את קובץ הלוג של השרת רשת ומאתר את הדפים הפופולאריים ביותר (הדפים עם מספר כניסות של הגולשים הגדול ביותר על בסיס יומי), ולוקח N דפים מתוצאות המיון (כאשר N הוא מספר שאתה מגדיר) ושולח אותם לבדיקת תקינות תווית (Markup) של W3C. תוצאות הבדיקה ישלחו אליך.
למה זה טוב לך? ובכן תוכל לתקן תחילה את הדפים הפופולאריים ביותר, כמו גם הערכת איכות האתר שלך תוכל להתבסס על דפים אלו – ללא צורך להסתמך על כל דפי האתר.
ל- LogValidator יש ארכיטקטורה פתוחה ומודולארית כתובה בפרל (Perl) כך שתוכל לפתח מודולים שהינך זקוק להם כדי לשרת את מטרותיך. לדוגמא, אתה יכול לפתח כלי לבדיקת האיות, או לפתח מודול הבודק האם המידע בלוגו תקין בדפים שלך, או אולי תחליט לפתח מודול שבודק את תקינות הלינקים באתר שלך. זהו כלי שמותקן בקלות והינו חלק מהארכיון ה- CPAN.
ישנם אינסוף אפשרויות, כך שרצוי מאוד להישאר מציאותי במושגי היעדים שלך.
לאחר אימוץ ה- LogValidator, ישנם מספר דרכים להמשך ניתוח התוצאות שנשלחו מה- LogValidator. לדוגמא, אתה יכול להגדיר רשימת דיוור פנימית לצוות בדיקת איכות האתר עם רשימה יומית של URIs אשר זקוקים לטיפול, ועל הצוות יהיה לטפל בבעיה או לדווח אם המקור לבעיה הינו אחר.
שיטה זו המוצגת כצעד אחר צעד עוזרת לשמור על איכות האתר שלך, אך עדיין עליך לבדוק על בסיס קבוע האם הבעיות חוזרות וצצות שוב.
אחת לכמה זמן (כל שלושה חודשים לדוגמא), יש להריץ בדיקה מלאה, כך תדע אם הייתה התקדמות באיכות האתר שלך, וכמו כן תוכל כך להגדיר מהן הבעיות הנובעות משימוש במחולל התבניות שלך. זה גם יעזור לך לעמוד במטרות שהצבת בתחילת הדרך. אם איכות האתר שלך אינה משתפרת, יש משהו שגוי בתהליך שאתה מבצע.
בסופו של דבר התהליך נותן פידבק על העבודה של הצוות שלך, האנשים המעורבים במאמץ זה, ומראה את ההתקדמות שנעשתה. אט אט תרכוש ניסיון אשר יהיה יקר ערך לארגונך. במקביל להרצת הבדיקה, הכן רשימה של כל הדברים שטופלו ופרסם אותה. זה יהפוך למקור מידע מעודכן לגבי איכות האתר שלך.
לעיתים קרובות ישנם נהלי סגנון (style) בחברה אשר מגדירים את צבעי התבנית והלוגו. הוסף לנהלים הללו שיטות פשוטות אשר יעזרו לאנשים לשפר את האתר כאשר מזהים טעות.
השיטה המוצגת כאן הינה דינאמית ואין להתייחס לה כתורה מסיני; השיטה צריכה להיות מותאמת לצרכיך. אם בתהליך ההוצאה לאור ישנם דרישות שאינן רלוונטיות יותר, או דרישות חדשות נוספו, יהיה זה מן ההכרח להתאים את תהליך ההוצאה לאור למצב החדש, ומכאן גם תהליך בדיקת האיכות יעבור עדכון.
הפתרון להערכת ושיפור האיכות אשר הצגנו בפניכם מחולקת לרכיבים אשר אינם משפיעים אחד על השני, מכאן שניתן להסיר רכיבים שאין בהם צורך יותר, או להוסיף חדשים היכן שצריך.
יכול להיות כי תמצא בעיה אשר אין לה פתרון מעשי מיידי מפני שאין ביכולתך לתקן זאת בעצמך. לדוגמא, יכול להיות שהינך משתמש בכלי להוצאה לאור, כלי עריכה (authoring tool) אשר מחולל קוד לא תקני. ניסית לתקן זאת בדרכים רבות, אך דבר לא עזר. חשוב ביותר לאסוף מידע זה ולשלוח אותו לחברה שפיתחה את כלי זה, לא כאיש פרטי, אלא חתום בשם החברה שלך. אתה מייצג פלח מהשוק, כך שחברות שמפתחות כלים אלו יטו לך אוזן קשבת.
כדי לשמור על איכות נאותה באתר שלך, תצטרך לתגמל את היוצרים (authors) שלך כדי לעזור לאלו המתקשים יותר. לא יראו את הפירות מאימוץ השיטה בה בחרת. הזמן אותם לשלוח פידבקים ודיווחים על בעיות בתהליך, עם הכלים וכו'... זה ישפר את הארגון כולו.
שיטה זו פשוטה ונמצאת בשימוש מזה שנים ב- W3C בנושא ה- HTML, זה עזר לנו לשמור על איכות נאותה של כל דפי הרשת. שיטה זו יכולה להיות משמעותית ויעילה אם תשתמש בה בארגון או בצוות שלך.
תודה לאנשים אשר קראו והעירו מאמר זה: אוליביה טרו , סטפני תרוט , דניס בורדרו ואנשים הנמצאים ברשימת הדיוור הציבורית של האוונגליסטים .
המאמר המקורי http://www.w3.org/QA/2003/03/web-kit תורגם ע"י אורי ברקוביאר, לפרטים על דו-כיווניות ועברית אפשר לפנות ל אלינו.
Created Date: 1-6-2003 by O.Bercovier >
Translated from http://www.w3.org/QA/2003/03/web-kit