Archives

Cambridge Lean Coffee (Hiccupps)

On April 26, 2017, in Syndicated, by Association for Software Testing
0

This month’s Lean Coffee was hosted by DisplayLink. Here’s some brief, aggregated comments and questions  on topics covered by the group I was in.How to spread knowledge between testers in different teams, and how often should peopl…

Bad Meaning Good (Hiccupps)

On April 23, 2017, in Syndicated, by Association for Software Testing
0

Good Products Bad Products by James L. Adams seeks, according to its cover, to describe “essential elements to achieving superior quality.” Sounds good! As I said in my first (and failed) attempt to blog about this book, I’m interested in quality. But in the introduction (p. 2) Adams is cautious about what he means by it:

Quality is a slippery, complex, and sometimes abstract concept … Philosophers have spent a great deal of time dealing with the concept of quality. This is not a book on semantics or philosophy, so for our purposes we will simply assume that quality means “good.” But, of course, that leaves us with “good for whom?” “good for what?” “good when?” “good where?” and if you really like to pick nits, “what do you mean by good?” I won’t go there, either.

My bias is towards being interested in the semantics and so I’d have liked not to have seen a concept apparently so fundamental to the book being essentially dismissed in the space of a paragraph on the second page of the introduction. Which isn’t to say that quality is not referred to frequently in the book itself, nor that Adams has nothing to say about quality. He does, for example when thinking about why improving the quality of a manufacturing process is often considered a more tractable problem than improving the quality of the product being manufactured (p. 25):

characteristics of good products, such as elegance, and the emotions involved with outstanding products, namely love, are not easily described by [words, maths, experiment and quantification] – you can’t put a number on elegance or love.

Further, he’s clearly thought long and hard about the topic, and I’d be surprised if he hasn’t wrestled at length with definitions of quality – having spent no little time exploring my own definition of testing, I have sympathy for anyone trying to define anything they know and care about – before deciding to pursue this line. What’s reassuring to see is that Adams is clear that whatever quality or goodness of a product is, it’s relative to people, task, time and place.

He references David Garvin’s Competing on the Eight Dimensions of Quality, which I don’t recall coming across before, and which includes two dimensions that I found particularly interesting: serviceability (the extent to which you can fix a product when it breaks, and the timeliness with which that takes place) and perceived quality (which is to do with branding, reputation, context and so on).

I was reading recently about how experiments in the experience of eating show that, amongst many other factors, heavier cutlery – which we might naturally perceive to be better quality – enhances the perception of the taste of the food:

… we hypothesized that cutlery of better quality could have an influence on the perceived quality of the food consumed with it. Understanding the factors that determine the influence of the cutlery could be of great interest to designers, chefs, and the general public alike.

Adams also provides a set of human factors that he deems important in relation to quality: physical fit, sensory fit, cognitive fit, safety and health, and complexity. He correctly, in my opinion, notes that complexity is a factor that influences the others, and deems it worthy of separation.

A particularly novel aspect for me is that he talks of it in part as a consideration that has influence across products. For example, while any given car might be sufficiently uncomplex to operate, the differences in details between cars can make using an unfamiliar one a disconcerting experience (p.91): “I … am tired of starting the windshield wipers instead of the turn signal.”  He admits a tension between desiring standardisation in products and wanting designers to be free to be creative. (And this is the nub of Don Norman’s book, The Design of Everyday Things, that I wrote about recently.)

It’s not a surprise to me that factors external to the product itself – such as familiarity and branding – govern its perceived quality, but it’s interesting to see those extrinsic factors considered as a dimension of intrinsic quality. I wondered whether Weinberg’s classic definition of quality has something to say about this. According to Weinberg (see for example Agile and the Definition of Quality):

  Quality is value to some person.

And value is a measure of the amount that the person would pay for the product. Consider I’m eating a meal at a restaurant: if my enjoyment of the food is enhanced by heavier cutlery, but the cost to me remains the same as with lighter cutlery, then in some real sense the value of the food to me is higher and so I can consider the food to be of higher quality. The context can affect the product.

Alternatively, perhaps in that experiment, what I’m buying is the whole dining experience, and not the plate of food. In which case, the experiential factors are not contextual at all but fundamental parts of the product. (And, in fact, note that I can consider quality of aspects of that whole differently.)

Weinberg’s definition exists in a space where, as he puts it,

the definition of “quality” is always political and emotional, because it always involves a series of decisions about whose opinions count, and how much they count relative to one another. Of course, much of the time these political/emotional decisions – like all important political/emotional decisions – are hidden from public view. 

Political, yes, and also personal. Adams writes (p. 43)

Thanks to computers and research it seems to me that we have gotten better at purely technical problem solving but not necessarily at how to make products that increase the quality of people’s lives – a situation that has attracted more and more of my interest.

And so there’s another dimension to consider: even a low quality item (by some measure, such as how well it is built) can improve a person’s quality of life. I buy some things from the pound shop, knowing that they won’t last, knowing that there are better quality versions of those items, because the trade-off for me, for now, between cost and benefit is the right one.

Bad product: good product, I might say.
Image: Amazon

Walking the Lines (Hiccupps)

On April 22, 2017, in Syndicated, by Association for Software Testing
0

I recently became interested in turning bad ideas into good ones after listening to Reflection as a Service. At around that time I was flicking through the references in Weinberg on Writing – I forget what for – when I spotted a note about Conceptual B…

Remote agile teams. (zagorski software tester)

On April 22, 2017, in Syndicated, by Association for Software Testing
0

Reading Time: 2 minutesTL;DR This post is about using narratives in software development. I presented this idea at Brighton TestBash 2017 Open Space session. At that session we had two groups, one group was collocated agile team that is using in person communication almost all the time, opposite group was me, remote tester that is using communication tools … Continue reading Remote agile teams.

A Special Thank You

On April 20, 2017, in #engagedmembership, General, News, Newsletter, by alemoreira
0

I have been a long time member of the AST and almost 3 years ago, at CAST2014 in New York, something pretty special happened: I was elected a board member. It was an exciting time! The years that followed were great at the board and I learned a lot about the operations of a non-profit […]

2017-2018 Board of Directors Nominations Now Open

On April 20, 2017, in News, Newsletter, by jrohrman
0

The nomination period for the 2017-2018 Board of Directors (BOD) is now open. If you would like to nominate yourself or someone else to the BOD election slate, please be aware of the AST Bylaws, which are explicit: Nominees must have become AST Members prior to August 17, 2016 and contiguously since then All nominations […]

שתיים ועוד שלוש הן חמש Two plus three is five (אשרי אדם מפחד תמיד Happy is the man who always fears)

On April 18, 2017, in Syndicated, by Association for Software Testing
0
Source: Every conversation between a parent an a child in four conversations (link in the text)
– אני יכול את זה?
– לא? 
– אולי לא הסברתי את עצמי היטב, ביקשתי כי אני רוצה את זה. 
– למעשה, הבנתי.
– אולי אינך שומע אותי היטב, אני רוצה את זה.
הקטע הזה ממשיך עוד קצת (והרבה יותר מוצלח בלי התרגום החובבני שלי) ואפשר לקרוא את כולו כאן (ומשם גם התמונה בראש. לאחרונה אני נזכר בטקסט הזה לא מעט. 
ואיך כל זה קשור לתוכנה? זה לא סוד שיש לפעמים פערים בתקשורת בין מהנדסים לבין האנשים שמנהלים את הצד העסקי של הדברים – אנשי מכירות, מנהלי מוצר וכדומה. הפערים הללו מתבטאים לרוב בדרישות מורכבות, לוחות זמנים בלתי אפשריים או סתם בקשות חסרות פשר. בערך כמו שקורה למומחה הקווים האדומים (וכן, גם בסרטון הזה אני נזכר לא מעט, באותו הקשר). 
בעבודה, יש לנו פרוייקט חדש. יש לו תאריך סיום שלא אנחנו קובעים, קצת כמו שתעשיית המשחקים לא קובעת מתי בדיוק תגיע עונת החגים. הפרוייקט היה צריך להתחיל לפני הרבה זמן אבל בגלל עומס של דברים דחופים לא פחות, לא באמת התחיל לזוז עד לפני חודשיים-שלושה. במהלך הזמן הזה, הקדשנו המון זמן לישיבות אינסופיות בהן מנהלי המוצר ניסו להבין איך אנחנו יכולים גם לא לאחר בשנה וגם להכניס פנימה את כל התוכן שאנחנו רוצים. תוכניות נכתבו, שעות הושקעו בהערכת מאמצים, מדי פעם נערכו כמה חשבונות בסגנון “אם נשים עשרים אנשים על הפרוייקט, נסיים אותו בתוך תשעה חודשים” (מה שהזכיר לי את הבדיחה על מנהלי פרוייקטים והריונות), מה שהוביל לכל מיני משחקים בהם עובדים חדשים הופיעו יש מאין, משל היינו בתרגיל צבאי ומנהל הפרוייקט הוא השליש שמשלים את מצבת הלוחמים במטה קסם, תוך התעלמות מוחלטת מכך שלוקח לנו לפחות שלושה חודשים לאייש משרה.
בקיצור, למישהו היה כיף, והמישהו הזה לא היה אני. אבל, סוף כל סוף, נגמרו הקשקושים ואפשר לומר שאפשר להתרכז בעבודה ולא בתכנונה. ואז, במסגרת אחת מישיבות העדכון, מנהלת המוצר הודיעה על שינוי כיוון – אחד הספיחים לפרוייקט הזה הוא שיתוף פעולה בינינו לבין חברה אחרת, ושיתוף הפעולה הזה אמור להכניס לא מעט כסף לכל הגורמים המעורבים. כל התוכניות שנעשו עד כה הניחו שאנחנו יכולים לסמוך על כך שסיימנו את עיקר הפרוייקט הראשי ולהשתמש במה שנבנה שם, מה שמיקם את הספיח במרחק יפה על לוח השנה. ובכן, שינוי הכיוון היה כזה – הנהלה החליטו שאנחנו רוצים את הספיח מוקדם ככל שאפשר. רגע, מה? זה אומר שכל העבודה שצריך לעשות לפרוייקט הראשי ונדרשת כדי לתמוך בספיח צריכה להיעשות קודם. כלומר, כל מה שחסכנו הוא חודשיים או שלושה. תגובת מנהלת  המוצר הייתה פשוטה, ומרגיזה להחריד – “זה לא מספיק טוב, אני צריכה תוכנית שתאפשר לנו להעלות את זה לאוויר בתוך חודשיים מהיום”. אוקי, אנחנו מכירים את המשחק. בטווח של חודשיים לא רלוונטי לדבר על תוספת משאבים, ואם התאריך נעול, כל מה שנשאר לדבר עליו הוא על התוכן. אבל גם על התוכן אי אפשר לוותר, כי את כל הוויתורים כבר עשינו כשהגדרנו את הפרוייקט הראשי. בכל זאת, בדקנו – “האם את מוכנה לוותר על א’?” “לא”. כך גם לב’ וג’. בקיצור – איך שלא מסובבים את זה, הבקשה היא לדחוף תשעה חודשים קלנדריים (לא חודשי אדם) לתוך שלושה. התגובה לכל הסבר שמצביע על הפער הזה הייתה “אז תעשו משהו מהיר ומלוכלך” (עד לנקודה בה אחד המפתחים הסביר שאנחנו אמנם יכולים לכתוב את הקוד מלוכלך יותר, אבל יותר מלוכלך ממה שכבר מתוכנן לא יהיה מהיר יותר).
אני יצאתי מתוסכל מאוד מהישיבה הזו, מקטר ביני לבין עצמי שזה לא משנה אם סופרים שתיים ועוד שלוש או שלוש ועוד שתיים, ואפילו לא שתיים ועוד שתיים ועוד אחת – התוצאה תמיד נשארת חמש ולעולם לא תהיה ארבע.

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

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

Child: Can I have this?
Me: No.
Child: Ah, perhaps I’ve miscommunicated. I’m asking for it because I want it.
Me: I understood that, actually.
Child: I think maybe you’re not hearing me. I’d like it because I want it.

This quote is from a longer text that goes on (and gets funnier), which you can read here. Lately, I’m reminded quite often of this text. 
And what does it have to do with software, you wonder? Well, it’s no secret that there are sometimes gaps between engineers and business people – salespersons, project managers etc. . Those gaps often manifest as complex requirements, impossible timelines of simply senseless requests, as is happening to this poor red lines expert (yes, I’m reminded of this video as well, in the same context). 
We have a new project at work. It has a deadline that we do not set, in the same manner that the gaming industry cannot move holiday season just because the game is a bit more complex to build. Worse – this project should have started quite a while ago, but a load of other urgent tasks didn’t actually begin to move until about three months ago. So, what’s the first thing to do when you start a project late? Naturally, begin with a month-long estimations and planning phase. Ok, I’m being a bit over-sarcastic here, as the planning was quite important for us to know what we actually need to do, and start having a discussion about what must be released in the first deadline of the project and what can wait a bit, so there was value to it, but it was just so annoying to go through.  During those endless meetings, the product management goal was to understand how can we get all of the content that we need and not miss our scheduled release date in a year or so.at certain times there were some calculations such as “if we’d put 20 people on the project, we could be done in 9 months”. This reminded me the joke about project managers and child bearing and then I was reminded of some war-games where dead or injured soldiers are magically replaced by other troops when the discussion started guessing that we could assume we’d recruit three new employees within the next couple of months, ignoring the history (in which finding a suitable candidate usually takes us between 3 and 6 months during which the effectiveness of the employees interviewing drops sharply).
So, to state it simply – someone was having fun, and that someone wasn’t me. But, finally, we got to the point where we can shift our time and focus from talking to doing. great. Then, during one of the update meetings the project manager announced a change of direction: One of the side tracks to this project was another sub-project that depended on many of the capabilities in the main project. This  sub project is a collaboration between us and another company, and should produce a nice revenue to all involved parties. So, instead of waiting until the main project is done, now we want to have the sub-project done as quickly as can be, so all of the work that had to be done in the main project and supports the sub project now have to be done separately and all that we would save is probably two or three calendar months. The product manager’s response was simple and frustrating: “This isn’t good enough, I need a plan that will enable us to go live with this in a couple of months”. OK, we know this game – it’s the triangle of resources\time\content.  Since it’s a schedule of 2 months, adding people is not really an option, and the time is set, so it must be content. However, we already cut content to a minimum when defining the main project. Still, we asked “Are you willing to give up on A?” the answer was “no, we must have A”, and the same went for B and C. In short, we were asked to find a way to cram some 9 calendar months into 3. Doesn’t really matter how you do the math, it does not work. Any attempt to explain this was met with the response “just do something quick and dirty”. This phrase came up so many times in the conversation that one of the developers reacted with “we can do it as dirty as they want it to be, but at the point we are, dirtier won’t be quicker”.
Personally, I got out of this meeting feeling very frustrated and ranting to myself that two and three is five, as is three and two, and even two and two and one – it does not matter how you count it, it won’t stop being five.

But, later that day something interesting happened. After we were done ranting and got used to the fact that this new requirement is the reality – we need to do something in three months, what can we suggest?  – we came up with a solution: it solves only part of the problem, and it depends in our partner’s capabilities and goodwill, but we can do it in a single month. We have something management can work with.
This made me think – It’s really easy  to rant about how management knows nothing, It’s easy to be annoyed with impossible schedules. But the whole purpose of a delivery team is to find solutions to problems. Those won’t always be perfect or complete (or on schedule), but they are still good solutions. Sometimes, that little annoying brat who says “I want it!” and won’t take no for an answer is what needed to nudge the team to find a solution.

Also, on another note – you people who preach #NoEstimates , how do you cope with projects of this size that have a deadline and you need to know whether or not you should recruit more people? If there’s something these last months convinced me it’s that I really don’t enjoy estimating stuff. I would love to hear of another way of dealing with this problem. 

What is software testing according to the “others” (Mr.Slavchev())

On April 18, 2017, in Syndicated, by Association for Software Testing
0

I took a long break from blogging and the series of “what software testing is”, so before I go back to them, I would like to share my personal observations on some interesting facts. It’s actually related to what software testing is, but it’s sort of outsider’s view. It’s actually part of the reasons why […]

The post What is software testing according to the “others” appeared first on Mr.Slavchev().

Week 15 reading list (zagorski software tester)

On April 15, 2017, in Syndicated, by Association for Software Testing
0

Reading Time: 0 minuteby

UX issue in comic book (zagorski software tester)

On April 15, 2017, in Syndicated, by Association for Software Testing
0

Reading Time: 1 minuteTL;DR This post is about my other passion, comic books. I found one UX issue while enjoying Inkal comic book. Observe following photo: On the right side, my user experience was broken. Can you identify the issue? Everybody who reads from left to right, reads comic books in the same fashion. Actually, expects that comic book panels … Continue reading UX issue in comic book

Page 1 of 3123

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!