Archives

Engagify Before You Gamify Testing (Assert.This)

On March 30, 2016, in Syndicated, by Association for Software Testing
0

Gamification is the practice of wrapping an activity in a game like context to make the process more interesting. It’s pervasive and examples are everywhere. At its worst it sounds like psychological warfare upon customers to increase potential for addictive or compulsive use hopefully resulting in higher profits, but there are cases where its power … [Read more…]

Takeaways from a Pitching Masterclass (The Pain and Gain of Edward Bear)

On March 29, 2016, in Syndicated, by Association for Software Testing
0

Pitching is 95% practice and 5% inspiration. -Annette Kramer A couple of weeks ago I attended a pitching masterclass by Annette Kramer. It’s part of this strange habit I’ve developed that I watch masterclasses on Youtube to pick up ideas for my own coaching sessions. Now I decided to watch a live one. But more […]

Software testing is not… (Mr.Slavchev())

On March 28, 2016, in Syndicated, by Association for Software Testing
0

This post might be considered  a follow-up to Outdated testing concepts, but with it I’d like to switch the perspective to a bit more general view. After the above mentioned series were published, I went through a lot of feedback, comments and other non-related articles and they made me think. How do anyone, mostly non-testing professionals […]

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

Application variability tour in action (zagorski software tester)

On March 26, 2016, in Syndicated, by Association for Software Testing
0

TL;DR My first contact with software testing was in factory and control schools of software…

The responsibilities of an open-source developer (The Continuous Improver)

On March 24, 2016, in Syndicated, by Association for Software Testing
0

The proudest moment anybody initiating an open-source project can experience is when that project finally gains the momentum to make a difference within the community it targets. When my colleague Martin and I published the first release of Fluent Assertions on CodePlex in 2011 (yeah, those were the days), not even in our wildest dreams we expected that by 2016 our NuGet package would have been downloaded that much. Next to that, almost every week, somebody posts a blog post about our little .NET assertion library. And if you scan nugetmusthaves.com, you’ll find 54 packages relying on Fluent Assertions. It supports all current .NET versions and platforms including Xamarin (by Oren Novotny). And even the .NET Core Lab team is using it, which is why we support CoreCLR, .NET Native and .NET 4.6 since it earliest betas.

But with that popularity comes great responsibility…

Rather than working on the next killer feature or API, you’ll be spending a lot of your private time answering questions on GitHub, Gitter, StackOverflow or email. And if you do that, stay friendly and constructive. Thank them for taken the time to file an issue, and do that in a timely fashion. Nothing is more annoying for somebody that uses your library, runs into an issue he or she can’t resolve, takes the time to post about it and doesn’t get a response in weeks. That sure is a recipe for losing some fans quickly. Even if you believe they’ve made the mistake and everything is fine with your library, take the time to explain your reasoning behind it. More than often I expected to get some nasty repute when I rejected an issue. But I’ve come to learn that people are just happy to get some help to get them going.

Sometimes the issue is more complex, e.g. when somebody is using your library in an unsupported way (you’ll be surprised what people think of sometimes). Explain them the design philosophy behind your library and why you’re rejecting a particular issue. If possible and – like Fluent Assertions – you offer extension points, provide them with a link to some example that shows them how to build their own extensions. If it’s a potential bug which you can’t reproduce easily, be not afraid to ask them to help you reproduce it or request a little project that reproduces the problem. Now, most open-source developers I do know don’t have the free time to build every possible feature that is requested. So if you do think their issue or suggestion has merits, tell them that you’re accepting pull requests.

Now that I mentioned that, I need to explain my philosophy on using open-source software in professional software development. If it’s up to me, you can use whatever open-source library you want to use, but only if it meets one of following two requirements.

  1. It’s backed by a large group of developers or contribution base. So if one of the original authors abandons the project, there’s no risk to the project itself.
  2. Its code is well-written, readable, properly documented and heavily covered by unit tests at a level that your confident enough to continue supporting the code as part of your own code base.

With this in mind, I think I have the following responsibilities towards my own project.

  • Ensure that all code uses the same layout, coding styles and naming conventions.
  • Make the code a testimony on how I envision high-quality code.
  • All public and protected APIs are properly documented.
  • All changes are backwards compatibility with prior versions. If breaking changes are needed, they get staged for a next major release.
  • The API is consistent and follows the Principle of Least Surprise.
  • All edge cases are covered by well-factored unit tests.
  • Ensure a clean source control history that will make it easy for contributors and users to find out what has been fixed when.

These will hopefully encourage more people to join the project and will lower the threshold for those cases where somebody needs to fork the code and start to maintain it themselves.

I expect it to be no surprise that these responsibilities in some form transfer to contributors who submit a pull request. And that’s the hard part. You should show contributors the respect that they deserve. They’ve decided to commit a potentially substantial amount of their free time to provide you with a pull request that solves a particular bug or adds a feature, so show how much you value that. Sometimes you won’t get a single PR in weeks, but then you suddenly receive a couple of them in a short time. If you’re lucky, those PRs meet whatever requirements you’ve set (e.g. by using Github templates) to honor responsibilities such as I mentioned above. If not, you have to decide how to deal with that. You can decide to take the PR as-is and do the rework yourself, or, as I tend to do, do a thorough code-review and ask them if they’re willing to pick up the rework. And that’s a double-edged sword. Either you do the work in your precious free time, or you risk discouraging contributors from contributing again.

So what do you think about this? Do you agree with the responsibilities of an open-source project? Would you accept any PR or do you prefer to uphold you standards? I’d love to hear your thoughts by commenting below.

That being said. Now you know how I think about all this, if you would like to join the ranks of those that made Fluent Assertions such a great library, we have lots of work up for grabs. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.

The responsibilities of an open-source developer (The Continuous Improver)

On March 24, 2016, in Syndicated, by Association for Software Testing
0

The proudest moment anybody initiating an open-source project can experience is when that project finally gains the momentum to make a difference within the community it targets. When my colleague Martin and I published the first release of Fluent Assertions on CodePlex in 2011 (yeah, those were the days), not even in our wildest dreams we expected that by 2016 our NuGet package would have been downloaded that much. Next to that, almost every week, somebody posts a blog post about our little .NET assertion library. And if you scan nugetmusthaves.com, you’ll find 54 packages relying on Fluent Assertions. It supports all current .NET versions and platforms including Xamarin (by Oren Novotny). And even the .NET Core Lab team is using it, which is why we support CoreCLR, .NET Native and .NET 4.6 since it earliest betas.

But with that popularity comes great responsibility…

Rather than working on the next killer feature or API, you’ll be spending a lot of your private time answering questions on GitHub, Gitter, StackOverflow or email. And if you do that, stay friendly and constructive. Thank them for taken the time to file an issue, and do that in a timely fashion. Nothing is more annoying for somebody that uses your library, runs into an issue he or she can’t resolve, takes the time to post about it and doesn’t get a response in weeks. That sure is a recipe for losing some fans quickly. Even if you believe they’ve made the mistake and everything is fine with your library, take the time to explain your reasoning behind it. More than often I expected to get some nasty repute when I rejected an issue. But I’ve come to learn that people are just happy to get some help to get them going.

Sometimes the issue is more complex, e.g. when somebody is using your library in an unsupported way (you’ll be surprised what people think of sometimes). Explain them the design philosophy behind your library and why you’re rejecting a particular issue. If possible and – like Fluent Assertions – you offer extension points, provide them with a link to some example that shows them how to build their own extensions. If it’s a potential bug which you can’t reproduce easily, be not afraid to ask them to help you reproduce it or request a little project that reproduces the problem. Now, most open-source developers I do know don’t have the free time to build every possible feature that is requested. So if you do think their issue or suggestion has merits, tell them that you’re accepting pull requests.

Now that I mentioned that, I need to explain my philosophy on using open-source software in professional software development. If it’s up to me, you can use whatever open-source library you want to use, but only if it meets one of following two requirements.

  1. It’s backed by a large group of developers or contribution base. So if one of the original authors abandons the project, there’s no risk to the project itself.
  2. Its code is well-written, readable, properly documented and heavily covered by unit tests at a level that your confident enough to continue supporting the code as part of your own code base.

With this in mind, I think I have the following responsibilities towards my own project.

  • Ensure that all code uses the same layout, coding styles and naming conventions.
  • Make the code a testimony on how I envision high-quality code.
  • All public and protected APIs are properly documented.
  • All changes are backwards compatibility with prior versions. If breaking changes are needed, they get staged for a next major release.
  • The API is consistent and follows the Principle of Least Surprise.
  • All edge cases are covered by well-factored unit tests.
  • Ensure a clean source control history that will make it easy for contributors and users to find out what has been fixed when.

These will hopefully encourage more people to join the project and will lower the threshold for those cases where somebody needs to fork the code and start to maintain it themselves.

I expect it to be no surprise that these responsibilities in some form transfer to contributors who submit a pull request. And that’s the hard part. You should show contributors the respect that they deserve. They’ve decided to commit a potentially substantial amount of their free time to provide you with a pull request that solves a particular bug or adds a feature, so show how much you value that. Sometimes you won’t get a single PR in weeks, but then you suddenly receive a couple of them in a short time. If you’re lucky, those PRs meet whatever requirements you’ve set (e.g. by using Github templates) to honor responsibilities such as I mentioned above. If not, you have to decide how to deal with that. You can decide to take the PR as-is and do the rework yourself, or, as I tend to do, do a thorough code-review and ask them if they’re willing to pick up the rework. And that’s a double-edged sword. Either you do the work in your precious free time, or you risk discouraging contributors from contributing again.

So what do you think about this? Do you agree with the responsibilities of an open-source project? Would you accept any PR or do you prefer to uphold you standards? I’d love to hear your thoughts by commenting below.

That being said. Now you know how I think about all this, if you would like to join the ranks of those that made Fluent Assertions such a great library, we have lots of work up for grabs. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.

Getting Out of Here (Hiccupps)

On March 24, 2016, in Syndicated, by Association for Software Testing
0

Some of the testers from Linguamatics went to Cambridge Escape Rooms yesterday. Why? This is from their FAQ:You are locked in a room … and have to solve a series of puzzles and mysteries to escape. You will have to search high and low for clues and w…

Getting Out of Here (Hiccupps)

On March 24, 2016, in Syndicated, by Association for Software Testing
0

Some of the testers from Linguamatics went to Cambridge Escape Rooms yesterday. Why? This is from their FAQ:You are locked in a room … and have to solve a series of puzzles and mysteries to escape. You will have to search high and low for clues and w…

כשאבטחת תוכנה מתנגשת עם הדרישות when functionality and security collide (אשרי אדם מפחד תמיד Happy is the man who always fears)

On March 23, 2016, in Syndicated, by Association for Software Testing
0
אני לא יודע כמה מכם שמו לב, אבל בלוגר החליפו את הדרך בה הם מאפשרים לבעל הבלוג לא לכלול את המחשב שלו במניין הצפיות בבלוג. בעבר, היה מדובר בחלון קופץ עם ההגדרות, שנראה בערך ככה:
Source: http://2.bp.blogspot.com/-UWeVYXHYWaA/Vf5KrOD_ZfI/AAAAAAAACDY/oKFUYDRCFGQ/s1600/dont%2Btrack.png

 כעת לחיצה על הכפתור מובילה לדף חדש בכתובת שנראית פחות או יותר ככה:  https://<blog_name>.blogspot.com/b/statsCookieManage (זה אינו קישור!)
אני מניח שאחת הסיבות לשינוי הזה נובעת מתלונות רבות שהיו על כך שהתכונה הזו לא עובדת (האינטרנט מלא בהן, פשוט לכו לחפש). יכול להיות שיש גם קשר לעבודה עם עוגיות צד שלישי והניסיון לצמצם את השימוש בהן, אבל בכל מקרה – מה היא השאלה הראשונה שעולה בראשו של בודק תוכנה שרואה את ההתנהגות החדשה הזו? נכון מאוד! האם אני יכול לעשות את אותו הדבר בבלוגים שאינם שלי? חמש שניות לאחר מכן, קיבלתי תשובה – אני יכול לגשת לדף הזה, ולפחות למראית עין, ההשפעה של סימון “אל תעקוב אחרי הצפיות שלי” זהה למה שקורה בבלוג שלי. 
תגובה ראשונה – מצאתי באג!
ושנייה אחר כך – רגע, אולי זה בכוונה? 
מצד אחד, המוצר אינו עקבי ביחס להיסטוריה של עצמו, שכן בעבר ניתן היה לגשת לאפשרות הזו רק דרך ממשק הניהול, וממילא רק לבלוגים שאני מנהל.  בנוסף, מה יקרה אם כולם יבחרו לסמן את התיבה הזו? ספירת הכניסות תהפוך ללא אפקטיבית. לכאורה – תקלה. 
מצד שני, יש בזמן האחרון מודעות גבוהה יותר לחשיבות של פרטיות הגולשים. אולי האפשרות הזו גלויה בכוונה? אולי רוצים לאפשר למי שהפרטיות חשובה לו לא להיספר בתוך מניין המבקרים בבלוג? זו כנראה לא הדרך בה אני הייתי נוקט, אבל אולי כך אמור האתר להתנהג? 

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

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

הדילמה הזו קיימת בכל פעם בה שתי דרישות מתנגשות, אבל איתור של דרישות מתנגשות, במיוחד אם אחת מהן “שקופה” (כלומר – לא מקושרת לדרישה פונקציונלית, ולא בהכרח מדידה). לא קל לשים לב שהוספת אימות דו שלבי (2 factor authentication) יכולה ממש להרגיש את המשתמש, או שאיסוף פרטים מועילים עבור התמיכה הטכנית יכולים לפגוע בפרטיות הלקוחות שלהם.
האם יש לכם משהו שאתם עושים כדי למצוא התנגשויות מהסוג הזה?

——————————————————————————-

I don’t know how many of you have noticed, but Blogger has changed the way the “don’t track your own pageviews” work.
At first, it looked like this:

Source: http://2.bp.blogspot.com/-UWeVYXHYWaA/Vf5KrOD_ZfI/AAAAAAAACDY/oKFUYDRCFGQ/s1600/dont%2Btrack.png
Now, the user is redirected to a new page  https://<blog_name>.blogspot.com/b/statsCookieManage (This is not a link!), I guess that one of the reasons, or maybe even the only one, for this change was the number of complaints that the previous implementation was broken and many people complained about it (google it), probably due to most browsers making the life more difficult for 3rd party cookies. Indeed, the new mechanism does redirect to the blog domain, so it shouldn’t cause many problems on that aspect. 
Anyhow, what’s the first question that pops to a tester’s mind when faced with such a feature? Indeed, it is “can I use this feature on blogs not under my control?”. So, quickly after making sure to work around what seems to be another bug (This new feature does not seems to be working across regional domains, so I made sure to check both .com and .co.il ), I went to another blog I follow and got the relevant URL, and Lo and behold – nothing blocks my way. 
Also, as far as I can tell – the behavior seems to be the same (Sure, I couldn’t go and check the actual stats, but I got an identical cookie to present). 
My first reaction: “Yay! I found a bug!”. 
And a second later – “Wait a second. maybe this is on purpose?”
On one hand, this feature is not consistent with its history, and therefore, also with my expectations as a user – before, it didn’t seem that I was able to opt-out of the tracking of blogs that I don’t own, and as a blog owner – I actually look now and then at the pageviews stats and would be very sad if my readers would hide this way. 
But, on the other hand, privacy is a really strong trend these days, and perhaps it is an improvement that enables user to control who sees them and who doesn’t. It might not be the way I would do things, but maybe this behavior is intentional?

Certainly, this problem is not unique to cases where I’m completely out of the loop and have no idea of the business model behind the product. I might find myself facing the same question when working on the product I’m testing. Should we present a helpful, informative, error message, or prevent an attacker from enumerating our current users by checking the error message? Is encrypting another piece of information worth the impact on performance?  Should we provide the customer support useful information or protect the end-user privacy? The decision is not always obvious. 

In this particular case, I think it’s safe to assume a bug – if this was a privacy enhancement, it should have been accessible from any blog I read – not only from the management section. So, instead of a (security) requirement trumping another requirement, I think that the root cause is just that it is a case where a requirement is having an unexpected effect on another. 
At least, I got a nice thinking exercise out of it. 
Do you have ideas that helps to determine when there was a conscious choice to prefer a requirement over another,  and when it’s simply a bug? 
Also, noticing requirements collision is not always easy – it is very easy to miss the fact that our two-factor-authentication may actually be really annoying to  the user? or that when we collect data to improve our services we might be collecting that hinders the user privacy? 
How would you suggest to spot conflicts between transparent requirements (transparent requirements = properties of the software that are not “it does X”, but rather “it is…”, most illities are transparent, as is performance and responsiveness) and functional ones?

Testing the Arbitrary: Mind Mapping a Mug (Assert.This)

On March 23, 2016, in Syndicated, by Association for Software Testing
0

Ah, your friendly every day mug. A temporary home for your coffee, tea, hot chocolate, common enough that you may use one everyday. So why bother spending the time to consider it for testing? Other posts in this series have been inspired by interview questions I have heard people be asked. Testing a mug falls … [Read more…]

Page 1 of 712345...Last »

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!