4 – ASP.NET & ADO.NET

ברוכים הבאים לעולם של DOTnet בנושא: ASP.NET ו-ADO.NET, SQL בעמוד הזה יש צילומי מסך עם הסברים שלי בסרטון וידאו לכל צילום וצילום.

להלן סרטון וידאו עם הסבר לכל צילומי מסך שיש בעמוד הזה:

Let's add DataGrid to Visual Studio

3 – ASP.NET & ADO.NET

להלן סרטון וידאו עם הסבר לכל צילומי מסך שיש בעמוד הזה:

Let's create first XML document

So Catalog.ASPX will be:

Let's add button

Now let's change code

Now let's talk about SQL

Now Let's create in SQL Server Management new User!

For it need login for first time as Windows authorization.

Let's change SELECT:

SELECT [ProductID], [ProductName], [CategoryID], [UnitPrice] FROM [Products]
to
SELECT TOP 10 [ProductID], [ProductName], [CategoryID], [UnitPrice] FROM [Products]

We can see new product with ID 82 was added

Let's add manually in SQL Server Studio

Let's check

Now let's update product

For now we have product with ProductID=84

Let's check it

Let's do it manually in SQL Server Studio

Let's check it

Let's delete some product

Let's delete ProductId=84

Let's check it

Let's do it manually in SQL Server Studio

Let's delete ProductId=83

Let's check it

Now let's get: NameOfTheProduct & Price by ProductId

Let's select ProductId=76

Let's do it manually in SQL Server Studio

Let's get all products

2 – ASP.NET

ברוכים הבאים לעולם של DOTnet בנושא: ASP.NET בעמוד הזה יש צילומי מסך עם הסברים שלי בסרטון וידאו לכל צילום וצילום.

להלן סרטון וידאו עם הסבר לכל צילומי מסך שיש בעמוד הזה:

Now let's create other basic aspx pages

Let's modify Web.config

First let's add Validation

Second let's add default redirection

Button go home not Visible

Field NAME will be checked by ValidationGroup="DetailsValidation" and it will be Required Field.

Field ExamID will be checked by ValidationGroup="DetailsValidation" and it will be Required Field with MaximumValue="800" MinimumValue="200"

Field EmailID will be checked by ValidationGroup="DetailsValidation" and ValidationExpression="\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*"

Field STATUS will be checked by ValidationGroup="DetailsValidation" and it will be controlled by ddlFamilyStatus.

Field ID will be checked by ValidationGroup="DetailsValidation" and it will be controlled by CustomValidator1_ServerValidate.

We take from tag "OnServerValidate" args, now we can check length of value of args. If something wrong so we print error via CustomValidator.

Field ID will be checked by ValidationGroup="DetailsValidation" and it will be Required Field.

Hide all form fields, after sent and make show HOME button.

Let's try enter NULL (nothing) will be called ValidationGroup (not custom)

Let's try enter number 7, will be called custom validation

Now let's try use JavaScript for validation by ClientValidationFunction="CheckID"

Let's try enter ID =7

Software Test Report

מטרה של מסמך STR לדווח על כל תהליך של בדיקות לצורך מסקנות.

סיכום בדיקות

כאן זה המקום לדיווח סטטיסטיקות, לדוגמה:

בהרצת מקרי בדיקה ב-STD בגרסה #2644 נתגלו 21 באגים מתוכם 12 באגים נפתחו ותוקנו ועברו בדיקות חוזרות בהצלחה לאחר תיקון.

5 באגים לא נפתחו – אנשי צוות הפיתוח נתנו הסבר מה הסיבה שזה לא באגים.

4 באגים עדיין נמצאים במצב תיקון.

21 באגים תוקנו בהצלחה.

לדוגמה:

במסמך-STD בגרסת Beta 2644# ב-TEST CASE C12 קיבלנו תוצאה לא צפויה!

ID3# BUG דווח ב-Jira, וקיבל סטטוס OPEN בתאריך 10.12.19 בתאריך 12.01.20 BUG תוקן ונבדק לאחר מכן בצוות QA.

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

המלצות ולקחים

ערכת מצב של התוכנה/מוצר לצורך החלטת אם תוכנה/מוצר מוכן להצגת ללקוח עבור – Acceptance testing

כל כבוד לכם!!!

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

אם תרצו ללמוד מבוא לתכנות ו-SQL כולל HTML, CSS, JS אז באתר יש גם קורסים נחמדים במבוא לשפת Java, JS, HTML/CSS ו-SQL.
כדי להיות בודק תוכנה טוב – לא חובה לדעת תכנות ובסיס נתונים אבל כדי להכיר 😉

שיטות סטטיות ב-QA

Static testing VS Dynamic testing

בבדיקות סטטיות לא מריצים את הקוד כנגד בדיקות דינמיות, אלה עושים סקירות/ניתוח ללא הרצה של התוכנה/רכיב כגון:

דרישות
מסמכי הבדיקות
Syntax of the code
דוקומנטציה אחרת…
…

Testing Review – סקירה

INTRO STAGE 0

מתאם (moderator) מקבל מ-Technical Lead בקשה לבדיקת מסמך לצורך בדיקת קריטריוני כניסה לבדיקות (entry check ) ללא entry check – קריטריוני כניסה לבדיקות, ביקורת המסמכים יכולה להיות כבזבוז זמן.

Planning stage 1

נניח שמתאם (moderator) בזמן סקירה מצא שגיאות כתיב בחלק מהכותרות של האפליקציה במסמך האפיון.
לכן MODERATOR יבקש Technical Lead לתקן את השגיות ולאחר התיקון אם הכל בסדר אז MODERATOR קובע שעות לפגישה עם כל צוות לצורך סקירה, כאשר בהזמנה למפגש הוא רושם נושא של הסקירה, מקום המפגש, מגדיר את קריטריוני יציאה (Exit criteria) – מהו המקסימום בעיות שיכול להיות בעמוד של מסמך אשר מיעוד לבדיקה וגם מבקש בקשה מ TECHNICAL LEAD לצרף מסמך אפיון לפגישה.

מתאם ביקורת – MODERATOR – מתוכנן גם באיזה אופן לבדוק מסמכים כגון 10-20 עמודים ביחידת זמן.

- Planning
The review process begins with a request for review by the author to the moderator/inspection leader. 
A moderator has to take care of the scheduling, entry check( to ensure that the reviewer’s time is not wasted) & exit criteria.

Kick-off meeting 2

פגישה של סוקרים מקבוצת ביקורת (reviewers) לצורך הצגת יעדי בדיקות וחלוקת מסמכים. לכל אחת מסוקרים.

בפגישה נמצא גם המחבר (author) – לדוגמה מחבר של מסמך STP, מסמך אפיון,,,, תפקידו להקריא את המסמך שלו ולבקש ממבקרים תגובות לגבי המסמך שלו.

- Kick-off
Short introduction on the objectives by author.

3 Preparation

סוקרים (reviewers) מבצעים ביקורת באופן אינדיבידואלי ובודקים מסמכים ורושמים כל פגמים שיש במסמכים ושאלות שלהם ב-LOG. כאשר בדרך כלל מספר עמודים בשעה לביקורת (checking rate) הוא 5.

לדוגמה סוקרים מגלים במסמך אפיון שחסרה פונקציונליות בחלק מהמקומות באפליקציה, אז הם רושמים את זה…

- Preparation
Reviewers review the document individually, all issues are recorded using a logging form - checking rate is ¬5 pages per hour.

4 Review meeting

יש כאן מספר תת שלבים:

Logging phase

כתבן (Scribe) רושם בפגישת סקירה על כל שגיאה / באג שצוין על ידי סוקרים בטופס רישום. כאשר לכל פגם יש רמת חומרה:

Minor – יש סיכוי קטן שפגם יגרום לנפילה

Major – יש סיכוי גדול שפגם יגרום לנפילה

Critical – פגם יגרום לנפילה בהחלט!

בדרך כלל כתבן (Scribe) רושם בדיווח בפגישה עם הסוקרים (reviewers) מאחת עד שני פגמים בדקה.

מתאם (moderator) גם יכול להיות סוקר – reviewer

Discussion phase

דיון בין כתבן (Scribe) וסוקרים (reviewers) על בעיות שנרשמו ב-Logging phase כך שמתאם (moderator) שומר על יחסי אנוש בין הצדדים. בנוסף במידה ומספר בעיות שנמצאו על-ידי כתבנים(Scribes) יותר ממספר שהוגדר בקריטריוני יציאה (Exit criteria) (לדוגמה נמצאו יותר מ-3 בעיות קריטיות במסמך, בעמוד אחד) אז מסמך נשלח לתיקון (Rework).

- Review meeting-Logging phase: 
The issues and the defects that have been identified during the preparation step are logged by the author or by a scribe. During the logging phase the moderator keeps a logging rate (number of defects logged per minute ~2 bugs per minute);

- Discussion phase: 
The moderator takes care for discussion of the logging issues. If the number of defects found per page is more than a exit criteria on page (for example if found more than 3 defects on page) then the document must be reviewed again-reworked.

5 – Rework

מחבר מסמך (author) יעשה שינוי/תיקונים במסמך לפי LOGGING PHASE – לפי מסמך שרשם SCRIBE.

Rework:
Author judges whether the defect has to be fixed.

6 – Follow-up

מתאם (Moderator) בודק שכל בעיות תוקנו על ידי מחבר מסמך (author) כאשר מתאם (moderator) מחליט אם יש צורך שסוקרים (reviewers) יבדקו עוד הפעם מסמכים.

Follow-up:
Moderator check if the author has taken action on all defects.

ניתוח סטטי בעזרת הכלים

מהדר (Compiler) מתרגם שפה מסדר גבוה לשפת מכונה אז מהדר בודק Syntax של שפת תכנות לתקינות.

Static analysis

ניתוח סטטי כגון: מסמך דרישות ודוקומנטציה אחרת, בדיקת קוד ללא הרצת תוכנה כגון Syntax, לוגיקה של הקוד…

עקרונות QA

שבעת עקרונות הבדיקה

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

הפסיכולוגיה של בדיקות

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

בדיקות מאפשרות למדוד את איכות תוכנה – QA.

מדוע בדיקות נחוצות ועד מתי לבדוק ?

ללא QA המוצרים יהיו עם הרבה BUGS וכתוצאה מזה יהיו FAILURES. כלומר בעזרת QA אנשי בדיקות תוכנה בודקים ש-BRS-Business Requirement Specification
ו-System Requirement Specifications
שזה אכן מתקיימים כנדרש.

QA מעלה את ה-QUALITY של המוצר ומוריד RISK של FAILURES

כמה צריך לבדוק?

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

בנוסף במסמך STP מוגדרים מתי יש להפסיק תהליך בדיקות (מקרים קיצונים).

תפקידים ראשים בעולם QA ?

Test leader/manger

מוביל בדיקות – אחרי על אנשי בודקי תוכנה (testers) שמנהל את כל תהליך של הבדיקות. להלן תפקידים של מוביל בדיקות (Test leader)

בניית אסטרטגיית הבדיקות בתיאום עם הנהלה.
הערכת זמן ומאמץ כולל עלות הבדיקות.
כתיבת מסמך STP, מעקב אחרי תוצאות הבדיקה של מסמך STD.
כתיבת דוחות סיכום STR.

TESTERS – בודקי תוכנה

אחרים על כתיבת מקרי בדירה
כותבים מסמך STD
מעריצים ומדווחים גל הבאגים
עושים בדיקות רגרסיה ו-RE-TESTING …

ארגון הבדיקות

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

מסמך בדיקות STD

STD – Software Test Description

במסמך STD יש אוסף מקרי בדיקה – TEST SUITE. כלומר במסמך הזה יש חילוק לפי נושאים, כאשר תחת כל נושא יש אוסף מקרי בדיקה ( Test Scenario ) ובכל מקרה בדיקה יש צעדים עם תוצאה צפויה ותוצאה בפועל עם ציון הצלחה של כל צעד.

אני ממליץ על הכלי לכתיבת מקרי בדיקות TestRail.

בתמונה למטה יש חילוק מקרי בדיקה לפי נושאים, כך שתחת כל נושא יהיה אוסף של מקרי בדיקה.

מה יש במקרה בדיקה – TEST CASE ?

Pre-conditions זה נתונים לפני הרצת שלבים של מקרה בדיקה, את הנתונים ניתן לקבל תוך שימוש בטכניקות שונות של בדיקות תוכנה (כאן באתר ראה תפריט עם תיאור טכניקות שונות מעולם QA ).
תיאור של הצעד – מה יש לעשות לבודק תוכנה.
תוצאת הצעד – PASS,FAILED ורישום תוצאה בפועל תוך השוואה לתוצאה הצפויה. במידה ותוצאה צפויה לא מתאמת את התוצאה בפועל אז יש לדווח על ה-BUG תוך התחשבות ברמת סיכון של ה-BUG (קריטי , חשוב, רגיל…).לצורך דיווח באגים, עדיף להשתמש ב-JIRA.

דוגמה למקרה בדיקה:

עוד דוגמה למקרה בדיקה:

בדיקת כניסת משתמש – positive testing, כאשר בצעד #2 יש באג – bug:

דוגמה למסמך STD:

1) Introduction
1.1 Document overview
This document is the software test description it contains the description of tests list in software test plan ref. STP#13. The tests will be executed during
Validation testing:
– Integration testing
– System testing

2) Tests basic preparations
This section contains basic tasks and recommendations before executing tests, the other INPUT DATA and preparations will be added with the depending by test case.

2.1 Hardware basic preparation

Describe platform configuration operations, like specific hardware to be used, physical network configuration.

Web server (minimal)
1,75 GB RAM
PHP > 5

2.2 Software basic preparation data

Describe software set-up and configuration operations, like simulators or software test tool to be used or the data.

2.2.1 JewNetwork user data:
– Email: [email protected];
– Password: sfdf4Kd2dnen1de9J
URL: Beta.JewNetwork.com

3) Test scenarios

3.1) Signup – Test Scenario
3.1.1) Negative test case – SPAM CHECK during registration.
3.1.2) Positive test case – SPAM CHECK during registration.
3.1.3) Positive test case – email confirmation.

3.2) Sign-in -Test Scenario
3.2.1) Positive test case – Login
3.2.1) Positive test case – Password recovery
3.2.3) Negative test case – Password recovery

3.3) Guest a non login visitors -Test Scenario
3.3.1) Positive test case – Read posts

…..

3.4) SEO -Test Scenario
3.5.1) Check meta tags
3.5.2) Keyword match for the articles.

Test Case & Checklist

Test case

ב-test case יש צעדים אם תיאור מה יש לעשות לצורך בדיקה עם עמודות של מספר צעד, תיאור הפעולה, ותוצאה בפועל, תוצאה צפויה וסטטוס של הצעד – עבר לא עבר..
נוח לאחד מספר test cases לפי תפקוד כגון איחוד כל test cases הקשורים לכניסה לאתר אינטרנט, האיחוד הזה נקרא תרחיש (TEST SCENARIO).

דוגמה של מקרה בדיקה – test case:

Test Scenario

תרחיש מבוסס על המסמכים: BRS, SRS, STD והוא כולל אחת או מספר מקרי בדיקה.

לדוגמה:

למעשה בדוגמה הזאת יש לנו ב-TEST SUITE אחת, שני תרחישים וששה מקרי בדיקה.

Checklist – צ'ק ליסט

הבדל בין צ'ק ליסט – Checklist ל-test case שב-Checklist אין תיאור מה יש לעשות בצעדים אלא רק מה לבדוק ללא פירוט איך לבדוק, כלומר Checklist מיעוד יותר לבודקי תוכנה שמכירים את המערכת וכאשר אין זמן לכתיבת תיאור של צעד אחרי צעד כמו שעושים ב-test case.

כאשר סטטוס יכול להיות PASS או FAIL.

Test design זה: תהליך של הפיכת תוכן המסמך SRS למקרי הבדיקה (test cases).

דיווח באגים – Jira

טוב, נניח שמצאתם BUG ועכשיו זה הזמן לדווח עליו במסמך- Bug report או עדיף להשתמש לצורך זה ב-BUG TRACKING SYSTEM לדוגמה JIRA.

Jira מאפשרת לנו לדווח על הבאגים, ליצור משימות ו-user stories. בנוסף יש אפשרות להעריץ SPRINTS תוך שימוש בגישת AGILE SCRUM.

Bug life cycle

אנשי QA מעברים BUG למפתחים ל-(BACKLOG) לצורך החלטה של הסטטוס עבור באג הזה.

BUG יקבל סטטוס Rejected: באג לא ניתן לשחזור.
BUG יקבל סטטוס Duplicate: באג כבר קיים.
BUG יקבל סטטוס Deferred, Postponed: באג אכן קיים אבל אין צורך לתקן אותו עכשיו.
BUG יקבל סטטוס OPEN: באג אכן קיים וצריך לתקן אותו.
נניח במהלך בדיקות חוזרות לבאג עם סטטוס (תוקן-FIXED), הבאג עדיין לא תוקן!
במקרה הזה באג מקבל סטטוס– REOPEN.
כאשר באג תוקן – FIXED
BUG יקבל סטטוס DONE: באג תוקן ויש צורך בבדיקה של אנשי QA

דוגמה ליצירת פרויקט ב-Jira

באו ניצור Scrum פרויקט.

יש לעבור בקישור https://www.atlassian.com/software/jira

לאחר הרשמה קצרה יפתח חלון הבא:

יש לבחור שם האתר, למעשה זה יהיה קישור לפרויקט JIRA שלכם בענן.
לדוגמה אם נבחר qablog אז קישור לכלי Jira שלנו יהיה:
qablogi.atlassian.com

לאחר מכן יש לדלג על כל מיני הצעות של Atlassian עד שיהיה חלון הבא:

ואז יש לבחור את Scrum

נבחר שם לפרויקט ומזהה לפרויקט.

לדוגמה:

שם: Test Name ומזהה: TN2

יש ליצור ספרינט חדש(נקרא לספרינט: TN2 Sprint 1).
לצורך זה – יש להיכנס ל-Backlog וללחוץ על הכפתור Create New Sprint

הוספת באג חדש ל-Jira

לדוגמה ניתן להוסיף באג חדש ל-BACKLOG.

Test Lead/Team Lead, בוחר מ-BACKLOG באגים פתוחים (שיש להם סטטוס OPEN) ומעביר אותם ל-Active Sprint. לעמודה "To Do".

לאחר תיקון הבאג, באג עובר לעמודה – DONE. בודקי תוכנה לוקחים את הבאג אשר נמצא בעמודה QA ועושים בדיקות חוזרות.

בקרוב אני מתכוון לעשות מצגת וידאו על כלי Jira, אבל העיקר שתכירו פחות או יותר את הכלי הזה.

Bugs – עולם הבאגים

קודם כל נשאלת שאלה הבא: מאיפה באים BUGS : )

מאיפה באים באגים?

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

עלות התיקון של באגים

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

Software Problem Report

דיווח באגים – חשוב מאוד לרשום ב-SPR את התיאור של צעדים שגורמים ל-BUG וגם SEVERITY (כמה ה-BUG משפיע על המערכת) ו-PRIORITY עדיפות לתיקון BUG.

I like bug tracking system Jira : )

Bug lifecycle

כאשר נפתח BUG אז הוא מקבל סטטוס OPEN
כאשר בעבר באג תוקן ושוב חוזר אז באג מקבל סטטוס DUPLICATE
אם מפתח או ראש צוות פיתוח אמר שזה לא באג אז סטטוס – REJECTED
כאשר באג תוקן – FIXED
הערה:
- לאחר תיקון באגים, יש לעשות בדיקה חוזרת RETEST ולוודא שהבאג אשר תוקן.
- בנוסף יש לעשות בדיקות רגרסיה.
נניח במהלך בדיקות חוזרות לבאג עם סטטוס (תוקן), הבאג עדיין לא תוקן!
במקרה הזה באג מקבל סטטוס– REOPEN.
לאחר תיקון הבאג אם אין יותר באג בבדיקות חזרות אז הבאג מקבל סטטוס – CLOSED