Skip to content

Feed aggregator

.NET Developers in Focus

NCover - Code Coverage for .NET Developers - Mon, 10/13/2014 - 14:35

This week we wanted to bring into focus two amazing .NET coders whose experience is as broad as it is deep. Keep up the great work Xavier and Mark!

Xavier Decoster

ncover_mvp_xavier_decosterXavier Decoster is a Microsoft Most Valuable Professional (MVP) Visual Studio ALM and co-founder of MyGet, a NuGet-as-a-Service platform on Windows Azure. He dislikes development friction and in order to make other developers aware of how frictionless development can and should be, he tries to share his experiences and insights by contributing back to the .NET community as a speaker, author, blogger, and through various open source projects. He has written a book, Pro NuGet, and has published articles on MSDN, on CodeProject and on various other web sites. He blogs at and you can follow him on Twitter (@xavierdecoster).

Mark Needham

ncover_mvp_mark_needhamMark Needham has been around code for years. He has written product code in Java, C#, Scala, Ruby and 7 lines in Clojure! While he has experience in a wide variety of languages, according to him “the most fun I had with a language was when I was learning F# in 2009/2012″. He is currently working for Neo Technology – the creators of Neo4j, the NoSQL graph database. Never one to rest on only knowing what he knows, he most recently started re-learning algorithms that have been lost since university and modeling complex domains using graphs. Follow him on twitter (@markhneedham ) or on his blog

The post .NET Developers in Focus appeared first on NCover.

Categories: Companies

Don’t write a single test! Until you know how to do it

PractiTest - Mon, 10/13/2014 - 14:10

We’ve all heard about the “Infinite Monkey Theorem” whereby a monkey hitting keys on a keyboard (typewriter) at random will eventually come up even with the complete works of Shakespeare.

Monkey Typing

Monkey Testing? :-)

But the problem is that it would take it an infinite number of years, and maybe more importantly the work would be buried under so much junk and gibberish that it would be impossible to find it.

What’s the status of your test cases?

Now take a look at your test repository.  What do you see?
Is there anything in common with the work of the monkey above?

I am not implying your team is made up of chimps typing at random – even though if it is, please take a picture of them and send it back to me, I promise to publish it!!!

But something I see a lot in the context of my work with PractiTest’s customers is that people tend to concentrate on the quantity of their test cases, and fail to put enough efforts on the quality of their resources.

The result is repository with a lot more test cases than it should actually have, many of them covering the same feature too many times, others describing functionality that was modified a number of releases back, and some that have not been run in a number of years because they are not really important anymore.

I don’t think this comes from incompetence, but I do believe that a big factor for this is the fact that it is easier to create a new test than to find an existing case (or cases) and modifying it accordingly.

Another cause is the fact that it is a lot easier to measure the number of tests than the measure the quality of your testing coverage (and the quality of the individual tests cases themselves).

Process and rules of thumb for writing test cases

A good way of stopping problems of this type is to have some process and rules of thumb in place to help testers write better cases.

ID-10051915Some examples for rules of thumb you can define with the team can be the following:

  • Setting upper and lower limits for the number of steps per test case.
  • Setting maximum number of test cases per feature or functional area.
  • Working with modular test cases that you can use as building blocks for your complex test scenarios.
  • Have separate test cases for positive and negative scenarios.
  • Use attachments and spreadsheets to decouple testing data from testing processes.

Regarding process, this is a little harder but it is also a lot more effective in the long run.  Some examples might be:

  • Before starting to write test cases have a small team create the test list and their scope, only then fill out the steps.
  • Break your test repository into areas, assign each area to a tester in your team and make him/her responsible for all aspects of its maintenance.
  • Have peer test creating or review sessions.
  • Visit and validate “old” test cases & tests that have not run in the last 6 months.
  • Review tests that do not find any issues in the last year.
Create visibility and accountability into your test management system

A big factor that will help or hamper the way you maintain your test cases is how you manage and organize them.  You can obviously do this in your file system repository or using something like Dropbox to share these resources with your team.

But  after your tests grow in size or your team expands above a certain level it makes more sense to find a professional test management system that will help you to organize your test cases and generate good visibility and control over them.

I don’t want to make this a marketing post, but I do recommend you take a look at PractiTest and the way we provide excellent visibility into your test cases with the use of our exclusive Hierarchical Filtering system.

Other than creating visibility, make sure there is accountability for each area of your testing repository.  As I wrote above, it is important to assign testing areas and their cases to specific players in your team.

Give them tasks (and the time) to update and maintain their tests, both during the preparation stages but also during the regular testing process.  You should not expect people to maintain their test cases during the frenzy and craziness of your regular testing cycle.

How do you do it?

ID-100288588Does your team have other process or rules of thumb in place to maintain your test cases?

Share them with us to understand what other ways are there to keep our test cases sane and effective.

Categories: Companies

Join Us in London at TestExpo 2014

The Seapine View - Mon, 10/13/2014 - 11:00

testexpo2014Seapine Software is a gold sponsor of TestExpo again this  year. Join us in London on October 21 to explore the theme, “Defining the Digital Testing Strategy.”

TestExpo 2014 will explore the ways in which we might rethink our testing practices and incorporate new digital technologies into our testing plans to support the delivery of high quality digital applications.

This one-day conference will be structured around a series of themes, with keynote presentations and roundtable sessions where all participants can join in and discuss their own experiences, consider how the testing industry is progressing, and find new ways to approach digital testing challenges.

Seapine Solutions Specialist Gordon Alexander will deliver an afternoon presentation on integrating risk management and mitigation with testing. Risk management and mitigation is a central tenet of effective project management, and must be incorporated into your testing plan to be effective. Learn why automating traceability, and ensuring that design, risks, and testing are linked and managed in a central repository, are necessary to truly integrate risk management and mitigation activities with testing.

Register to attend TestExpo 2014 now.

Share on Technorati . . Digg . Reddit . Slashdot . Facebook . StumbleUpon

Categories: Companies

Pairing On a Mission

Agile Testing with Lisa Crispin - Mon, 10/13/2014 - 05:23
"We're on a mission..."

“We’re on a mission…”

Most of us have more we’d like to do than the time to do it, even if we’re in an experienced agile team working at a sustainable pace. A couple of us that work on our iOS team wanted to try automating some UI regression tests. The programmers write their code using TDD with good test coverage, but UI regression testing was all done manually and tended to be a bit hit-or-miss.  However, we were stretched thin on the testing side, and that idea didn’t get to the top of the priority list.

Luckily, a highly experienced tester, JoEllen Carter (@testingmojo), joined our team. Soon after that, when we were regression testing an iOS release, JoEllen found a showstopper regression failure. Automating regression tests through the UI to catch failures such as that more quickly became a more compelling idea.

Getting started

The developer who is also the iOS product owner championed the automation effort, and knew some testers in our company’s Toronto office who were successfully automating mobile UI tests. He set up a meeting so we could pick their brains. They recommended using Apple’s built-in test automation tools in Instruments, along with the tuneup.js library, and kindly sent us a book, examples of their own tests, and other helpful documentation.

The PO helped us install and build the iOS code, and spike some rudimentary automation with Instruments. We agreed on some simple scripts to try, and he put stories for those in the backlog. Since the main focus of our team is our web-based SaaS product, and we testers wear other hats including helping with customer support, it was hard to find time to devote to the iOS test automation. JoEllen suggested blocking out an hour every day to pair on it. This proved key to getting traction.

Pairing FTW

You know how it’s good to be the dumbest person in the room? This worked for me as I watched JoEllen fearlessly use the record function in Instruments as well as the logging feature to see how the iOS app pages were laid out and how to refer to the different elements. Every time we paired, we made good progress, starting with the simplest of scripts and incrementally adding to them. Demands on our time for more business-critical work sometimes meant we let the iOS automation effort slide, but we’ve experimented with trying a different time of day when distractions are fewer.

Obstacles to overcome

We had a few scripts written when the element names changed unexpectedly due to updates to support iOS 8. We were discouraged because we’d had no warning about it from the programmers. They work in a different office two timezones away, and though we have a daily standup and are on chat all day, we testers are usually focused on other products. We discussed this with the PO, and agreed it was time to get our test scripts into CI, so that if we weren’t warned about big changes, they’d at least be immediately obvious to everyone. We wrote more stories for the steps needed.

Some obstacles to making the UI automation scripts part of CI seemed tough. For example, we needed to figure out how to run the tests from the command line rather than from within Instruments. After one pairing session of Internet searching, reading doc, and trial-and-error, we nailed it! By “we” I mean JoEllen, with me contributing information from searches and a bit of shell command expertise. We also got help at one point with a Javascript question from a pair of programmers that work on our web-based app.

Overcoming my own weenieness

I have personally experienced a lot of fear and trepidation about the UI test automation effort. I don’t know Javascript, I’m a newbie at iOS (even as a user) and mobile app testing in general, and I always find test automation hard even though I also really enjoy doing it. But I finally forced myself to ‘drive’ and felt much better actually trying things. We have a plan for refactoring to make the scripts easier to run and maintain, and of course more tasks to do to get them into CI.

Lessons learned

I can’t advise you on the best techniques for iOS UI test automation, but I can share some general takeaways from this experience so far:

  • Has anyone else in the company already succeeded with a similar effort? Ask them for help – they’re probably happy to share their experiences.
  • Pairing brings much better chances for success than working alone, for so many reasons.
  • Put time on the calendar every day to work on an effort like this, even if it’s only one hour (that is also good advice if you want to write a book!) Experiment with different times of day. Right after lunch has been a good time for us, before getting pulled back into the routine, and before afternoon meetings.
  • Bring up obstacles during stand-ups, set up meetings to discuss them with people who can help.
  • Write stories for automation tasks to make them visible.

I still have some misgivings about our automation effort. I’d like for the programmers to be more involved. After all, test automation is coding, and they are the people who code all day every day, rather than one hour or so a day at best. However, we have lots of support from the PO who is also a programmer, and we’re moving towards making this automation a part of the existing test automation already in the product’s CI.

If your team has a tough testing problem to solve, try pairing to spike a solution. Reflect and adapt as you go! Oh, and hiring excellent experienced testers like JoEllen is also a good idea, but don’t be trying to poach her away from our team.



The post Pairing On a Mission appeared first on Agile Testing with Lisa Crispin.

Categories: Blogs

Building the Agile Culture you want

When some organizations think of going Agile, they tend to gravitate toward applying a set of Agile practices.  While this provides insight into the mechanical elements of agile, these types of implementations tend to overlook the cultural elements.  A move to Agile implies that you make the cultural transformation to embrace the Agile values and principles and put them into action. 
Adapting an organization's culture is effectively an effort in change management.  And changing a culture is hard. People underestimate the difficulties of a culture change within their organization because it involves the cooperation of everyone. This is why some organizations avoid this.  But the business benefits can be tremendous. I have seen Agile efforts get started with poorly stated objectives and motivations, a lack of employee ownership or engagement, and a lack of thinking through the effort. Also, Agile journeys significantly benefit from education in both change management and agile techniques to achieve a meaningful cultural change. I have seen companies assign a member of senior management as the change agent, yet they have neither education nor experience in change management. A better approach may be to hire an Agile Coach with change management and Agile experience.
Creating or adapting a culture is not done by accident. It must be considered a change initiative and thought through. As part of readiness of deploying Agile, start the process of adapting to an Agile mindset and the culture you are looking for. What are some activities that will help you move to an agile culture?  Some include:
  • Recognizing that moving to Agile is a cultural change (it’s a journey)
  • Sharing and embracing the Agile values and principles (seriously folks!)
  • Moving to an end-to-end view of delivering value (don’t stop at just the build portion)
  • Adapting your governance to focus on value (enough with the cost, schedule, and scope!)
  • Evaluating employee willingness (employees are your brainpower!)
  • Gaining continuous feedback from customers (adapt toward customer value)
  • Adapting the reward system to align with the new culture (toward team and value)
  • Assessing executive support (build engagement along the way)

What other activities would benefit you in getting to an Agile culture?  Ultimately you want to start living the values and principles that help you develop the culture you are looking for.  As you have approached Agile in the past, how much of it was focused on the mechanics and how much was focused on adapting to an Agile culture? 

PS - to read more about really making the shift toward an Agile culture, consider reading the Agile book entitled Being Agile.  
Categories: Blogs

Another Look at the Jenkins Promoted Builds Plugin

I discussed the Jenkins Promoted Build Plugin in a few recent blog post, when talking about the QA Process and Beta Test Distribution for mobile apps, where I gave a simple scenario of how it could be used to help control the testing lifecycle for application builds.  I happened to run through this with my friend Andrew Phillips from XebiaLabs, and he suggested some improvements to that scenario that I thought people might like to see, so I reworked the online example to illustrate those ideas.  Thanks also (as always) to Kohsuke Kawaguchi for his help and suggestions.  By the way, if you are interested in this and other enterprise-scale features of Jenkins, then please join Andrew and I for a XebiaLabs and CloudBees joint webinar on Wednesday November 7th: Setting up Continuous Delivery with Jenkins Enterprise and DeployIt.  

For this scenario, we have four Jenkins jobs, two which are "owned" by the developer and two which are "owned" by QA and Release Management.  The developer pushes code changes to a Git repository  and that triggers the initial build job (cuckoochess-android): this job has a build promotion configured (Release to QA), which depends on a successful build/test plus a downstream build (cuckoochess-android-matrix) that checks for compatibility with older versions of the Android SDK.  As far as the developer is concerned, he or she is really only interested in the outcome of the initial app build/test but until the downstream multi-configuration test build completes, the build isn't ready to go for QA review so the Promotion Status shows like this:

Once the downstream matrixed build(s) run successfully (and in reality we would expect to see a range of other tests including automated functional and touch tests), the build is automatically promoted and is ready for QA review and the Promotion Status now looks like this:

The remaining two build jobs are managed by the QA and Release Management teams: these are gated by a second build promotion (CuckooChess QA Approval).  A third Jenkins job (cuckoochess-android-QA) is triggered by the Release to QA build promotion, like so:

and the only qualification (in this example) is a manual approval by a named QA reviewer, which is configured like this:

The QA reviewer would usually want to look at unit test results, code coverage and quality metrics reported by tools like JUnit, Cobertura/Emma, Android Lint or one or more of the many code quality tools supported by the Jenkins Violations Plugin.  Many users probably prefer to have as much as possible of this quality and test coverage checking automated using Jenkins and it is common to set thresholds that must be achieved before a build can be accepted.  You can see an example of how to configure this sort of reporting for an Android build here, described in more detail in this blog.  Either way, the cuckoochess-android-QA job will show its Promotion Status like this, until a manual approval is given (by logging on to Jenkins, viewing the build and clicking Accept):

Once the QA reviewer is happy and the manual approval has been given, then the QA Approval build promotion will run, which in this case triggers the final build job (cuckoochess-android-release) which pushes the approved build to Zubhium for beta test distribution as described in the earlier blog.  The final build promotion status of the cuckoochess-android-QA job is now:

The final piece of the puzzle is how to ensure that the build that finally gets pushed to Zubhium for beta testing is the right one: we need to make sure that the application archive that goes out contains the exact bits that were built by the original cuckoochess-android job.  The way to configure that is by using the Jenkins Copy Artifacts Plugin to get the .apk application archive from the cuckoochess-android project, using a permalink to specify that we want the build associated with the most recent Release to QA build promotion.  That configuration looks like this:

Mark Prichard, Senior Director of Product

Mark Prichard is Java PaaS Evangelist for CloudBees. He came to CloudBees after 13 years at BEA Systems and Oracle, where he was Product Manager for the WebLogic Platform. A graduate of St John's College, Cambridge and the Cambridge University Computer Laboratory, Mark works for CloudBees in Los Altos, CA.  Follow Mark on Twitter and via his blog Clouds, Bees and Blogs.

Follow CloudBees:

Categories: Companies

That's all folks!

Tester Tested! - Sun, 10/12/2014 - 16:42
Categories: Blogs

BDD Using Cucumber JVM and Groovy (video) - Sat, 10/11/2014 - 21:47
BDD Using Cucumber JVM and Groovy
Categories: Communities

Networking is important–or what we are really not good at

Decaying Code - Maxime Rouiller - Sat, 10/11/2014 - 03:22

virtualbusinessMany of us a software developer work with computers to avoid contact with people. To be fair, we all had our fair share of clients that would not understand why we couldn’t draw red lines with green ink. I understand the reason why would rather stay away from people who don’t understand what we do.

However… (there’s always an however) as I recently started my own business recently, I’ve really started to understand the meaning of building your network and staying in contact with people. While being an MVP has always lead me to meet great people all around Montreal, the real value I saw was when it was a very good contact of mine that introduced me to one of my first client. He knew they needed someone with my skills and directly introduced while skipping all the queues.

You can’t really ask for more. My first client was a big company. You can’t get in there without either being a big company that won a bid, be someone that is renowned or have the right contacts.

You can’t be the big company, you might not ever be someone but you can definitely work on contacts and expanding the amount of people you know.

So what can you do to expand your contacts and grow your network?

Go to user groups

This is killing 2 birds with one stone. First, you learn something new. It might be boring if you already now everything but let me give you a nice trick.

Arrive early and chat with people. If you are new, ask them if they are new too, ask them about their favourite presentation (if any), where they work, whether they like it, etc. Boom. First contact is done. You can stop sweating.

If this person has been here more than once, s/he probably knows other people that you can be introduced.

Always have business cards

I’m a business owner now. I need to have cards. You might think of yourself a low importance developer but if you meet people and impress them with your skills… they will want to know where you hang out.

If your business doesn’t have 50$ to put on you, make your own!  VistaPrint makes those “Networking cards” where you an just input your name, email, position, social network, whatever on them and you can get 500 for less than 50$.

Everyone in the business should have business cards. Especially those that makes the company money.

Don’t expect anything

I know… giving out your card sounds like you want to sell something to people or that you want them to call you back.

When I give my card, it’s in the hope that when they come back later that night and see my card they will think “Oh yeah it’s that guy I had a great conversation with!”. I don’t want them to think I’m there to sell them something.

My go-to phrase when I give it to them is “If you have any question or need a second advice, call me or email me! I’m always available for people like you!”

And I am.

Follow-up after giving out your card

When you give your card and receive another in exchange (you should!), send them a personal email. Tell them about something you liked from the conversation you had and ask them if you could add them on LinkedIn (always good). Seem simple  to salesman but us developers often forget that an email the day after has a very good impact.

People will remember you for writing to them personally with specific details from the conversation.

Yes. That means no “copy/paste” email. Got to make it personal.

If the other person doesn’t have a business card, take the time to note their email and full name (bring a pad!).

Rinse and repeat

If you keep on doing this, you should start to build a very strong network of developers in your city. If you have a good profile, recruiters should also start to notice you. Especially if you added all those people on LinkedIn.

It’s all about incremental growth. You won’t be a superstar tomorrow (and neither am I) but by working at it, you might end-up finding your next job through weird contacts that you only met once but that were impressed by who you are.


So here’s the Too Long Didn’t read version. Go out. Get business cards. Give them to everyone you meet. You intention is to help them, not sell them anything. Repeat often.

But in the long run, it’s all about getting out there. If you want a more detailed read of what real networking is about, you should definitely read Work the Pond by Darcy Rezac. It’s a very good read.

Categories: Blogs

Announcing Support For iOS 8

Sauce Labs - Sat, 10/11/2014 - 00:43

ios8Today we added support for iOS 8 to our platform offering. The new simulators run on OSX 10.9 and will support both the iPhone 6 and iPhone 6 Plus screen sizes. Heralded as the biggest release to-date, iOS 8 delivers several new features including Apple’s HealthKit and iCloud integrations.

You can access the new simulators for web testing using the example code below.

# for Java and Appium
DesiredCapabilities caps = DesiredCapabilities.iphone();
caps.setCapability("browserName", "Safari")
caps.setCapability("platformVersion", "8.0");
caps.setCapability("appium-version", "");
caps.setCapability("platformName", "iOS");
caps.setCapability("deviceName", "iPhone Simulator"); # for Node and Appium caps = {browserName: 'Safari'}; caps['platformVersion'] = '8.0'; caps['appium-version'] = ''; caps['platformName'] = 'iOS'; caps['deviceName'] = 'iPhone Simulator';
# for Python and Appium
caps = {'browserName': "Safari"}
caps['platformVersion'] = "8.0"
caps['appium-version'] = "1.3.0-beta1"
caps['platformName'] = "iOS"
caps['deviceName'] = "iPhone Simulator"


Grab the code for other supported languages from the platforms page.

Categories: Companies

uTest to Provide Coverage Next Week from STARWEST in Anaheim

uTest - Fri, 10/10/2014 - 20:05

star_west_logo-150x150Headed to STARWEST in Anaheim, CA, next week? uTest will be there for the final three days of the nearly week-long esteemed testing event of the Fall. We’ll also be live tweeting and interviewing conference attendees all week.

In a clever spin on the hit TV show Breaking Bad, the 2014 theme is Breaking Software. The conference is billed as the premier event for software testers and quality assurance professionals—covering all your testing needs with 100+ learning and networking opportunities including: keynotes featuring recognized thought-leaders, in-depth half- and full-day tutorials, and conference sessions covering major testing issues and solutions.

Some of this year’s keynotes include The Power of an Individual Tester: The Experience, by Ben Simo of eBay. If you weren’t there for Ben Simo’s similar session at CAST 2014 in NYC in August, you’re in for a treat — this was a cant-miss keynote.

So if you’re wandering the halls of STARWEST next week in between all of these great keynotes and sessions, be sure to stop by and see us at the Applause booth (#5) on Wednesday and Thursday, as representatives from both uTest and Applause will be in attendance! You may even get some nice uTest and/or Applause goodies, too.

For those unable to make it in person, have no fear, as we will be video interviewing attendees on the spot here on the uTest Blog, and you’ll be able to follow along @uTest on Twitter for all of the coverage live from Cali.

Categories: Companies

Code Coverage – The Peace Maker?

NCover - Code Coverage for .NET Developers - Fri, 10/10/2014 - 17:32

In business we find ourselves interacting with people from different departments and with varying goals and input on a particular project. Sometimes all of these people and objectives align perfectly and everything works smoothly with your project on time and under budget. However, other times, we find ourselves looking at items with different concerns and development can get off track – from bugs or timelines.

code_coverage_peace_maker_blogYes – alignment issues are an issue no matter the organization. What does this have to do with code coverage?

Here at NCover, we see this misalignment most often with Quality Assurance and Development teams. The Quality Assurance division of any software development company is often structured around the tools used to analyze software rather than the process maintained to deploy healthy solutions. Development is structured around being able to build and write code.  These differences can lead to rifts between the coders building a structure of a project and the coders looking at the finished project for potentially buggy code.  Code coverage can bridge this gap and consistently produce high-quality deployed solutions.

How you ask? When did code coverage become the Geneva of quality code development?

Code coverage can help align and set expectations across both teams. For example, maintaining a coverage threshold for all builds helps keep Development and Quality Assurance aligned. This practice sets a standard that all builds sent to Quality Assurance must satisfy. This can stop careless development efforts and redirect responsibility from the individual reviewing the project to the individual coding the project. Time spent finger pointing or assigning blame can now be redirected towards building quality .NET applications.

Looking for a way to align your development and quality assurance teams? Code coverage may be the place to start.

The post Code Coverage – The Peace Maker? appeared first on NCover.

Categories: Companies

Detecting command injection flaws (like Shellshock)

Kloctalk - Klocwork - Fri, 10/10/2014 - 15:00

In this follow up to our last article about Shellshock, we’ll take a look at an example of a command injection flaw and see how Klocwork detects it. As a refresher, a command injection flaw is the result of improper or incorrect neutralization of elements that could modify an intended operating system command. The Shellshock flaw falls under this as Bash doesn’t neutralize string elements declared after a function statement in an environment variable declaration – in fact, it treats the elements as a real command.

Finding the flaw
Klocwork detects a comprehensive set of Common Weakness Enumeration (CWE) vulnerabilities as part of its on-the-fly code analysis and command injection falls under CWE-78. For this CWE ID, Klocwork covers three different scenarios with these checkers:

NNTS.TAINTED – finds code that uses string manipulation functions with character arrays that may not be null terminated, resulting in potential buffer overflows and security problems
SV.CODE_INJECTION.SHELL_EXEC – finds code that accepts command lines that are influenced by external input, resulting in the execution of potentially malicious commands
SV.TAINTED.INJECTION – finds code that doesn’t validate input from the user or outside environment, potentially resulting in the execution of arbitrary commands, unexpected values, or altered control flow

For example, consider the following code in a file called bashed.c:


    int main(int argc, char *argv[])
        // Tesstcase 1 of 2
        int ret1 = 0;

        if (argc > 1) {
            ret1 = system(argv[1]);

        // Testcase 2 of 2
        int ret2 = 0;

        char *anything = getenv ("anything");

        if (anything) {
            ret2 = system(anything);

        return ret1 + ret2;

Running kwcheck run on this code from the command line would yield the following results:

bashed.c:10 SV.TAINTED.INJECTION (3:Warning) Analyze
Unvalidated string '*argv' is received from an external function through a call to 'main' at line 3
this can be run as command line through call to 'system' at line 10. User input can be used
to cause arbitrary command execution on the host system. Check strings for length and content
when used for command execution.

bashed.c:20 SV.TAINTED.INJECTION (3:Warning) Analyze
Unvalidated string 'anything' is received from an external function through a call to 'getenv'
at line 17 this can be run as command line through call to 'system' at line 20. User input
can be used to cause arbitrary command execution on the host system. Check strings for
length and content when used for command execution.

bashed.c:10 SV.CODE_INJECTION.SHELL_EXEC (3:Warning) Analyze
function 'system' possibly accepts command line that may be influenced by user, causing
execution of arbitrary code. Arbitrary commands can be executed by an attacker. Check
the length and content of strings used for command execution. Also there is one similar
error on line 20.

Summary: 3 Local
3 Total Issue(s)

The first two reports, found by the SV.TAINTED.INJECTION checker, indicate that the variables argv and anything are unvalidated and have the potential to be used to execute arbitrary commands. The last report, found by the SV.CODE_INJECTION.SHELL_EXEC checker, warns that the call to system uses input that is potentially influenced by a malicious user. In all cases, Klocwork is advising you of the potential for unintended commands to be executed – a common form of attack by hackers.

Learn more:
• Read about the complete set of security standards that Klocwork supports, including OWASP, CWE, CERT, and DISA
• See the leading challenges driving code security and complexity issues in software today by watching this webinar

Categories: Companies

SaaS vs Hosted

Adam Goucher - Quality through Innovation - Fri, 10/10/2014 - 12:29

I’ve had this conversation a couple times in the last week, which usually means I should be writing about it. (Also, because its been ~ 15 months since there was one…)

There seems to be this myth that just because an application is not installed on the client’s premises that it must be SaaS. Ummm… no. Or at least not exactly. See, its a lot more subtle than that. Here is how I am currently distinguishing between the two in my head.

  • Delivery – This is easy. If you host it for your customers, you can be SaaS-y. If you have to ship something to your customers they need to install, then you cannot.
  • Tiering – At the heart of SaaS is the differentiating of customers based on service levels or other customers. And charging differently for them.
  • Onboarding – Customer should be able to sign up for your service without you knowing about it. Ideally you should regularly look at your customer list and be surprised by who you see on it.
  • Self-service – That thing your service does likely needs to have some sort of interaction from your customer be it periodic configuration or scheduling or whatever. They need to be able to do it. All. Without your involvement — unless you are charging a higher tier rate for that…
  • No touch billing – You know you have figured out the whole SaaS thing when you can hook a vacuum up to your customer’s wallet. If you are dealing with smaller businesses, then this is relatively easy by hooking up to a corporate credit card. But even at the ‘enterprise’ level you can do it by integrating with your financial and invoicing systems
  • Offloading – This is more ‘open source anarchist’ maybe than anything else, but your customers should also be able to leave your service without you knowing [hint: have a notification for when someone leaves and then follow up to see if you could have prevented it]. This includes getting their data out.
  • Crazy uptime – Remember the first bullet? Your service is hosted… so if its down because you are offline because you are deploying an update, your customers are dead in the water. 100% uptime. That’s your goal, not ‘5 9s’ or whatever.
  • Paranoia – Because you are hosted, and can be easily onboarded and offloaded you need to be constantly paranoid that someone will build a better ‘thing’. This paranoia is a good thing as it drives innovation.

This is still evolving, but having played in and paid attention to the SaaS-y space for a number of years now, I’m fairly comfortable with this list of attributes and is how I’m mentally evaluating all companies that call themselves SaaS.

Categories: Blogs

Just Released: The State of Medical Device Development 2014

The Seapine View - Fri, 10/10/2014 - 09:00

The results of the 2014 State of Medical Device Development Survey have been analyzed and compiled, and the report is now available. The 29-page report features research findings, data charts, and key takeaways to help you learn how other medical device companies manage product development, and to benchmark your processes against your peers.

This  year, we surveyed nearly 500 engineering, R&D, and regulatory professionals to help assess how medical device development teams manage core product development artifacts, compliance, and traceability. Their responses identified three overarching challenges to the industry: managing risk, working with documents, and overcoming barriers to improvement.

Download to learn:

  • How risk and traceability are being managed
  • What areas in the development lifecycle need more visibility
  • Which development activities are the most time-consuming
  • What prevents teams from improving their development processes

Read the 2014 State of Medical Device Development report and see how the demand for smarter, safer, more connected medical devices has introduced new complexities to the development process.


Share on Technorati . . Digg . Reddit . Slashdot . Facebook . StumbleUpon

Categories: Companies

Breaking Builds - No More Half Measures

OK, you’re a TV producer, and you’ve been charged with creating a spoof series based on “Breaking Bad.” But instead of making meth, your characters are going to make … software. 
What would the show look like? What kinds of jams would the characters find themselves in? Who’d play Walt?
Here at CloudBees we kicked the idea around and came up with our own concept that we trotted out last week at JavaOne and in a series of memes on Twitter, Facebook, G+ and LinkedIn. Our show is “Breaking Builds.” Our Walter White character is being played by everybody’s fanatically efficient, deviously stoic butler, Jenkins.
Now, follow along for a minute. The term “breaking bad,” according to, comes from the American Southwest – just like the show itself. The phrase equates roughly to the process of defying authority, skirting the edges of the law – just generally raising hell. In the TV show, Walt breaks bad in a big way. He drives his RV right along the edge of the law and pretty much makes a mess of everything around him.
In our scenario, “Breaking Builds” is a good metaphor for the anarchy that can manifest itself in the software development process. If something can go wrong in the software lab, chances are it will. Ask anybody in development or DevOps if they have ever broken a build, and he or she will probably have some pretty good stories to tell. Our character doesn’t cause the anarchy; it’s there already. His job is to make sure bad things don’t happen.
To keep builds from breaking in the real world, development teams can dial up Continuous Delivery by using Jenkins CI. Jenkins manages and controls development lifecycle processes of all kinds – everything from building to documenting to testing to packaging to deploying to analyzing software projects.
On our show, Jenkins is the star. He’s got Walter White’s bravado and the Jenkins butler’s work ethic. He is the one who knocks. He’s an expert in chemistry, ensuring that the "chemistry" in companies’ DevOps is pure. Walter White needs to cook; Jenkins needs to code. Walt and Skyler pile up cash; Jenkins keeps stacking up hundreds and hundreds of plug-ins for people to use to integrate Jenkins with their favorite technologies.
Let’s face it: Builds will break – if you don’t do something to head off problems. Continuous Delivery can make a difference. And there’s one character that knows how to make CD work.
This character is Jenkins. Say his name.

Categories: Companies

Career advice for anyone who cares to listen :)

Rico Mariani's Performance Tidbits - Fri, 10/10/2014 - 03:06

At the Grace Hopper Celebration of Women in Computing there are many attendees offering and looking for good advice.  Dear friends among them.  I read some, “inarticulate” responses earlier today and they prompted me to think of what advice I might offer.  As I considered this I found myself thinking the same thoughts I always think when counselling people on how to have a good career. And so I offer these tidbits, trite as they may appear, in good faith, to all genders, religions, orientations, ages, and other demographics equally. I do this partly because it seems timely but also partly because I promised Emma Watson I would do something in the spirit of #heforshe even if she didn’t exactly hear me make that promise.

1. Don’t compromise

It is, in my opinion, impossible to have a good career if you aren’t investing in a good life and so you must never sacrifice the things that most matter to you in the name of career progress.  That kind of sacrifice will ultimately backfire without fail.  It doesn’t matter if what matters to you is your husband, your wife, your children, your church, your fire department, your animal friends, your theater, your poetry, your dancing, or anything else.  It is these things that we do when we leave the office that nourish us and put us in the frame of mind to feel valued, to do our best work, to not be spiteful, but instead be as successful as we can be.  If you come to work feeling like what you really should be doing is something else, or that you failed to do that something else this past weekend, you cannot give matters at hand the attention they require and you will then fail at all the things.

It is my belief and experience that you will have the best career you can possibly have by taking care of all your needs.  It only superficially feels like you’re compromising your career to do "that other thing", in the end, you aren’t.

2. Bring all your experience to the job every day

Do not compartmentalize who you are.  You are a whole person. All those other things I mentioned up there, whatever they may be, they enrich you and make you better.  They are skills and knowledge that you can and should tap every day.  If you try to turn some of them off, or fail to consider the utility of some of the others, you are less than all you can be, and it will show in your work.  I’m unable to think of any endeavors a person could be passionate about that bring no material value to a professional context.

3. Find mentorship and sponsorship

Professional waters are difficult to navigate.  You put yourself at a huge disadvantage if you do not have colleagues that can help you avoid common mistakes and give you important perspective.  Mentors are out there for the asking, and while you may not succeed immediately I can promise that, as the saying goes, “When the student is ready, the master WILL appear.”  Sponsorship is as important but in a different way, and it can’t always be the same person.  I think of sponsorship as having a person or persons “out there” that have a good sense of who you are, what your desires are, where you are in your career stage, and so forth.  These people need to be in play so that when opportunities arise, they will be able to speak for you.  It is truly unfortunate if “Jane” doesn’t get that choice assignment and promo opportunity simply because nobody knew that she always wanted to work on “ratafrat development” and had experience from her hobby.

4. Keep investing in yourself

Ongoing professional and personal development is essential to be promoted in a corporate environment, but I think it’s also essential for your happiness.  If you end the year a [slightly?] better engineer, parent, husband, wife, poet, singer, dancer, or whatever matters to you… you’ve had a good year.  That’s worth celebrating.  Making yourself a better person will pay in the end.  I’ve personally been astonished how many times my little side things turned out to provide just the thing I needed down the line.

5. Self-advocacy is great, but do it in the way that fits best in your environment

As far as promotions go, the best way to get promoted is to be doing the work already.  The best way to get raises is to be extraordinarily competent.  But those things alone might not be enough.  Some corporations give raises through a fairly formalized process where asking for a raise really isn’t even an option.  But in those cases the questions to be asking are more like, “what could I be doing to earn my next promotion, I want to be a strong candidate” – from a career management position that’s still a great take-charge way to proceed.  And it shouldn’t be off-putting.  On the other hand, there are plenty of situations where getting raises is a personal experience that practically requires a specific request.  These are great things to discuss with a mentor.

Even if you’re not getting your promotions as often as you want, if you are constantly a candidate for promotion you can hardly be considered among the weaker team members.  You will command a good share of the budget for raises.

If you feel you are being treated unfairly, I can’t recommend silence, but sadly I can’t make a specific recommendation that’s good in every organization. 

6. Self-worth goes a long way to projecting, and inspiring confidence

In the end, getting assignments and promotions may come down to whether or not your management feels you can handle those situations.  If you are always cautious and appear to doubt your own self-worth, or need to be reminded of it constantly, you are unlikely to inspire the confidence needed to get the big jobs.  You are also much more likely to accept substandard pay because you think yourself unworthy of a fair wage. 

Trust your skills and yourself, do not accept the unacceptable, conduct yourself with integrity and professionalism, these things will inspire your organization to give you the rewards you deserve.  And if they don’t, it may be time to consider another organization.  A skilled worker knows their value.


I’m sorry if all those thoughts seem like so much trite advice, it seems like I said nothing noteworthy at all, and yet those are the things that people seem to most need to hear in my experience, so there they are.

Best wishes and thanks for reading.

Categories: Blogs

‘Tis the Season for uTest Community Contests

uTest - Thu, 10/09/2014 - 22:18

If you haven’t noticed, we’ve gone a little crazy over tester recognition at uTest lately. We closed out the summer by crowning the victors of our epic Bug Battle and Ideal Tool contests.  Then we made a nice new home for our Testers of the Quarter and our uTesters of the Year in our Hall of Famelight-bulbs

To keep the excitement going, we thought we’d bring some cash and prizes to help highlight two other areas of software testing: your testing workspace and your favorite testing tools. We have two contests running in the uTest Forums right now:

Your Testing Workspace

What does your sanctuary of testing bliss say about you? This month’s uTest Community contest asks you to take a step back and examine this question – and take a picture of this testing workspace in the process!

uTesters will be able to submit their best photos in one of two categories: Best Testing Workspace or Best Desktop Trinket. For the first category, maybe your workspace has a wickedly cool setup or there’s just something unique about it. For your best desktop trinket, perhaps there’s one item that was a gift from a dev that will just make everyone laugh. Whatever these images are, we wanna see ‘em! One tester will also be selected at random out of all entrants for a uTest t-shirt as well, so don’t be shy about participating!

For more information, read the forums thread (login required). 

Chrome/Firefox Testing Add-on Tutorial

Browser add-ons are handy tools to use when testing, but it’s not always clear as to the best ways to set them up for testing. We are running a quick contest with a $200 cash prize for the best workflow and easiest-to-follow tutorial for your favorite browser add-on. Check out our Tool Reviews library for Chrome tools and for Firefox tools, but you are not limited to just these specific examples.

For more information, read the forums thread (login required).

So what are you waiting for? Sign up for a uTest account (if you don’t already have one) and get those ideas flowing for your submissions.

Categories: Companies

Nexus Live, October 2014 – Gene Kim, Josh Corman, TheNEXUS

Sonatype Blog - Thu, 10/09/2014 - 20:41
During the October 2014 broadcast of Nexus Live we were able to catch up with Gene Kim and Josh Corman to find out what’s in store for the DevOps Enterprise Summit in the Bay Area at the end of the month. We also took a quick look at TheNEXUS, the new community site for Nexus, […]

To read more, visit our blog at
Categories: Companies

Don’t Say That: Five of the Most Disliked Software Testing Terms

uTest - Thu, 10/09/2014 - 20:15

When you say that, you just sound like a jerk.YOU_DONT_SAY

Or maybe at least don’t sound like you completely know what you’re talking about. There are many words and phrases used within the software testing realm that have caused much anguish amongst testers, either because the terms are so vastly overused or are grossly inaccurate in how they are used.

In the past on the uTest Blog, we’ve covered software testing buzzwords, but a tester in our community recently took it a step further in our Forums, coming up with terminology that has caused such unrest beyond the normal annoyances of buzzwords. Here are some of the highlights from the discussion, in the words of our testers:

  • Manual testing: It’s one of the most hated terms in the industry. A manual tester, manual project manager and a manual network admin walk into a bar…
  • Glitch: A bug is not a glitch. A glitch is something transient, undefinable and suddenly appears. I search for bugs — repeatable faults in the code that can be triggered following a certain set of actions.
  • Manual testing vs. Automated testing: As soon as this term is raised, it becomes a kind of a war. This is a never-ending debate.
  • Validate vs. Verify: I will sometimes say verify when I should say validate just to annoy testers. I think the value of these terms does not outweigh the pain and suffering I get trying to get people to use the right term, so I quit worrying about it.
  • Test vs. Check: Honestly, does anyone outside the test community care? Testers are constantly getting into discussions about how these terms should be used. That’s a waste of my time. Every engineering person I’ve ever talked to immediately knows what regression testing is. No real need to explain it.

What would you add to the list? We’d love to hear in the Comments.

Categories: Companies

Knowledge Sharing

SpiraTest is the most powerful and affordable test management solution on the market today