Add new tag

Nov 12 2009   7:09PM GMT

Using Agile, scaling back helps software projects in recession

Posted by: Dan Mondello
Project management, Add new tag, Software project management, software development

“You are about to embark on a dynamic quality endeavor. It is time to throttle down on your already oversized and over-budget test and development teams.” That was the opening salvo of Michael Mah’s (QSM Associates) SQE Agile Development Practices Conference session, Rightsizing your project in a down economy.

Project teams are just too large, Mah said. Sure, the poor economy has prompted downsizing in this industry; but that could be a blessing in disguise. After all, there have been many years of impractical spending, mismatched teams and dysfunctional workplace goals in software projects.

For too long, Mah said, executives and managers have emphasized speed over quality, judging success by whether teams turn out code lines on time, rather than on delivering in a reasonable time frame quality code that’s free of obvious functional flaws. He’s seen promotions being given to project leaders who met deadlines without ensuring quality. The results? We are paying the ultimate price in lost jobs and market share, he said.

“Now that I have pointed out where the trouble began, let me now explain where the trouble continues,” said Mah. Today, he sees many companies using the recession as an excuse for adopting seriously questionable practices, like trying to cut steps to recovery by cutting down on employees. In the short term, this does free up some cash; but once a company has rebounded or is recovering, new team members will have to be hired. Of course, it takes precious time and money to train new employees and pay for newbie mistakes.

On the other end of the spectrum, there are the overly-cocky executives who have spent more wisely over the years, they see this time where other companies are cutting back and pinching pennies as time to throw money and software at problems. This rarely works, and usually sends these companies into the downward spiral.

In a time of recession, throwing enormous manpower and software at problems will rarely resolve issues. It is more appropriate and intelligent to scale back, says Mah.

To scale back, project leaders should build strong relationships with a small core group of commited employees. Research your service and tool providers more thoroughly, gather references and check them.

“How many of you have some fear about loosing your job?” Mah asked the audience, and nearly all of them held up their hands. “And how does that make you feel? Bad, right?” Company and project leaders are responsible for alleviating fear, not creating it. Fearful teams don’t work productively. Often fear is responded upon with aggression.

The most effective way in managing concerned workers in a recession is by showing “concerned optimism,” Mah said. Explain the situation, but encourage the team. Leaders’ optimism and relationship helps team members feel confident in their abilities and have more belief that they are capable of working on innovative projects. A motivated and innovation-welcoming team is critical to success and growth. Optimism makes for more tolerable working environments and more creative problem solving.

“I remember a good many times I would work through 70+ overtime work weeks; partly because work needed to be done, but also because there was always a chance that the company president would see me there,” said Mah. “On the occasions when he did, he would always compliment me with a thumbs up and a ‘good job.’ That was all the praise I needed.”

---

More coverage from Agile Development Practices:
Early adopters, Agile philanthropy key points in ADP keynote

Agile philanthropy, one man’s ambition for a brighter future

Nov 3 2009   7:52PM GMT

Some tips for one-person software test teams

Posted by: Michael Kelly
Add new tag, Software testing, software testing teams, software, Indianopolis Workshops on Software Testing

Last week I hosted a panel on time management for a local software testing group, IWST (Indianapolis Workshops on Software Testing). One of the questions asked during the meeting went like this: “I just started a new job and I’m at a company where I’m the only tester. Any tips for making that work?”

The entire panel was quick to point out that you’re never alone, and that you always have a team to work with. Brian Ball, a software engineer with Software Engineering Professionals, said that it’s important for you to realize you’re part of a larger team — whether they feel like it or not. He said you need to let the rest of the team know that you’re concerns are really their concerns.

Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, pointed out the following:

“What you really need to do in those situations is identify who are the stakeholders around you who care about the results of your work and the results of what’s happening, and find a way to leverage their expertise, their ability, their commitment and their passion towards what you do. Now that’s a problem that is magnified when you have technical expertise in some area of what you do, and the people around you — the stakeholders — don’t.”

Slaughter also pointed out that one of the most important things you can do is to help people give you information in a way that enables you to do your work better.

“You need to realize that you might have this expertise or this area of technical facility [and they do not]. You need to go back to the stakeholders and identify ways to communicate better. Maybe they need a form to fill out. Maybe they need a tracking system, your ticket tracking for the request. Or maybe you need to find a way to give them information in a more organized fashion, so they can find it more easily so they are not constantly calling you.”

Chris Wingate, principal software engineer for Liberty Mutual, summed up his thoughts on the question the following way:

“To me is seems to come down to two things…and those are trust and education. So you’re the only tester in your organization at the moment, and so it’s very important to build the trust in your competence with the rest of the team — with the developers and the managers. That way when you say, ‘Yes I can do that.’ or ‘No I can’t do that for these technical reasons.’ you don’t have to spend a lot of time explaining all of that and rehashing all of those things that you continually do.

“The other thing is educating the rest of the team about what your capabilities are, what timelines are, and they go together… you have to educate your customer in terminology. Educating your customer is going to help improve the communication and help make you more efficient.”

You can find the complete audio for the panel members’ advise for one-person test teams on the IWST website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.

Oct 13 2009   8:44PM GMT

Project management consultant/author extends savings to SearchSoftwareQuality readers

Posted by: Dan Mondello
Add new tag, Barbee Davis

Barbee Davis is an experienced Project management consultant and author who routinely writes for a semi-monthly international publication, Community Post on project manager concerns as well as ways to successfully negotiate projects.

She is offering our readers this 30% savings coupon on her latest project management book published through O’Reilly: 97 Things Every Project Manager Should Know.

To receive this 30% title savings, apply this promotional code ABF09 through the O’Reilly website

For more information on Davis click here.

---

Related Content
Software expert on Agile’s rise, avoiding project management mistakes
Software project management consultant opines on importance of agile development, common errors in PM, PM career preparation and more.

Sep 29 2009   9:49PM GMT

At the movies: Exploratory, performance, security testing a kiosk

Posted by: Michael Kelly
Add new tag, Software testing, exploratory testing, software performance testing

Whenever I walk into a movie theater, I remember when I tested a self-service ticket machine. No one was paying me to test the kiosk. I was just killing time, waiting at a theater for someone to join me to watch a movie. The machine looked and functioned similar to an ATM. You select your movie, slide your credit card and print your tickets. What was great about the opportunity is that it allowed me to practice exploratory testing, usability testing, performance testing and security testing all at once.

I discovered that “playing” with the kiosk nicely illustrated what software testers do every day.

The system would allow you to select up to 10 tickets for each type of ticket you could purchase: adult, child and senior. While testing the limits of ticket selection and the proper calculation of the total amount, I noticed that if you max out the number of tickets for senior- and child-priced tickets, the system would beep at you each time you tried to select more then ten tickets. However, when you attempted to select more then ten tickets priced for adults, there was no beep. It made me wonder about the beep. Was it a usability feature?

After I was done doing my functional analysis of the system I had a chance to do some usability testing by watching people interact with the system. I noticed one case in particular that showed what I consider to be a serious defect. A lady using the system selected her movie, entered her credit card information and started waiting as the screen displayed the message: “Please wait while processing your transaction.” I assume that at this point the system was attempting to connect to whatever service it uses to process credit cards.

As luck would have it, at that moment credit card processing for the theater went down. I know this due to the very vocal population of customers at the ticket counter. Unfortunately for the lady making her self-service purchase, the ticket machine seemed to have hung as well. It just sat there saying “Please wait while processing your transaction.” No message saying: “Timed out while connecting to service. Please try again.” No message saying: “Trying your transaction again, please wait.” Nothing. It just sat there.

After about five minutes, the lady finally lost her patience and started pushing the cancel button. She pushed it once. She pushed it a second time - harder. She then pushed it five times in rapid succession. She then put all of her weight into the pushing of the button and kept the button down for several seconds. This processed continued for some time. I counted as she pushed the button over 40 times. Still the screen read: “Please wait while processing your transaction.” So much for the cancel option! She then left the machine and went to the ticket counter for help.

I found other issues while testing, but what stands out for me when reviewing this experience is not the issues I found, but that the process of finding issues “in the wild” is the same that we use “in the lab.” There was setup and configuration for my testing: show times; my credit card; connectivity to the bank; real users I could observe; and my watch to time transaction response times.

There was interaction with the system: myself and others pushing buttons: the system with the bank: the system with the system at the counter that the clerks used; customers swiping cards; and the system printing tickets and receipts.

There was observation of results: noticing beeps and information on the screen; looking at my receipt and tickets; looking at the time on my watch; listening to customer reactions and the conversations at the counter; and seeing the actions the user took under stress.

I was able to draw conclusions based on those observations: the need for better error messaging in the system; the probability of a bug around the beeping for adults; and the fact that the cancel key sticks could be due to multiple people applying fifty pounds of pressure for extended periods of time.

Does that testing process sound familiar?

I like this memory because it illustrates all the basic mechanics of software testing, regardless of the type. It doesn’t matter if it’s functional testing, usability testing, performance testing, security testing, or even automated testing:

• Testing almost always requires basic setup and system configuration.
• Testing requires that someone operate the test system or interact with it in some way.
• Testing requires that someone observe the results of those interactions.
• Testing requires that someone evaluate those results and draw conclusions.

What’s even better is that I learned something while waiting!

Aug 7 2009   8:05PM GMT

Reluctant Twitterer finds golden IT links, mentors

Posted by: Jan Stafford
Twitter, Software testing, Add new tag, Chris Wolf

Are you a software developer, tester, quality assurance manager or Agile/waterfall expert? Then I’d like to follow you…on Twitter, that is. In this post, I’ll introduce you to some of the smart software experts I follow on Twitter and share my experience as a reluctant Twitterer.

Exactly when I began writing about Twitter, I couldn’t get on the site due to a denial-of-service attack. That the attack was made indicates that Twitter has arrived. That I was mildly put out because I wanted to tweet shows that I’ve become a Twitter.

I started as a reluctant Twitterer. Email, phone and IM communications keep my day hectic enough, I thought. I asked myself and others: “What meaningful communication can take place in 140 characters?” That said, I do write about information technology, so I figured I’d give it a trial run. Maybe I’d be able to write a scathing review. Well, two things have won me over to Twitter:

• Twitter lets me keep up with interesting people I don’t talk to daily.
• The links those people share have taken me to top-notch IT content.

Since I’ve been a computer industry journalist since the 1980s, I’ve covered many beats, ranging from desktops to operating systems to e-software (remember that?) to virtualization to software development. Twitter gives me an easy way to catch up with and continue to learn from my mentors and friends in fields I no longer cover, as well as the new beat I follow now. Here are some examples of both types of people whom I’m following now:

• Bernard Golden is an open source software expert I met when I helmed SearchEnterpriseLinux.com and who also moved into virtualization about the same time I led the launch of SearchServerVirtualization.com.
• Burton Group senior analyst Chris Wolf was and still is my virtualization mentor. He’s actually just about everyone’s virtualization expert, and he knows his way around virtual labs, too.
• I was just introduced to Matt Heusser”, creator of the dev/test blog, Creative Chaos, Now I read his blog daily, and I hope to be working with him soon.
• I read this chapter of Stand Back and Deliver: Accelerating Business Agility, which led me to reading the whole book in one day. Then, I got the inside scoop on the book from and began following co-author Pollyanna Pixton.
• After doing keyword searches on Twitter, I began following software testers and Agile experts Anne-Marie Charrett and David Alfaro. In last week’s blog post, Testing blog digest, I wrote about Charrett’s blog tip on discovering software bugs. Almost every day, Alfaro tweet links send me to super-informative articles.

I enjoy reading about the lighter side of my band of Twitterers’ days, too. A few minutes ago. Chris Wolf’s update said: “Driving up 95 to NJ. My son sees an oil refinery in Baltimore and asks ‘Is that New Jersey?’”

Finally, I’m forced to admit I’ve grown to love the 140-character tweet limit. Not only does the limit make me boil things down to the real nitty-gritty, it saves me from having to read long-winded posts.

Care to join my Twitter community? I tweet about software testing/QA articles I read, my conversations with experts and more. You’ll find me on Twitter as jlstafford. Please invite me to follow you, too.

Jul 31 2009   9:27PM GMT

Software testing blog digest: Bug, team woes; memes; Ford Motors

Posted by: Jan Stafford
Add new tag, Software testing, software testing teams, software bugs, Debugging

If you don’t read software testing blogs, you’re missing some great advice and thoughtful ramblings on testing philosophies. I tap into those blogs daily, and here I’m sharing the wealth with this reader’s digest of the testing posts I enjoyed this week.

Why bugs are hard to kill

On Maverick Tester, Anne-Marie Charrett describes the mistakes she’s made when doing offsite exploratory testing under tight deadlines. Then, she reveals how she’s stopped making those mistakes in her list of offsite exploratory testing guidelines to bug reporting.

One tidbit of her advice: Write reports right away, even if you are super-busy. She writes that “it takes longer to write them up at the end, when you have to review heaps of cryptic phrases in Session Tester or in your notebook.”

I love the post’s title, “Do your bugs only glow when it’s dark?” It reminds me of the “putting out fires” metaphor. How many times have I gotten emails from co-workers, site experts and others saying they’re late with a response or a deliverable because they’ve been putting out fires? Hey, I’m guilty, too.

In my own work, I see that most of these fires were started when haste made waste. Why is it so hard to take things one step at a time? Oh yeah, there’s a deadline and not enough time to make it.

When familiarity breeds success
Moving on, two posts on Matthew Heusser’s Creative Chaos blog explore thought-provoking topics: team cohesiveness and memes. In his post on Jelled Teams, he ponders the good results of working on a team that’s been together for over a year. How much creativity and productivity is lost, he asks, when companies often shift people from team to team as casually as they do? Too few managers realize that teamwork flourishes when people know each other well enough to feel comfortable sharing their ideas. When a team works well together, it’s an added-value asset in and of itself.

So, project managers, think twice before breaking up good teams!

I see a connection between that post and Heusser’s musings today in The meme’s the thing. Wikipedia calls a meme “a postulated unit or element of cultural ideas, symbols or practices, and is transmitted from one mind to another through speech, gestures, rituals, or other imitable phenomena.” Good grief! I think Heusser’s short definition is better: “It’s an idea - a concept that spreads from person to person. “

Any married person knows that familiarity and mind-melds go hand-in-hand. It stands to reason that team members that’s been together a while will start understanding how each other thinks, and the ideas will start flowing. Community work along the same lines. That’s why, I think, the open source software community has made such great strides so quickly. Another is that open sourcers are so communicative and have created vehicles – sites, projects, message boards and so on – that foster collaboration.

Heusser believes that software testers should be thinking along the same lines and said:

“I believe that the communities I belong to…have ways to test software that are significantly better than the status quo, and we have ways to communicate them and techniques to teach them. Yet if our testing ideas are memes, we need to think about ways to package and present them to win.”

Carrying on with the teamwork theme, there’s a nice exchange on the topic of how to handle unhappy testing teams on Jerry Weinberg’s blog, The Secrets of Consulting. A software test manager at an insurance company wrote to Weinberg, and they –- and others – brainstorm on the subject in an informative message chain.

On the lighter side

Once you’re a software tester, you look at everything from that point of view. So, Software Quality Insights blogger and independent consultant Mike Kelly describes Ford Motor’s web application flaws whe he was trying to spec a new Ford truck. In his entertaining post, he concludes that it’s easier to build and buy a Toyota online. This is something Washington has missed when discussing bailouts and the state of U.S. auto companies, I think.

There were plenty of other good reads in testing posts this week, more than I can cover here. Please comment below if you read something good this week or have a favorite testing blog.

Jul 29 2009   4:29PM GMT

Tester’s view: IBM buys source code analysis company

Posted by: Michael Kelly
Add new tag, IBM, Ounce Labs, source code, source code analysis tools

In a press release yesterday, IBM announced it would be acquiring Ounce Labs Inc., whose software helps companies reduce the risks and costs associated with security and compliance concerns. IBM will integrate Ounce Labs products into its Rational software business.

For those who might not be familiar, the current lineup of Ounce products include:

• Ounce Core is their security source code analysis engine, used to assess code, enforce rules and policies, and it houses the Ounce security knowledgebase
• Ounce Security Analyst scans, triages and assigns results, and manages security policies allowing you to take action on priority vulnerabilities.
• Ounce Portfolio Manager delivers at-a-glance metrics and information to manage risk enterprise-wide.
• Ounce Automation Server augments Ounce Core by integrating and automating scanning, publishing, and reporting in build environments.
• Ounce Developer Plug-Ins helps pinpoint vulnerabilities and provides remediation advice for rapid fixes.

For those familiar with the latest offerings of IBM Rational, it comes as no surprise that the Ounce Labs products will be offered as part of the IBM Rational AppScan family of Web application security and compliance testing solutions. The current suite of IBM Rational tools (AppScan and Policy Tester) provide some of the basics around security vulnerability scanning, content scanning and compliance testing, but they aren’t as full featured as their competitors products.

When the current Quality Manager suite of tools from Rational came out a year (or so) ago, I was quite happy to see AppScan integrated more closely with the testing products. And over the last several years, Rational has done a better job of integrating their testing and development platforms — moving the tools to a common platform/IDE, etc. Hopefully the addition of the Ounce products will continue that trend of bringing team members together in a common toolset.

For more information on the acquisition, SearchSecurity.com has the full story.

Jul 22 2009   4:19PM GMT

Using taxonomies to help with test planning

Posted by: Michael Kelly
Add new tag, Software testing, software test plans, FMEA, failure modes and effects analysis

A year ago, I was working on a project where we were doing a failure modes and effects analysis (FMEA) related to failover and recovery. As I was thinking about how to best start my analysis, I recalled that in the past while doing performance testing work I looked at many of the same aspects of the system while planning. As a way to generate ideas, I did some research to identify sources that could help me with my planning. You can take a look at some of the resources I found, or use different taxonomies if you have any that you particularly favor.

Here’s an example of how you might use a resource like this. Let’s take the risks listed in chapter three of Performance Testing Guidance for Web Applications. In the following figure from the book, you’ll see a summary of the risks presented in that chapter.

Figure 1: Performance testing risks, from the book Performance Testing Guidance for Web Applications.

I prefer working with the list of questions the authors have outlined in the chapter, but the graphic does a nice job summarizing things. For each specific risk listed, you want to:

• Ask yourself if you’ve accounted for that risk with your current plan. If you haven’t, figure out if you should. If you think you should, figure out what type of testing would be most appropriate for you. One nice thing about this particular taxonomy is that they give you some guidance there.
• For each risk, move from the generic to the specific. The risk “Can the system be patched or updated without taking it down?” is a great question, and an initial answer might be “yes.” But when I look at the system I currently work with, there are several major systems all working together. I might ask if I can patch all of them. And patch them in what ways; via software, database, run-time dependencies, services, etc.?
• For each risk, ask yourself if there are any slight variations on that risk that might be important to you. Good examples of the practice are the two risks listed in the book: functionality could be compromised under heavy usage; and the application may not stay secure under heavy usage. And you can vary different parts of the same question. In those two risks, they varied the quality criteria — functionality and security — but kept the risks, such as heavy usage, static. You could add other quality criteria or other risks.

The general idea is that you’re using lists like these to help you generate test ideas. In a way, you’re also using them to test the planning work you’ve done so far to make sure you haven’t forgotten or overlooked anything.

Jul 15 2009   1:23AM GMT

New DevSuite 8.0 tools aim to aid multi-project collaboration

Posted by: Jan Stafford
Add new tag, application lifecycle management, ALM, development tools

TechExcel, a decade-old maker of development tools, released new features to its application lifecycle management software package, DevSuite 8.0. Included are MyWord dashboard engine and wiki tools promise improved team collaboration and status reports on concurrent software projects. Another bow to collaboration support comes in DevSuite 8.0’s new multilingual capabilities and user-definable UI names and values for multiple languages.

When a new product or features are announced, I always wonder what user problems or requests spurred the vendor to invest in developing them. So, when I heard about the DevSuite 8.0 additions, I posed those questions to Paul Unterberg, associate director of product management for Lafayette, Calif.-based TechExcel.

First I asked how users have been getting views and an overview of project status prior to the release of the MyWorld dsashboard engine. Unterberg responded:

“Before we introduced MyWork, the data for an overview was available to a user or a team based on a report. The user had to login, select a project, navigate to the report view, and then run their report. This took a lot of effort. Since the data was already in the system, we simplified the process and put it all in one place.”

My next question: How about the before-and-after picture for integrated wiki tools?

“There was no integrated Wiki before DevSuite 8,” Unterberg said. “This meant that people wishing to collaborate on a requirement or document had few options. They could leave notes to each other, but there was always the risk of someone overwriting another person’s changes. The Wiki simplifies the entire process, and eliminates the risk of user unintentionally erasing another user’s data.”

The overall goal of DevSuite’s integrated set of tools is to marry the strategic and tactical worlds of application development together by creating software that lets management and planning processes co-exist seamlessly with specific task-driven development processes. The team of software tools that enable this relationship provide workflow, process automation, searching, reporting and customization capabilities, among other things.

DevSuite also co-exists with various application development methodologies. For instance, teams using both waterfall and agile processes can live in TechExcel’s ALM framework.

“From our perspective, there should be no relationship between an ALM system and the development methodology a team uses,” Unterberg said. “We’ve heard from many customers the horror stories of their former systems that tried to change the way they worked based on what the system could do.”

It’s better to create processes in the ALM system that change based on how the team works. He described such a situation, saying:

“If a team is agile, for example, they might need less process control and a greater degree of flexibility with how they are able to prioritize work. They might also have the system limit the amount of time they can spend in a certain area; adding a time box to a development iteration, for example. This same functionality might be useless to a non-agile team. A good ALM system should be able to adjust to these needs and give the teams the most flexibility in modeling how work is done.”

Not adding another management layer with ALM is a stringent goal of TechExcel and is played out in DevSuite, Unterberg said. Adding different management when adopting ALM is only necessary if lack of management in a certain area was a driver for the ALM adoption in the first place. “Who is in charge depends greatly on the team and the process they follow,” he concluded. “ALM just enhances, automates and ties that process together.”

Jul 2 2009   6:25PM GMT

CAST 2009: Almog presents controversial new test case definition approach

Posted by: Michael Kelly
Add new tag, Association for Software Testing, Software testing, Dani Almog

Dani Almog will be outlining a new approach to test case definition at the Conference for the Association for Software Testing (CAST 2009) this month. In his talk “Test Case Definition: A New Structural Approach,” Almog will explore and classify the various definitions of test cases, discuss the implications of the current situation, and will suggest an alternative structural definition for test cases. CAST 2009 takes place July 13-16 in Colorado Springs, CO.

“Based on thorough research of academic articles, journals and books and by consulting some of my distinguished colleagues around the globe, I will present my findings aiming at an alternative formal structural definition of the term ‘test case. Although it may be a controversial approach, formalizing the term fits my engineering perceptio’n of the testing process. Thus, during my talk I will present a newly developed structural definition to a test case.

During the last six years, I was very fortunate to be able to fulfill a dream and implement ideas pertaining to how and when software testing should be developed; in short, finding ways to bridge the gap between the software development approach, the technology, the training (mostly object oriented thinking) and the way we testing engineers see the same applications; in an intuitive, procedural –the way we use it — manner.

I got full support from top management in the company I worked for (Amdocs) to recruit a very talented and innovative group of young people who assisted me in developing and implementing a full infrastructure for test automation. Later, (this) was rolled out to all the corporate divisions and units. Now that I have retired from Amdocs, I have decided to dedicate the rest of my professional career to exposing and promoting the new approach I have developed, including methodologies and tools.”

Dani Almog is currently a member of the academic staff at Ben Gurion University, Israel. He teaching and researching. Dani teaches software quality engineering and testing, and research the interaction between development processes and quality/testing - trying to introduce to the academic world some of the achievements and work models developed in industry.

“Coming from a large corporation’s (Amdocs) R&D division, we have encountered many issues regarding test case automation- a necessity and a key factor for supporting eight different large software products, often with 3 different versions distributed among one hundred different very large customers. This situation made us consider all options and alternatives for test automation infrastructure, tools and methodologies. We were given the opportunity to be involved in shaping the future of our new products’ development processes and procedures. All my academic activities since my retirement, including this talk, are derived from this experience and I am now actually documenting and presenting the best practices of what have we done. “

Almog says that in his talk he’s targeting two different communities. The first is the professional community, who he says is struggling to “improve its skills and outcomes regardless of inferior reputation and image – knowing they never really get the deserved glory.” The second is the academic community, who has “neglected a very exciting field of research and progress.” He suspects both communities might have some criticisms for his talk.

“I welcome the challenge of debate and criticism and believe it will improve my work. I guess the criticism will come from two main channels. From those questioning the relevance of my approach to all different streams and to the new ways software development expands to. And from people who perceive testing as softer and more flexible (exploratory, context-dependent, and others) rather than structured and engineered. I believe that my approach paves the way to more systematic and precise testing, as well as to development of advanced automation tools. I welcome all constructive and relevant criticism. It will help me present a better model.”

For more on the upcoming show, check out the CAST conference website. For a chance to explore the topic in more detail, you can contact Dani Almog on the Software Testing Club or following his discussions.