114: סדרת R&D 04 - איך בונים אסטרטגיית טסטים טובה בלי מחלקת QA

אנחנו מביאים תובנות עיקריות מסשן בנושא A good testing strategy שנערך בכנס ה-Unplugged בנושא R&D שלנו. אורח: שני רדזבסקי, Full Stack Developer במאנדיי.קום.

פיתוח

Why have we decided to not use QA teams? How to build a good strategy for automatic tests? And how can we make sure that we cover every potential bug in our code?

At monday, we don’t have a QA department. With that being said, just like every other company, it’s important to us to make sure our R&D department runs as fast as possible (and still allow our developers to sleep at night). So how do we do it?

In one of our Unplugged engineering sessions, Shanee Radzewsky, a Full-Stack developer on the Autopilot Core team at monday, shared how we built a good testing strategy incorporated into every level of the R&D. A strategy that will allow us to continue moving quickly in our R&D department, without relying on a QA team. In this week’s episode we bring the main insight from her session

Under this description is a link to the original session’s presentation, and we recommend looking at it while listening.

And a short reminder - this episode is not a technical one, and is suited to managers or founders wanting to learn more about the subject, or test their engineering department work methods.

----

Link to the session - https://www.youtube.com/watch?v=XWkQDPAOc9E&t=20s

Link to the presentation- https://drive.google.com/file/d/1Bx8wR0eR8YebkVLig0mfLxquaBxMjPXV/view?usp=sharing

---

More relevant episodes:

First R&D mini-series episode - The core principles of our R&D culture

Second R&D mini-series episode - How we upgraded our framework at minimal riskThird R&D mini-series episode - On our developers’ personal development plan

Episode transcript

Automatically transcribed — it may contain errors.

היי כולם, אני דלי ורטיים ואתם הגעתם לסטארטאפ פור סטארטאפ, הפודקאסט שבו אנחנו חולקים מהניסיון, מהידע והתובנות שלנו כאן במאנדי.קום וגם מחברות אחרות ומיועד לכל מי שסטארטאפ מדבר אליו, לא משנה באיזה כיסא הוא יושב ברגעים אלו. ברוכים הבאים ליומימי סדרה שלנו על R&D, שבמהלכה נשתף בעקרונות, בתרבות ובתהליכים של מחלקת האינג'ינירינג במאנדי.קום. במרץ 21 התקיים אירוע Unplugged Engineering, שבו עסקנו בעקרונות שמובילים את מחלקת הפיתוח במאנדי ואיך אנחנו מיישמים אותם בפרקטיקה. באחד הסשנים שהתקיימו באירוע, שנירה ג'ייבסקי, מפתחת פול סטאק בצוות האוטופיילט קור במאנדי, שיתפה איך בונים אסטרטגיה טובה לטסטים אוטומטיים, כאלה שיאפשרו לנו להמשיך לזוז מהר במחלקת הפיתוח מבלי להסתמך על צוות QA. אז בפרק היום אנחנו מביאים את התובנות העיקריות מההרצ של שני, שמסבירה איך בנינו את אסטרטגיית הטסטינג שלנו, מהם סוגי הטסטים השונים שאפשר להשתמש בהם ובעיקר איך הם מאפשרים לנו לעשות דיפלוי שלושים פעמים ביום ועדיין להצליח לישון בלילה. בתיאור הפרק מופיע לינק למצגת שמלווה את הסשן ואני ממליצה להסתכל עליה במקביל להזנה. לפני שנצלול העומק לתוך בנייה של אסטרטגיית טסטינג, נר לי שכדאי קודם כל להבין למה בעצם אין לנו QA. QA בעצם יכול להיות כלי מאוד מאוד חזק, אבל יש לו עלות. זאת אומרת, אם אנחנו מסתכלים עכשיו על להשתמש ב ת בQA למשל במניואל טסטינג, כן, שעכשיו נגיד אני אומרת לפני שאני מעלה לפרודקשן אז אני מעבירה את זה דרך מישהו ממחלקת QA והם בעצם ככה באים ובודקים. אז זה בעצם משהו שמוסיף לי איזשהו בוטלנק, נכון? זה מוסיף לי עוד איזשהו שלב שמוסיף זמן. כן, וזה פוגע ביכולת שלי לרוץ מהר, זה פוגע ביכולת שלי ב ת לקחת אחריות מל על מה שאני עושה. זה עוד איזשהו שלב, נכון? אם בדרך כלל אז אני עושה את הריוויו שלי, אני בודקת ואני עושה איזשהו קוד ריוויו עם מישהו חיצוני, אולי דיזיין ריוויו. עכשיו יש לי עוד שלב ועוד מישהו לטעם איתם שאני צריכה ככה שיבואו ויבדקו וזה משהו שמעט אותנו. אפשר גם להגיד אוקיי, אז לא נעשה את זה ידנית, יהיה לנו צוות והם יכתבו בעצם ככה טסטים אוטומטיים ויהיה לנו את המערכת הזאת שכל הזמן ב ומריצה. עכשיו זה משהו שאפשר לעשות אבל זה מוסיף עוד איזשהו דגרי אוף ספריישן, שוב אולי עכשיו לא משהו שמעט אותנו, נכון? כי אנחנו אומרים סבבה זה טסטים אוטומטיים אבל זה כן משהו שמרחיק אותנו מהתוצר הסופי ומהמוצר והלחוש למוצר ואנחנו מרגישים שעבור המפתחים זה כן מוריד קצת חלק מהתחושת אחריות סביב מה שהם מעלים עכשיו. זאת אומרת אני כשאני מפתחת משהו אז צריך להיות לי אונרשיפ מלא על הדבר הזה ואני צריכה לדעת איך היוזרים הולכים לחוות את זה. זאת אומרת אם יש לי איזושהי בעיה בלהבין איך עכשיו לבדוק את זה או איך לראות כי אני לא בטוחה איך היוזרים משתמשו בזה זה גם יפגע ביכולת שלי לפתח את זה בצורה הכי טובה. אז אנחנו מאוד מ ינים שב ת חשוב לדעת לבוא ולבדוק את הפיצ'רים בעצמנו אם עכשיו גם לפני שאני מעלה משהו וזה יעזור לי לתכנן את זה יותר טוב וגם אחרי שאני מעלה משהו ממש לבוא ולחוש את זה ולנסות את הדברים והכיוונים השונים וזה משהו שאנחנו מ ינים שמוציא בסוף תוצר יותר טוב ושלם. אוקיי אז החלטנו שלא נעשה QA אבל מה במקום? זה בעצם המקום שבו אסטרטגיית טסטים נכנס. אז אסטרטגיית טסטים זה בעצם משהו שהוא קרוס R&D כן זה משהו שאנחנו עכשיו נגדירים קונבנציות ואנחנו אומרים מה הרמה שאנחנו רוצים שהטסטים שלנו יהיו איך אנחנו רוצים לכתוב את הטסטים שלנו וב ת שיהיה לנו ככה את הבסט פרקטיסס את הדברים של איך אנחנו חושבים שצריך לכתוב טסטים וזה גם אומר שאנחנו מורידים את העלות של כתיבת הטסטים נכון בגלל שאנחנו משקיעים בזה שיש לנו דוגמאות טובות יש לנו ככה knowledge based of אולי שמסביר איך לעשות את זה יש משאבים שבעצם באים ועוזרים לאנשים לכתוב טסטים וזה גם עניין של לעשות איזשהו promotion לזה שאנשים יהיה להם את היכולות האלה יהיה להם את הנולדג' הזה לדאוג שחלק מלהיות בעצם מפתח או מפתחת במינדי זה אומר לדעת לכתוב את הטסטים האלה ושזה יהיה חלק מהביט. אז זה בעצם לדעת ככה גם על מה הגישה שלנו גם על הבסט פרקטיסס שלנו וגם להקל על הדבר הזה. זה אומר גם שב ת הטרייד אופים שאנחנו מקבלים בתוך הטסטים זה משהו שהוא החלטה שקיבלנו מראש כן זה אומר שזה משהו שאנחנו עכשיו באים ואומרים כן אוקיי end to end testing יכול להיות שיכולנו לכתוב על כל המערכת והכל יהיה מכוסה לגמרי וכל flow אבל זה בסוף עולה לנו משהו נכון אנחנו לא שואפים ל100% קווירג' אנחנו שואפים למשהו שהוא ב ת ככה לחסות את הפלואוז הקריטיים לחסות את המקומות שאנחנו יודעים שהם רגישים וזה משהו שהטרייד אופים האלה חייבים להיות החלטות שקיבלנו בכוונה. גם אם אנחנו לא

אנחנו לא שואפים ל-100% קוורג' עדיין יש מינימום שהטסטים שלנו צריכים לחסות. אז איך בעצם בונים אסטרטגיה טסטינג שתוודא את זה? אז בשלב זה אני אקח אתכם רגע אחורה, אני אספר לכם קצת על הקבוצה שלי, הצוות שלי ומשהו שאנחנו עברנו. אז אני בעצם נמצאת בקבוצת אוטופיילט, למי שמכיר קצת את המוצר, זה בעצם כל עולם האוטומיישנס, אינטגריישנס, ה-API וה-Apps. ובהתחלה ב ת רצנו ואוספנו המון יכולות ובאנו והרבה פיצ'רים ואת האינטגרציות ושיהיה את כל היכולות האלה. אז עוד היינו טספורס, אפילו לא צוות, עכשיו אנחנו כבר קבוצה עם שלושה צוותים, אבל באיזשהו שלב, אחרי שכבר היה לנו את הבשר הזה, אז הבנו שאנחנו לא נמצאים איפה שאנחנו רוצים להיות מבחינת הטסטים ואנחנו לא קוורד, אנחנו לא מוגנים בצורה שהיינו רוצים להיות ואנחנו מרגישים את זה, אנחנו משלמים על זה את המחיר. אז בנינו אסטרטגיה ועכשיו אנחנו רוצים לבנות איזושהי טסט פלן סביב איזור מסוים במוצר. איך ניגשים לזה? אז בעצם מה שעשינו זה התחיל בעצם באיזשהו ריסרג' ממש על כל הדברים שקרו לנו עד עכשיו. כן, הסתכלנו ב ת על החצי שנה שקדמה של כל האוספות האלה ו רנו מה הדברים שקרו ואיזה באגים היו, איזה טיקטים קיבלנו מיוזרים, שזה בעצם שהם כותבים לנו ומתלוננים על משהו שהם חווים, אולי משהו שלא מובן או משהו ששבור. אז אנחנו ממש רואים, שמנו ברשימה ענקית כזאת את כל הבאגים שהיו לנו בכל החצי שנה האחרונה וממש עברנו עליהם ו רנו אוקיי, באיזה סרבסים זה קרה? כן, באיזה פלו בקוד זה קרה? ואיזה טסט היה מציל אותנו? ולפעמים יש גם שני טסטים שהיו מצילים אותנו. כשהסתכלנו על זה וחשבנו על זה, לא רצינו להסתכל ולהגיד מה הטסט האחרון שהיה מציל אותנו, אלא מה הטסט הראשון, הדבר הראשון, המעגל הראשון שנפרץ, שהיינו יכולים שם לתפוס את הבעיה. ואז באנו ו רנו אוקיי, עכשיו הסתכלנו על העבר, בוא נחשוב גם על העתיד. בוא נסתכל על הרודמפ שלנו, כן, לשנה הקדימה, ונגיד מה הדברים שאנחנו עכשיו הולכים לגעת בהם, מה החזון שלנו ואיזה דברים אנחנו הולכים לשנות הכי הרבה. איזה תשתיות עכשיו אנחנו נשען עליהם ממש חזק וחשוב לנו שהם יהיו ממש סולידיות, ושהם לא יוכלו להישבר, כי אנחנו יודעים שניגע בהם, אנחנו יודעים שנסתמך עליהם. וככה הסתכלנו ב ת על שני הכיוונים האלה. אוקיי, אז זה היה השלב הראשון. מה עשיתם אחר כך? אז הסתכלנו על הדברים האלה ועשינו איזושהי רשימה מאוד ארוכה של איזה טסטים אנחנו רוצים לעשות, ואז התחלנו לעשות פריוריטיזציה ב ת מתוך מה שבנינו, של איזה טסטים רצינו לעשות, פרסנו ב ת את כל הסוגי טסטים. איזה טסט זה, אם זה קליינט טסט, כאילו end-to-end טסט, האם זה יונת טסט, איפה, באיזה אזור של הפלואו, כשאתם רואים, באריה, כן, ומה הגודל של האפורט. וככה פרסנו את זה, ועשינו את הטסטות. אז שלנו תקפנו את הדברים האלה ככה, שיהיה לנו איזשהו די סיים ב ת טוב, שמשם אנחנו יכולים להמשיך. כשאנחנו מדברים ככה, לבנות את הטסטים ולהחליט איזה טסטים אנחנו עושים, לא רק לכתוב איזה טסט אנחנו רוצים לכתוב, אלא גם ממש לנסות לחשוב ולחשוט, וזה משהו שגם רצינו שאנשים יראו איך אנחנו ניגשים לזה וילמדו גם איך לגשת, כשכותבים טסט, מה זה אומר, איזה טסט קייסים כותבים, כן, אז עבור כל טסט ממש פירטנו את הדברים העיקריים שחשוב לבדוק. ובסוף יצאנו מזה ב ת כאילו עם אימפקט ממש גדול, ככה לאט לאט יורדים. הוספנו גם ב ת קוורג' מטריקס סביב הדבר הזה ואיזושהי חגיגה שבועית של מי הכי אלה את הקוורג' כאילו עם ה-PR שלהם באותו שבוע. הכל ככה כלים ככה להמשיך להיות על זה. אוקיי, אז בואו נדבר על הדברים שהכי חשוב לזכור בתהליך. קודם כל חשוב לא לכתוב טסטים סביב הקוד, כן? אנחנו לא רוצים לכתוב את הטסט ככה לפי שורה שורה בקוד, אלא לפי מה שיוזרים חווים, ואנחנו מאוד חשוב לנו גם ה-Rainy Day Scenarios, זאת אומרת איך דברים ייכשלו, שאם ייכשלו, מה אנחנו רוצים שיקרה. אנחנו לא רוצים לבדוק כאן עכשיו רק מה קורה בהייפי פלואו. אז כאילו מבחינת ה-לא לכתוב סביב הקוד, זה לא אומר לא להסתכל על הקוד בכלל, כן? אנחנו, חלק מהכוח שלנו כאן זה דווקא זה שמי שכותב את הטסט זה אנשים שהכי מכירים את האזור הזה ואת המערכת, וב ת יכולים לכתוב ויודעים את הפיטפולים ויודעים את הנקודות סיכון, ומצד שני, אותו הדבר הזה של ההיכרות הטובה עם הקוד ועם המערכת, לפעמים היא גם נותנת לנו איזשהו בייס, נכון? שאנחנו רואים את הדברים מאוד ככה ותכננו וככה עכשיו בדיוק שהשתמשו בזה, בסוף יוזרים חווים את הדברים אחרת, כן? מסתכלים על הדברים ומשתמשים בדברים אולי קצת אחר, בגלל זה כן חשוב לקחת צעד אחור ממש לחשוב, אוקיי, איך יוזרים משתמשים בתוצר של הקוד הזה ולכתוב לפי זה. מבחינת ריינידיי סינאריוס, זה פשוט עניין של לחשוב איך הדבר הזה ור לקשל, וזה משהו שהוא גם עוזר לנו לכתוב מוצר יותר טוב. כאילו כשאנחנו באים ואנחנו כותבים את הטסטים ככה ביחד עם יצירת הפיצ'ר, אז לפעמים אנחנו באים וכותבים לאיזשהו טסט קייס

אז גורם לנו לחשוב על משהו שוואלה לא חיסינו, נכון? אז שבונים טסט פלנט סביב אזור מסוים, אז קודם כל בודקים את ההפי פלו הכי בסיסי. אני נכנסת ורוצה לתת מסך בסיסי בלי אופציות של דברים שיכולים לקרות שהם ככה קסטומים. הדבר הכי בסיסי, האם זה קורה נכון. אחרי זה אני מתחילה, אוקיי, איך הדבר הזה יכול להיכשל? מה כל ה-fail scenarios? אם עכשיו אני תלויה במשהו וזה לא קורה. אם עכשיו אני מקבלת אימפוט לא טוב מיוזר. אז כל ה-fail scenarios, ואז להתחיל לבדוק ב ת את כל הדברים של הלוגיקה. כשנסתכל על מי הלקוחות של הטסטים האלה, אז אפשר להגיד אוקיי, זה הלקוחות שלנו, כי אנחנו רוצים להגן על המוצר. אבל בעצם הלקוחות שלנו זה אנחנו, זה המפתחים. אנחנו רוצים לא להצטרך לחוות את האוישיט הזה שאלינו בג. אנחנו רוצים לא להצטרך לקום בלילה. אנחנו רוצים שהטסטים האלה יעזרו לנו ויתפסו. זה היה הדבר שהיה לנו הכי חשוב לראות. כי אם אין לנו את התחושה שהטסטים תופסים בגים, אז לא עשינו כלום. וזה ככה מה שצריך להיות בפוקוס כשאנחנו כותבים את הטסטים. האם הטסטים האלה ב ת יגנו עלינו, או שזה סתם שאנחנו חושבים שזה פלואו מרכזי, אז החלטנו לכתוב לו טסט, אבל כשאנחנו מסתכלים על הדברים שב ת נשברים במערכת, זה לא זה. אז ככה צריך להיות ב ת בפוקוס הזה. ואני חושבת שזה ב ת מאוד מדגיש את הצורך בטסטינג סקוואט הזה. לרגע לפני שנסיים, אם יש אנשים שמאזילים לנו עכשיו ורוצים לבנות אסטרטגיית טסטינג, יש לך טיפים בשבילם? דבר ראשון שצריך, אנחנו רוצים לבוא לגשת ולכתוב טסטינג סטרטגי, זה להגיד אוקיי, מה המיין פלואוס? מה הדברים במערכת שהם ב ת חשובים? הדברים הקריטיים שאנשים ב ת עושים? וכאן ב ת, שוב, חשוב ממש לחשוב בקובע של יוזרים. מה הדברים שאנשים עושים? איך אחר כך זה מתרגם למה קורה במערכת? מה התשתיות שאנחנו הכי נוגעים בהן? דבר שני, וזה ככה מאוד מנדי, גם להציב יעדים מאוד יציונים. לא להגיד אוקיי, מה הריאלי, ובוא נחליט מה הריאלי שנעשה בחודשיים האלה, וזה מה שנשים לעצמנו יעד. לא, לחשוב על החזון. לחשוב על המצב הזה שאנחנו מוגנים ושאנחנו יכולים לרוץ, ואנחנו ב ת מרגישים טוב עם דיפלוימנס, כי אנחנו יודעים שהטסטים שלנו תופסים דברים, ואנחנו לא צריכים לדאוג מזה. לשים שם את היעדים. לשים שם את היעדים ואת החזון, בשביל שגם נתחבר ללמה אנחנו עושים את זה. ומשם להתחיל, אוקיי, פריורטיזציה ולגזור מה אנחנו יכולים לעשות מתי, אבל לשים את החזון כחזון חלום. אחרי זה אנחנו ב ת צריכים להחליט על הטכנולוגיות והקונבנציות, באיזה כלים אנחנו רוצים להשתמש, ואיך אנחנו מגדירים את ה-best practices שלנו. מה הדברים שאנחנו לא מסכימים לעשות, שכן, זה גם אומר מה הדברים שאנחנו יודעים שהם טרייד אוףים, והם לא אידיאליים, ואנחנו כן מסכימים לעשות אותם. אז כאילו ב ת להחליט על הקונבנציות האלה, ולדאוג שזה משהו שהוא קרוס-R&D. כן, אני לא רוצה עכשיו שאני אצטרך, אם נגיד אני עוברת צוות, או אם אני ב ועובדת באיזשהו אזור בקוד שהוא שונה, כשפתאום אני כותבת בטכנולוגיה טסטינג אחרת. כן, אני רוצה שכאילו ב ת הדברים האלה יהיו מאוחדים. ככה יש לי ב ת איזשהו נולדש שגדל, ויותר אקספרטס שמתבספים, ואנשים שאני יכולה להתייעץ איתם, כי הם כבר חוו את אותו הבעיה באותה טכנולוגיה. והדבר הרביעי, שזה משהו ככה, שוב, שאנחנו מרגישים שהיה לנו בוסט ממש מטורף, לבנות לזה צוות. יש לנו את הטסטינג סקוואד, בסוף, כמו ש רנו, נכון? עם הסקיורטי או עם כל דבר אחר, הצ'מפיוןים האלה הם משהו שהוא ממש חשוב. גם שזה יהיה אנשים מכל מיני דומיינים שונים, שיש את הקובעים האלה, יש את המחשבות של האזורים השונים בקוד. אבל בסוף גם העניין כאן, שטסטינג כאן, זה כאילו, אנחנו רוצים שלכתוב טסט יהיה נורא נורא קל. אבל לדאוג שלכתוב טסטים יהיה קל, זה פרויקט שהוא רציני. כן, לבחור את הטכנולוגיות, ולהיות ב ת האנשים האלה שיש להם את האקספרטיס, שעכשיו הם שואלים שאלה קשה, אז יודעים לענות כאילו על האזור שאנחנו מכירים. להחליט מה הקונבנציות, לעשות לי זה אינפורס, לדאוג שהנולדג' יהיה שם. זה פרויקט שצריך עבורם הורים, ואנשים שב ת ככה יבואו ויקחו את זה וידחפו את זה קדימה, וזה משהו שמעיף. אני אזכיר שהפרק הזה הוא חלק מהרצ בנושא, ששני העבירה בכנס Unplugged Engineering שלנו. בה היא פרטה גם על סוגי הטסטים השונים, ונכנסה לפרטים טכניים יותר. אם אתם רוצים לשמוע את ההרצ המל או הרצאות נוספות מהכנס, אפשר למצוא אותן בעמוד הוידאו באתר שלנו. ואם יש לכם שאלות שעלו בעקבות הפרק, אפשר לשאול אותן בקבוצת הפייסבוק שלנו או באתר. תודה שהזנתם. Start-up for Start-up for Start-up for Start-up Start-up for Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up for Start-up Start-up