תסריטי בדיקה STD

[etit2019]

תסריטי בדיקה STD

היי לכולם

איפה אני יכולה למצוא דוגמאות לתסריטי בדיקה גם בעברית וגם באנגלית?

אשמח לעזרתכם
תודה רבה!

 

[איגור שפירו]

תסריטי בדיקה

תסריטי בדיקה של מה בדיוק ?
תסריט בדיקה של אתר אינטרנט אחד יהיה שונה לגמרי מתסריט בדיקה של אתר אחר ושונה ממש מתסריט בדיקה של דיסק USB
&nbsp
משותף בין כולם יהיה פורמט: תעשה משהו - תבדוק שקרה מה שהיה צריך לקרות ןכך עד להשלמה של הפעולה שרוצים לבדוק

 

[etit2019]

היי איגור

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

 

[עמית ו]

למשל

חיפוש בגוגל מעלה דברים כאלה https://geteasyqa.com/qa/best-test-case-templates-examples/
&nbsp
לא טרחתי לחפש בעברית, כי בשום מקום שמכבד את עצמו לא כותבים בעברית (עברית יש בכמה משרדי ממשלה ואולי בצבא, טרם שמעתי על אחרים).
&nbsp
מה שכן, המסמכים האלה הם בערך הדבר הכי מיותר שאת יכולה ללמוד - למעט בתעשיות עם רגולציה גבוהה במיוחד לאף אחד אין זמן לבזבז על הדברים חסרי הערך האלה.
כרגע, בכל מקום אליו תגיעי יש את הדרך בה הם עובדים - חלק מהמקומות כותבים כלום, חלק יפרטו ברמת כותרת, חלק אולי יעבדו עם test charters. מה שמשותף לכולם הוא שכולם יעשו את המקסימום כדי לכתוב רק את מה שבאמת חייבים כדי לתפקד, כי כמות הזמן שמבוזבזת על פירוט יתר ועל מסמכים "מסודרים" שאף אחד לא קורא היא מוגזמת בעליל.

 

[איגור שפירו]

עמית צודק

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

 

[etit2019]

אז בשביל שאני אבין

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

 

[איגור שפירו]

עיקר התפקיד

אני אנסה קצר. ואתמקד בבדיקות תכנה. (ל- QA לדעתי ,יש משמעות יותר רחבה)
מה בודק תכנה צריך לדעת:
1. 100% הבנה של המוצר כמערכת שלמה שהוא בודק. כולל שימושים אפשריים .
2. 100% הבנה של כל featur במוצר ויחסים בין features .
3. הבנה של איך הסביבה הרלוונטית למוצר עובדת (חומרה, תכנה, פרוטוקולים ... )
לדוגמה בשביל לבדוק אפליקציית מובייל צריך לדעת גם ANDROID וגם איך
האפליקציה קשורה לעבודה של טלפון עצמו.
4. יכולת נתוח של מערכת והבנה של הדישות שצריך לבדוק
5. שליטה בכלי בדיקה הרלוונטים לבדיקה של המוצר.
6. תכנון מקרי בדיקה במטרה לתת כיסוי מקסימאלי של כל דרישה נבדקת
(קשור ליכולת ניתוח מערכת)
&nbsp
אפשר כנירא להמשיך אבל זה הכי חשוב לדעתי
&nbsp

 

[עמית ו]

זה נושא למלחמות דת לא מעטות

אישית, אני מאוד מתחבר לגישה של Alan Page שמגדיר את תפקיד הבדיקות כמשהו שנועד להאיץ את תהליך הפיתוח (או, במילים שלו - Accelerate the achievement of shippable quality) -וכן, חשוב לשים לב שהוא אומר "בדיקות" ולא "בודקים".
אבל, זה נושא למתקדמים, ודורש אנשים עם לא מעט ניסיון, וגם ארגונים שבשלים למעבר כזה.
ארגונים ששוכרים בודקי תוכנה ייעודיים, בדרך כלל לא נמצאים במקום הזה (ולמעשה, מעט מאוד ארגונים נמצאים שם), אבל גם כאן, יש רמות בגרות שונות של ארגונים -
בארגונים הגרועים יותר, הכישורים שתידרשי להראות יהיו "לעשות מה שאומרים לך" - למלא דו"חות הרצה ולכתוב תוכניות בדיקות ברמת פירוט משתנה, לקבל פיצ'רים ולייצר מהם דיווחי באגים שטחיים.
כישורים רלוונטיים: הנכונות לקבל שכר נמוך, מוכנות לבצע את המשימות שלאף אחד אחר אין כוח לעשות, היכולת להוריד את הראש ולספוג הרבה שטויות מאנשים. (ורק למקרה שלא הייתי ברור - אני ממליץ בחום להימנע ממקומות כאלה).
&nbsp
בארגונים קצת יותר מתקדמים, תידרשי להבנה טובה של המערכת כדי שתוכלי לתרום גם במהלך תכנון המוצר ואיסוף הדרישות ולא רק "הנה פיצ'ר, תבדקי לי אותו"
כישורים נדרשים: הבנה טובה של מערכות ושל מערכות תוכנה בפרט. "למידה מהירה" (כלומר - היכולת ללמוד משהו בצורה שטחית ולהגיב, ואז מתוך התמונה הכללית הזו ללמוד את הפרטים) ויכולות תקשורת.
&nbsp
השלב הבא הוא שלב בו עבודה יחד עם המפתחים נפוצה - גם אם המשימות נפרדות, עדיין תבואו אחד לשני עם בקשות עזרה (וכן, אם את לא יודעת לקרוא קוד, עכשיו זה זמן לא רע להתחיל ללמוד - לא חייבים לדעת לתכנת, אבל חייבים לדעת לקרוא קוד).
כישורים נדרשים - היכרות עם "איך תוכנה עובדת", יכולת תקשורת אישית גבוהה, כישורי חניכה (כי גם כשאת מגיעה כבודקת תוכנה שעכשיו התחילה את הקריירה, את "מומחית הבדיקות" בצוות, אם אין בו בודקי תוכנה אחרים), ניהול סיכונים (או לפחות, לדעת לדבר בשפה הזו)
השלב האחרון הוא השלב בו אין בודקי תוכנה מתחילים, כי צוות הפיתוח מכיל את כל הידע הבסיסי הנדרש, והתועלת שלהם מבודקי תוכנה היא בהתמחויות ספציפיות (אבטחה, ביצועים, חווית משתמש) או ביכולת החניכה כדי לשמר את הרמה בצוות.
&nbsp
&nbsp
&nbsp

 

[halperin]

פה תמצאי מסמך דוגמא שהעליתי לטובת הקהילה:

פה תמצאי מסמך דוגמא שהעליתי לטובת הקהילה:
https://www.facebook.com/groups/IL.Testing.QA/permalink/1247726735293251/
וכן - אני מסכים עם החברים שאמרו כי המסמך עצמו והפורמט שלו פחות חשוב, היום גם מי שכותב מסמכי בדיקה לעומק כזה או אחר עושה זאת ע"ג כלי ניהול ולא במסמך וורד (ורבים עדיין עושים זאת - בהמשך עם הניסיון כנראה תוכלי להחליט איזו רמה באמת עוזרת לתהליך ואיזו סתם מאיטה אותו, ויש יתרונות לכאן ולכאן - כלומר צריך ללמוד למצוא האיזון)
מתפלא שאיגור לא כתב - אבל הכלי החשוב ביותר של הבודק זה "המוח"...
המסמכים וכלים אחרים עוזרים לעיתים להוביל את קו המחשבה, לנהל את ביצוע הבדיקות, לזכור נקודות חשובות שלא נרצה לפקשש...