My 4 Main Takeaways from Let’s Test 2016 (Nicky Tests Software)

On May 30, 2016, in Syndicated, by Association for Software Testing

Last year, I wrote a two-part reflection on my experience at Let’s Test, which detailed every session I went to. This year, I’ve decided to take a different approach. While there’s a lot I can say about every session I went to this year – I feel my time would be better spent on focussing on a few things that I took away from Let’s Test 2016

1. Context > Process

In his workshop, Patrick Prill had us do a few activities where we discovered that instructions to do the same thing, can lead to wildly different results. One question that was asked was “How do you make good coffee?” – as someone answered the question, all I could think was Aren’t you going to ask if they want milk or sugar? Part of me thought, there’s no point having “good coffee” if you add condiments where they’re not wanted.

Being in his workshop reminded me of the importance of interpretation and that we need to know the context to be better able to interpret information (or instructions).

2. A lot of people agree on what makes a good conference abstract 

I went to Richard Bradshaw‘s and Martin Hynie’s workshop on being a TeSTAR, where we had some discussions around what makes a good conference abstract. 
According to us, characteristics of a good conference abstract include (among others):
  • Clear
  • Takeaways
  • Fits the theme
  • Appealing to the audience
  • Interesting
At the end of the day, knowing what makes a good abstract is one thing, knowing how to apply it – is another.

3. People can talk themselves to a solution

In Lou Perold‘s session, we did an activity where someone would talk about a problem and the other person would simply listen. No questions; no interrupting; just listen. One thing that stood out to me was the lack of questions, my understanding of this was to avoid the “listener” from steering the conversation – so the “speaker” could let it out.
I enjoyed the concept that people can talk themselves to a solution by talking to someone about it (having an actual person front of you, seems to do the trick). This takeaway is something that’ll probably be applied to life both in and out of my work.

4. At the end of the day, it’s about the people

I could rave about the keynotes and the sessions but to me, it’s the people who make the conference experience great. Last year, I made some amazing connections with people – and was very excited to see some familiar faces when I got to Runö. I’m gutted that it’ll probably be a year until I see most of the people again.

Software testing is not … playing. Part 5 (Mr.Slavchev())

On May 30, 2016, in Syndicated, by Association for Software Testing

Software testing is not… Software testing is not … part 2. Software testing is not … part 3. Software testing is not… finding bugs part 4. Software testing is not … meant to add value I know this is controversial claim and many testers might object it. So, let me explain. This is my position […]

The post Software testing is not … playing. Part 5 appeared first on Mr.Slavchev().

Page Objects are not enough (אשרי אדם מפחד תמיד Happy is the man who always fears)

On May 28, 2016, in Syndicated, by Association for Software Testing

Administrative note: Due to code mixing badly with Hebrew – English only. Sorry.So, as we all know, if one is writing automation in Selenium, one of the first things to hear about is page objects. Page objects are cool, very useful way to separate “wha…

Use docker for Linux (zagorski software tester)

On May 28, 2016, in Syndicated, by Association for Software Testing

TL;DR In this technical post I will explain how I resolved one of my previous…

Running Rspec acceptance tests in TeamCity (Chris Kenst's Blog)

On May 27, 2016, in Syndicated, by Association for Software Testing

At work we use TeamCity as our CI service to automate the build and deployment of our software to a number of pre-production environments for testing and evaluation. Since we’re already bottling up all the build and deployment steps for our software, I figured we could piggy back on this process and kick off a simple login test. It seems […]

Speak Easy at CAST 2016 – Part 2

On May 27, 2016, in CAST 2016, News, Newsletter, by Claire Moss

This is Part 2 of a 2-Part post on Speak Easy at CAST. Part 1 is here. As mentioned in the first article in this series, CAST 2016 will have multiple Speak Easy speakers joining us this year. Julie Lebo is fresh on the speaking scene and looking forward to attending CAST. She had this to say: […]

Experience Report: Giving a talk at Let’s Test as part of Speak Easy (Nicky Tests Software)

On May 26, 2016, in Syndicated, by Association for Software Testing


A few months ago, I approached Maria Kedemo to be my mentor as part of the Speak Easy Program. She said Yes! 😀 So we started working on my proposal and then later the actual talk itself together. At the start, we first discussed our expectations around how we would do this (to be honest, I remember having this discussion but not exactly what our expectations were, so I can’t list them here). We collaborated on Google docs to work on the proposal and then later, the talk itself. We also had a few Skype calls (about an hour long on average) to prepare for Let’s Test.
I practiced my talk with her for the first time (in full) about 1.5 – 2 weeks before Let’s Test. At this point she gave really useful feedback and how to improve my talk which I took onboard including the use of specific examples from my past and tying the closing points to the opening story. I then practiced in front of Martin Hynie and Maria the night before I gave the actual talk.
I practiced the talk a few times at home and in my hotel room at Runö (a blank white wall happened to be my favourite audience when doing this). I found that  I easily remembered about half my talk and the other half I really struggled with (this continued to the talk itself where I had to refer to my notes more than I would’ve liked).

Lead-up to the talk at the conference

To be honest, I was very nervous leading up to the talk itself while I was at the conference (I really was a bundle of nerves, I ate salad and a bit of egg for lunch then nothing until 6.30pm. I also had to exit the Closing Keynote to calm myself down as I felt I was going to throw up as my stomach was still twisting from the nerves
The fact that my talk was at the last time-slot before the Closing Keynote, didn’t help either as I’m one of those people who just gets more and more nervous as time passes. I had the logical side of my mind saying “You’ll be fine, you’ve spoken in public before and what’s the worst that could happen?” The logical side of my mind was trying to put it in perspective. 
But the more emotional part (which was more dominant) was scared of the fact that people would just stare at me blankly and think WTF or that there’d be no Open Season discussion. The Open Season discussion part was very  important to me as I feel you learn just as much (if not more) from the discussion than the talk itself.
I didn’t tell people that I met at the conference that I was going to speak at it, neither did I post it on Twitter while I was at the conference. I’m not sure why I didn’t, looking back I probably should’ve. 

The Talk

It went really well, I couldn’t have asked for a better audience. It was the perfect forum for me to share a personal experience. I shared a personal story about my past in software testing and then some of the things I learnt from it – including the acronym WIT, which has been a great go-to when it comes to advocating for bugs. Almost everyone either participated in the Open Season or came up to me afterwards to give feedback or add a few comments. Those really lifted my spirits. 

Lastly I would like to say thank you.

Thank you Maria for mentoring me – you were an encouraging mentor and I really appreciate the useful pointers so that I could improve my presentation.
Thank you Speak Easy for the opportunity – I love what you are doing!
Thank you Patrick for being my facilitator – your presence and support was very calming
Thank you Lim for filming a bit of it – it meant that my bf will get to watch a snippet.
Thank you to the attendees – I really appreciate your feedback and the questions you asked, they meant the everyone else in the room got to learn more from the session.

API Testing – Getting Started with SoapUI (Assert.This)

On May 26, 2016, in Syndicated, by Association for Software Testing

Every few weeks or so I see a new question on the LinkedIn’s Test Automation group about getting started writing API tests and there’s almost always a flurry of responses recommending SoapUI. There are definitely alternatives, but if you are just getting into automation or API testing in general SoapUI offers a visual interface that … [Read more…]

Cambridge Lean Coffee (Hiccupps)

On May 26, 2016, in Syndicated, by Association for Software Testing

This month’s Lean Coffee was hosted by Cambridge Consultants. Here’s some brief, aggregated comments on topics covered by the group I was in.

What is your biggest problem right now? How are you addressing it?

  • A common answer was managing multi-site test teams (in-house and/or off-shore)
  • Issues: sharing information, context, emergent specialisations in the teams, communication
  • Weinberg says all problems are people problems
  • … but the core people problem is communication
  • Examples: chinese whispers, lack of information flow, expertise silos, lack of visual cues (e.g. in IM or email)
  • Exacerbated by time zone and cultural differences; lack/difficulty of ability to sit down together,  …
  • Trying to set up communities of practice (e.g. Spotify Guilds) to help communication, iron out issues
  • Team splits tend to be imposed by management
  • But note that most of the problems can exist in a colocated team too
  • Another issue was adoption of Agile
  • Issues: lack of desire to undo silos, too many parallel projects, too little breaking down of tasks, insufficient catering for uncertainty, resources maxed out
  • People often expect Agile approaches to “speed things up” immediately
  • On the way to this Lean Coffee I was listening to Lisa Crispin on Test Talks:”you’re going to slow down for quite a long time, but you’re going to build a platform … that, in the future, will enable you to go faster”

How do you get developers to be open about bugs?

  • Some developers know about bugs in the codebase but aren’t sharing that information. 
  • Example: code reviewer doesn’t flag up side-effects of a change in another developer’s code
  • Example: developers get bored of working in an area so move on to something else, leaving unfinished functionality
  • Example: requirements are poorly defined and there’s no appetite to clarify them so code has ambiguous aims
  • Example: code is built incrementally over time with no common design motivation and becomes shaky
  • Is there a checklist for code review that both sides can see?
  • Does bug triage include a risk assessment?
  • Do we know why the developers aren’t motivated to share the information?
  • Talking to developers, asking to be shown code and talked through algorithms can help
  • Watching commits go through; looking at the speed of peer review can suggest places where effort was low

Testers should code; coders should test

  • Discussion was largely about testers in production code
  • Writing production code (even under guidance in non-critical areas) gives insight into the production
  • … but perhaps it takes testers away from core skills; those where they add value to the team?
  • … but perhaps testers need to be wary of not simply reinforcing skills/biases we already have?
  • Coders do test! Even static code review is testing
  • Why is coding special? Why shouldn’t testers do UX, BA, Marketing, architecting, documentation, …
  • Testing is dong other people’s jobs
  • … or is it?
  • These kinds of discussion seem to be predicated on the idea that  manual testing is devalued
  • Some discussion about whether test code can get worse when developers work on it
  • … some say that they have never seen that happen
  • … some say that developers have been seen to deliberately over-complicate such code in order to make it an interesting coding task
  • … some have seen developers add very poor test data to frameworks 
  • … but surely the same is true of some testers?
  • We should consider automation as a tool, rather than an all (writing product code) or nothing (manual tester). Use it when it makes sense to, e.g. to generate test data

Ways to convince others that testing is adding value

  • Difference between being seen as personally valuable against the test team adding value
  • Overheard: “Testing is necessary waste”
  • Find issues that your stakeholders care about
  • … these needn’t be in the product, they can be e.g. holes in requirements
  • … but the stakeholders need to see what the impact of proceeding without addressing the issues could be
  • Be humble and efficient and professional and consistent and show respect to your colleagues and the project
  • Make your reporting really solid – what we did (and didn’t); what we found; what the value of that work was (and why)
  • … even when you find no issues


לעניות דעתי In my humble opinion (אשרי אדם מפחד תמיד Happy is the man who always fears)

On May 25, 2016, in Syndicated, by Association for Software Testing

לא מאוד מזמן, נתקלתי דרך Humble Bundle במשחק בשם “מכונת משאבי אנוש“. זה משחק ששמתי עליו עין כבר לפני זמן מה, אבל החלטתי שמחיר של 10$ למה שיהיה לכל היותר שעשוע קצרצר זה מוגזם. לעומת זאת, כאשר פורסם באנדל שכלל את המשחק, החלטתי שאני מוכן לשלם דולר כדי לקנות את המשחק הזה (ועוד שניים או שלושה משחקים שכנראה שלא אשחק בהם לעולם), ועל הדרך, חלק מהכסף מגיע לצדקה – אז למה לא?

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

אז למה שמתי לב בזמן ששיחקתי במשחק הזה?

  1. היה לי הרבה יותר קל לשחק במשחק הזה מאשר לאחרים, כי ידעתי שאני מתכנת, ויש לי ניסיון מסוים בתכנות. 
  2. תוך כדי משחק, הרגשתי בחסרונן של כמה פקודות בסיסיות מאוד – כן, זה הרבה יותר פשוט לתכנת את המשחק אם שומרים את סט הפקודות בסיסי, ואפשר בהחלט לעשות כך הכל – אבל זה כל כך מתיש! אם אני כותב באסמבלי, למה אני לא יכול לקפוץ לשורה בתוך הקוד כדי ליצור לעצמי פונקציות? כתוצאה מכך, הקוד שכתבתי היה משמעותית פחות יפה מאשר רציתי שיהיה (כי בשביל קוד יפה הייתי זקוק לפונקציות, או לפקודת “קפוץ אם גדול מאפס”, למשל). 
  3. ומילא פקודות חסרות – הייתה פונקציה אחת שהרגיזה אותי במיוחד – המשחק מאפשר לכתוב תוויות – גם על שמות של משתנים (בלוקים על הרצפה) וגם לפני חלקים בקוד (ממש כמו תוויות באסמבלי). לכאורה – אחלה! בפועל, כדי לכתוב תווית נאלצתי לצייר אותה בעזרת העכבר. לכתוב בעזרת המקלדת? לא ולא. אז מה אם זה לוקח לי פי עשרה יותר זמן?
  4. כשהבעיות הסתבכו, הממשק הגרפי הידידותי להפליא בעיקר הפריע – כשהקוד הנדרש היה ארוך, או אם רציתי לנסות ולשפץ את הפיתרון כדי להצליח להגיע לאתגרים הספציפיים – פשוט פתחתי notepad וכתבתי את התוכנה שם. כל ההתעסקות הזו עם חיצים שזזים ממקום למקום בעיקר סיבכה את העין והסיחה את דעתי. 
  5. ככה שמתי לב שלוקח לי הרבה פחות זמן לכתוב את התוכנה שלי מחוץ למשחק. גם בלי בזבוז הזמן על התוויות, לגרור משהו למקום הנכון (ובמקרה של פקודות “קפוץ ל…”, לגרור שני דברים) פשוט לוקח הרבה יותר זמן מאשר לכתוב את הפקודה הרצוייה.
וכמובן, כל הדברים האלה רלוונטיים גם לתוכנות אוטומציה להמונים. צריך לנסח אותן טיפה אחרת, אבל העיקרון דומה. 
  1. למתכנתים יהיה קל יותר להפעיל תוכנות כאלה. בסופו של יום, עיקר ההבדל בין מתכנת לבין מי שאינו מתכנת הוא בהבנה של איך כותבים אלגוריתם – וגם אם גוררים ציורים יפים פה ושם, הם צריכים להתנהג כמו תוכנה. אפשר לרכוש מיומנות גם בלי רקע בתכנות, אבל זה רק אומר שלומדים לתכנת תוך כדי עבודה. 
  2. “קוד” שנכתב בעזרת כלי כזה לעולם יהיה פחות אלגנטי ופחות יעיל מקוד שנכתב בשפת תכנות מלאה – כדי לשמור על דברים פשוטים יחסית, התוכנה תאפשר סט פעולות מצומצם יותר. אפילו אם אפשר יהיה לשמור קטעי קוד בתוך התוכנה (SoapUI מאפשרת להכניס קוד groovy, אם אני זוכר נכון) – עדיין יהיה מדובר בקטעי קוד מבודדים, עם ממשק מוגבל להעברת נתונים בין קטעי קוד. 
  3. לכל כלי גרפי יהיו המוזרויות שלו – דברים שהמפתחים החליטו שצריכים להתנהג בצורה מסויימת, ולמשתמש אין מה לעשות חוץ מאשר להתרגל. כן, זה כך גם בשפות תכנות, אבל בממשק גרפי זה מורגש יותר ומגביל יותר. 
  4. ממשקים גרפיים מוספים רעש ומפריעים למוח להתמקד בבעיה. אם בשפת תכנות אני יכול להוציא את קטע הקוד בו אני מתמקד לפונקציה נפרדת או למחלקה חדשה בתוך חמש שניות – טרם נתקלתי בממשק גרפי שמאפשר לי גמישות שכזו, ובחלק גדול מהם -גם אם הצלחתי לבודד את הקטע בו אני רוצה להתמקד, השאר יהיו שם כדי לעשות לי רעש בעיניים או להחביא מידע חשוב מאחורי רשימות מתקפלות. 
  5. תכנות דרך ממשק גרפי הוא יקר באופן משמעותי בהשוואה לתכנות בטקסט. 
אז האם אני אומר שאין טעם להשתמש בכלים לאוטומציה ללא קוד? לא, לא בדיוק. לפעמים זול יותר לתת למישהו ללמוד כלי ספציפי ולהסתפק בתוצאות סבירות עם זמן כתיבה קצת יקר מאשר לשלם למתכנת ולהקים פרוייקט קוד של ממש שיעשה את העבודה באופן קצת יותר יעיל. אבל אני חושב שאם ניגשים לפרוייקט כזה, כדאי לדעת על מה מוותרים ולשם מה. כי למרות שהכלי בו משתמשים עשוי להיראות ממש מוצלח, ולאפשר כל פעולה שאנחנו מצליחים לחשוב עליה כרגע – אנחנו משלמים איפשהו את מחיר הפשטות ועדיף להיות מודעים  לכך.
חוץ מזה, המשחק הזה די חמוד.
Not very long ago I came, via humble bundle, across a game called “Human Resource Machine“. It’s a game I’ve noticed quite a while ago, but decided that while 10$ isn’t much at all, it is still more than I’m willing to pay for what would probably be a fairly short amusement with almost no challenge. So, since humble bundle offers a “pay what you wish”, I bought this game (alongside two or three other games I won’t even install on my PC, not to mention play) at tenth of the usual price of the game. 
In case you skipped the video in the link above, the way the game goes is as follows –  Each level looks the same: there’s an input queue, an output queue, a work floor and a place to write instructions. Only two things change between levels: the possible inputs in the queue, and the required output. For example, one level might be “move only the even numbers to the output queue and discard the rest” and another might be “for each number in the input, output all Fibonacci numbers that are not bigger than it. (so, for the input “10”, output 1,1,2,3,5,8). In order to achieve this goal, you have a set of up to 11 possible commands: take from inbox, put in outbox, copy to a tile in the work-floor, copy from a tile, increase a tile by 1, decrease a tile by 1, subtract, add, jump to command, jump if zero, jump if negative. 
Those of you who have seen an assembly code once or twice in their life can surely see the similarity. The rest – trust me, it’s a fully capable assembly programming language. 
The game itself is quite nice, and optimizing the solutions for the higher levels is a bit of a challenge even to someone with formal CS background and a bit of university-level experience in assembly such as myself (I’m assuming it wouldn’t be any problem for those with some practical experience with assembly), but it made me think about the plethora of tools meant to provide non-programming testers with automation capabilities.
How did I get from playing a game to thinking about commercial, sometimes very powerful tools? Well, the basic goal is the same – to have people programming without noticing this is what they do. I think we can learn something about those tools by looking at the game and projecting this on the click-programming tools.

  1. I had it much easier than others. I knew I was programming and I was familiar with assembly. 
  2. While playing, I strongly felt the need of certain basic commands. True, it is simpler to program the game while keeping the instruction-set to a minimal, and everything can be done this way – but this is so very much more frustrating this way. Why couldn’t I jump to a line in my code? or even better, have a “call function” functionality? As a result, the code I had in the game was not as clean as I would like it to be – there’s a limitation to what I could do without functions, or even a “jump if greater” command. 
  3. On top of the missing instructions, I found one existing, and quite needed feature to be extremely annoying. It was the labeling mechanism.The game allows for creation of labels by drawing pictures on a limited space. Both pieces of code and tiles on the work-floor can be labeled. However, the process of creating a label required me to doodle a word using the mouse. Writing with the keyboard? nope. So i spent about 30 seconds drawing “first” instead of typing it in two. In the cases I skipped using labels, I ended up confusing myself. 
  4. When I got to the more complex problems, especially to those requiring long code, or those where I didn’t manage to optimize the solution easily, I wrote my program in notepad++ before copying it to the GUI. Messing around with dragging and dropping commands, placing them properly (with jump commands requiring two such actions!), was taking me too long to properly think. Moreover – I couldn’t think properly when looking at the spaghetti code I had. One can’t really write assembly code without jumping, since every “if” statement is jumping somewhere, but with the GUI I could see the lines intersecting, and most of the times had to scroll up or down in order to see where I was jumping to or from. Processing the information from the GUI took more thinking resources from me than sorting out the algorithm in a clean textual way. 
  5. by writing stuff in notepad I noticed that even when I knew what I should do and did not have to stop thinking, writing code was tenfold faster than dragging stuff in the GUI. Even without the labels mess – working with the mouse is that much slower than typing. 

All of those points are, to some extent, relevant to all “you don’t need to be a programmer” tools. and here’s how I try to generalize them: 

  1.   Even with those programs, programmers will have an easier time generating more valuable product. The concepts of code reuse, being able to design an algorithm to solve a problem and the rest of the programming shticks really apply to this type of programming as well – not everything is feasible in every tool, but programming with a  GUI is still programming. 
  2. “Code” written with such tools will, most of the time, be less pretty than proper code written in a proper programming language. If the tool is really good, most of the mess will be hidden under the carpet and the developer working with this tool won’t notice the mess, or it would be quite expensive to design and implement a framework that will be cleaner. Even when one have the ability to write code snippets, moving data between code snippets will be limited to the way chosen by the tool. Making the tool itself communicate with your code snippet is even more limited – could I return an error code from a snippet that will direct the choice of the next step performed by the tool? The tool can parse only the interface chosen for it. 
  3.  Every graphic tool will have its own quirks – missing functionality, hidden stuff, common actions that take 5 clicks to perform or even simply doing things in a certain way, and the users can only grind their teeth and get used to it. It is also true for any programming language (really, Python? white spaces are syntax??), but in a GUI those nuisances are more present and a whole lot more annoying. 
  4. Graphic user interfaces add a whole lot of noise that interferes with engaging the programmatic problem. In any decent IDE I can take a problematic piece of code I want to focus on and extract it to a method or to a new class in less than five seconds, where I can then look only at the code I want to think about. I have yet to see a graphic tool that enables this.
    And even if there is something equivalent – all of those graphic hints (“this is a data source”, “this is a piece of code”, “this is an assertion”) still require some brain power to parse. Yes, it gets better as one gets used to the graphic language, but my guess is that it still requires more than simply reading text. 
  5. Programming through a GUI is way more expensive than using text. 
So, what am i saying, that such tools are useless? That everyone should just learn to program and write their own code? While tempting – that’s not what I say. Those tools (at least the good ones) do serve a purpose, and for that purpose they do very well – a non-programmer can definitely benefit from them, and even for a programmer, they tend to save quite a while of setting up your own infrastructure.
What I am saying, though, is that those tools, shiny as they may be, contain a rotten core – some fundamental limitation that will punish you some day. It might be an explosion of hard to manage “scenarios” (or “suites”, or whatever), it might be that you’ll start building large objects that will make the tool UI slow, or it might only be the fact that you get to the point where you have exhausted the potential of the tool, and now you can’t augment it (or it is really hard to augment and you waste a lot of time finding a workaround). But, as this bite might not be that bad, it does make sense, in some cases, to use such a tool. However, when you do consider choosing such a tool, take its promises with a pinch of salt, and be aware of what you are losing, not only what you  might gain. 
Besides, this game is quite cute. 
Page 1 of 41234

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!