Skip to content

Feed aggregator

Meet Our Newest Web Client: Surround SCM Web

The Seapine View - Mon, 09/08/2014 - 12:00

Surround SCM 2014.1 introduces a brand new web client that provides read-only access to Surround SCM source files, repositories, and branches. This new web client can be quite handy for remote users who need to view or get Surround SCM files but do not have the Surround SCM Client installed on their computer or device.

scmWebSourceList


You can use the Surround SCM web client to:

  • Browse to source files, repositories, and branches.
  • View file contents, versions, and historical information.
  • Download (or get) files to save local copies.
  • Bookmark files and repositories you frequently use for easy access later.
More information

The following links can help you get up and running with the new web client.

Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon

Categories: Companies

Are you Ready for your Agile Journey?

The common pattern in approaching an Agile deployment is to begin by conducting Agile practices training typically on Scrum or another Agile method.  While this will allow the team to begin mechanically applying Agile practices, it doesn’t address the culture shift that must occur, a culture shift that helps to inform the mind and shape behaviors, a shift toward "being Agile".  I term this approach of focusing on the cultural aspects of Agile as “readiness”. 
Readiness is the beginning of the process of acclimatizing the mind toward Agile values and principles and what they really mean.  It includes making decisions on the elements for your implementation. Although it is important to lead with readiness, this framework may be used iteratively depending on whether you plan for a more holistic deployment or iterative deployment of certain elements. This first starts with the premise that Agile is a culture change.  The implication is that Agile is more than a change in procedure or learning a new skill.  A culture change is a transformation in belief and behavior.  It requires a change by more than one person, and instead by a number of people within your organization.  As you can guess, this takes time. 
Over the years, I’ve established what I term the Ready, Implement, Coach, and Hone (RICH) deployment framework specifically focuses on readiness activities that help you prepare not only to adopt the mechanical aspects of agile practices but more importantly, begin a meaningful transformation of behavior toward an Agile mindset. 
Readiness starts the moment someone asks the question, "Is Agile right for me?” The goal is to work through this question, understand the context, and figure out how Agile might be deployed. Readiness can start weeks and even months before you really get serious about moving down the agile path. However, it can also begin when you are ready to commit.
What are some of the “readiness” activities?  These activities can help you shape the implementation according to the context and need of an organization. Readiness provides us with an opportunity to:
  • Assess the current environment and current state of agility
  • Lay the educational groundwork of agile values and principles
  • Understand and adapt to self-organizing teams and away from command and control
  • Shift the focus to delivering customer value and away from an iron triangle mentality
  • Discuss the agile business benefits
  • Gauge the team and management willingness

Readying the mind shouldn’t be taken lightly. It is important to understand the ‘what’ and ‘why’ prior to discussing the how and when.  It is important that the teams understand and really embrace the Agile values and principles.  Does senior management believe in the principles?  Do the teams feel they can operate in an Agile manner that aligns with the values and principles?  In fact, I will dare say that if the team acts in the manner that expresses the Agile values and principles and forgoes the mechanical application of agile practices, then there is a greater chance that Agile will survive and thrive within a company.  
Since there is already an overwhelming amount of material that focuses on “how to implement Agile” from a "doing" perspective, may I suggest that a different approach.  Provide the time to prepare the mind toward the Agile mindset and then incorporate this mindset into the culture, education, and decision-making process for your proposed implementation. With that goal in mind, let the readiness games begin!  How ready are you?

To read more about the importance of readiness and additional readiness activities in detail, consider reading the book Being Agile
Categories: Blogs

Header Poll for our new site

The Typemock Insider Blog - Sun, 09/07/2014 - 09:44
Help us find the best header for our new site, that reflects our incredible products. Feel free to propose your own idea. (image thanks to dollen) What’s a better header for our new site? Stop Chasing Bugs You are more Agile then you think View results Powered by kwiksurveys.com Stop Chasing Bugs 0% You are […]
Categories: Open Source

Top Tweets from SeConf 2014

uTest - Fri, 09/05/2014 - 20:41

The 4th Annual Selenium Conference kicked off yesterday in Bangalore, India. The goal of this conference is to bring together Selenium developers and enthusiasts from around the world. We didn’t have room in our travel budget this year to send our team, so instead we’re bringing you the top 5 tweets from the first day:

As of this morning, we have a total of 443 participants registered from 17 countries from 201 Companies with 232 Unique Roles @seleniumconf

— Selenium Conference (@seleniumconf) September 5, 2014

"If you're writing automated tests, you're doing development" @jimevansmusic It's true! #seconf

— Simon Stewart (@shs96c) September 5, 2014

#seconf automated tests are, and ought to be, software. @jimevansmusic pic.twitter.com/EDucxesMdJ

— Артём (@art_koshelev) September 5, 2014

Atypical use of #selenium for code injection penetration testing – session at #seconf

— Ashish (@ash1shm) September 5, 2014

At #Seconf Q&A straight from the brains behind #Selenium @shs96c @jimevansmusic pic.twitter.com/eXMjCPIudz

— Sudhir Patil (@sudhir_sgp) September 5, 2014

To see what other events are upcoming in the software testing world, make sure to check out our revamped Events Calendar. And if you’re curious about learning Selenium in general, be sure to check out our Selenium Basics course track at uTest University.

Categories: Companies

The ISO29119 debate

On Linkedin David Morgan started an interesting discussion titled: “ISO/IEC/IEEE 29119 – why the fear and opprobrium“. In this discussion Cor van Rijn asked me this question:

@Huib,
your comment gives the impression that you do not believe in standards,
Please enlighten me and let me know what are the DISadvantages to standards.
Personally I am a strong believer in standards, given that they are applied in a matter that is suitable to the environment and the problem (so with regards to complexity, size and risk) and that they should be used as a guideline and that issues that are not relevant should be omitted, due to your consideration and specific situation.
In that respect I would like to refer to the IEEE standards for software test documentation where this idea is phrased explicitly in the text of the standard.

Much has been said about ISO 29119 the last weeks. For some background, please have a look at the many things said online in my collection of resources on the controversy.

So what is wrong with this ISO 29119 standard?

  • The standard is not available publicly. How can I comply to or even discuss a standard that is not publicly available?
  • ISO is an commercial organisation. The standard is a form of “rent-seeking“. One form of rent-seeking is using regulations or standards in order to create or manipulate a market for consulting, training, and certification.
  • The standard embodies a document heavy test process which is unnecessary and therefor in many situations waste. Didn’t history show us that documentation and processes are important but that there are more important things we should consider?
  • The standard doesn’t speak about the most important thing in testing: skills! The word skill is used 8 times in the first three parts of the standard (270 pages!) and not once it has been made clear WHICH skills are needed. Only that you need to get the right skills to do the job.
  • There is much wrong with the content. For instance: the writers don’t understand exploratory testing AT ALL. I wish I could quote the standard, but it is copyrighted. [Edit: it turns out I can quote the standard, so I edited this blog post and added some quotes (in blue) from the ISO 29119 standard, part 1-3]. Here are some examples: (HS is my comments to the quotes)
    Example 1: The definition on page 7 in part 1: “exploratory testing experience-based testing in which the tester spontaneously designs and executes tests based on the tester’s existing relevant knowledge, prior exploration of the test item (including the results of previous tests), and heuristic “rules of thumb” regarding common software behaviours and types of failure. Note 1 to entry: Exploratory testing hunts for hidden properties (including hidden behaviours) that, while quite possibly benign by themselves, could interfere with other properties of the software under test, and so constitute a risk that the software will fail.
    HS: Spontaneously? Like magic? Or maybe using skills? There are many, many more heuristics I use while testing. And most important: I miss learning in this definition. Testing is all about learning. ET doesn’t only hunt for hidden properties, it is about learning about the product tested.
    2. The advantages and disadvantages of scripted and unscripted testing on page 33 in part 1:
    “Disadvantages Unscripted Testing
    Tests are not generally repeatable.”
    HS: Why are the test not repeatable? I take notes. If needed I can repeat ANY test I do. I think it is not an interesting question if tests are repeatable or not. Although I do not understand the constant pursuit for repeatable tests. To me that is old school thinking. More interesting is to teach testers about reasons to repeat tests.
    “The tester must be able to apply a wide variety of test design techniques as required, so more experienced testers are generally more capable of finding defects than less experienced testers.”
    HS: Duh! Isn’t that the case in ANY testing?
    “Unscripted tests provide little or no record of what test execution was completed. It can thus be difficult to measure the dynamic test execution process, unless tools are used to capture test execution.”
    HS: Bullocks! I take notes of what has been tested and I dare to say that my notes are more valuable than a pile of test cases saying passed or failed. It is not about test execution completed, it is about coverage achieved. In my experience exploratory testers are way better in reporting their REAL coverage and tell a good story about their testing. Even if tools are used to capture test execution, how would you measure the execution process? Count the minutes on the video?
    3. Test execution on page 37 in part 2:
    8.4.4.1 Execute Test Procedure(s) (TE1) This activity consists of the following tasks:
    a) One or more test procedures shall be executed in the prepared test environment.
    NOTE 1 The test procedures could have been scripted for automated execution, or could have been recorded in a test specification for manual test execution, or could be executed immediately they are designed as in the case of exploratory testing.
    b) The actual results for each test case in the test procedure shall be observed.
    c) The actual results shall be recorded.
    NOTE 2 This could be in a test tool or manually, as indicated in the test case specification.
    NOTE 3 Where exploratory testing is performed, actual results can be observed, and not recorded.
    HS: Why should I record every actual result? That’s a lot of work and administration. But wait, if I do exploratory testing, I don’t have to do that? *sigh*
  • I think there is no need for this standard. I have gone through the arguments used in favour of this standard in the slides of a talk by Stuart Reid (convener of ISO JTC1/SC7 WG26 (Software Testing) developing the new ISO 29119 Software Testing standard) held at SIGIST in 2013 and Belgium Testing Days in 2014:

stuartreid1

“Confidence in products”? Sure, with a product standard maybe. But testing is not a product or a manufactory process! “Safety from liability”? So this standard is to cover my ass? Remember that a well designed process badly executed will still result in bad products. Guidelines and no “best practice”? I wish it would, but practice shows that these kind of standards become mandatory and best practice very soon…

 

 

stuartreid2

Common terminology is dangerous. Read Michael Bolton posts about it here and here. To be able to truly understand each other, we need to ask questions and discuss in depth. Shallow agreement about a definition will result in problems. Professional qualifications and certification schemes? We have those and they didn’t help, did they? Benchmarks of “good industry practice” are context dependant. The purpose of a standard is to describe stuff context-free. So how can a standard be used as a benchmark? Ah! Best practice after all?

 

stuartreid3Who is demanding this standard? And please tell me why they want it. There will always be conflicts in definitions and processes. We NEED different processes to do our job well in the many different contexts we work in. A baseline for the testing discipline? Really? Without mentioning any context? What the current industry practice is lacking are skills! We need more excellent testers. The only way to become excellent is to learn, practice and get feedback from mentors and peers. That is how it works. Buyers are unclear what good test practice is? How does that work with selecting a doctor or a professional soccer player? Would you look at their certifications and standards used or is there something else you would do?

I do believe in standards. I am very happy that there are standards: mostly standards for products, not processes. Testing is a performance and not a pile of documents and a process you can standardise. I think there is a very different process needed to test a space shuttle, a website and a computer chip producing machine.

I wish that standards would be guidelines, but reality shows standards become mandatory often. This post by Pradeep Soundararajan gives you some examples. That is why I think this standard should be stopped.

Finally, let’s have a look at what the ISO claims on the “http://www.softwaretestingstandard.org/” website:

ISO/IEC/IEEE 29119 Software Testing is an internationally agreed set of standards for software testing that can be used within any software development life cycle or organisation. By implementing these standards, you will be adopting the only internationally-recognised and agreed standards for software testing, which will provide your organisation with a high-quality approach to testing that can be communicated throughout the world. ”.

Really? I think it is simply not true. First of all, since the petition is signed by hundreds of people from all over the world and over 30 people blogged about it, I guess the standard is not really internationally agreed.  And second: how will it provide my (clients) organisation with a high-quality approach? Again: the quality of any approach lies in the skills and the mindset of the people doing the actual work.

I think this standard is wrong and I signed the petition and the manifesto. I urge you to do the same.

This post was edited after Esko Arajärvi told me I can quote text from the standard. ISO is governed by law of Switzerland and their Federal Act of October 9, 1992 on Copyright and Related Rights (status as of January 1, 2011) says in article 25: Quotations. 1 Published works may be quoted if the quotation serves as an explanation, a reference or an illustration, and the extent of the quotation is justified for such purpose. 2 The quotation must be designated as such and the source given. Where the source indicates the name of the author, the name must also be cited.
Categories: Blogs

SIGIST – It’s better, but is it enough?

The Social Tester - Fri, 09/05/2014 - 17:30
The BCS SIGIST (Special Interest Group In Software Testing) was the first conference event I ever attended. It was about 6 years ago and I remember being amazed that people actually got together to talk about testing. SIGIST was where I first saw Michael Bolton, James Whittaker, Dot Graham, James Lyndsay and Julian Harty. There […]
Categories: Blogs

Best practices needed to ensure open source security

Kloctalk - Klocwork - Fri, 09/05/2014 - 15:00

As open source software continues to gain prominence, organizations around the world are beginning to realize that they need a new approach to security. The more popular and important open source software becomes, the more it will be targeted, and the greater the likelihood that any vulnerabilities will be exploited by cybercriminals.

Writing for TechTarget, industry expert Michael Cobb recently emphasized the need for best practices when it comes to open source software security.

Policies and governance
Among the most important aspects in any open source security plan is the implementation of an effective usage policy. Cobb recommended that IT security and development team managers consider limiting access to certain open source libraries. Specifically, he argued in favor of only permitting those personnel who have receive the required training and signed relevant agreements to utilize these these resources.

Without such policies in place, there is a significant risk that developers may take shortcuts when using open source libraries and packages without having read all of the relevant documentation. If this happens, the potential for a security breach increases significantly.

Additionally, Cobb noted that Google, one of the leading open source adopters, requires developers to abide by a coding and comment policy which enables employees to keep track of each others' efforts. This, the writer explained, is critical for ensuring security when thousands of developers have access to a  single monolithic code tree. This practice helps to keep all employees accountable.

The use of a high-quality open source scanning and governance tool can prove crucial in this capacity. These resources can enforce access limits and other policy frameworks and also provide reliable insight as to precisely where and how open source code is being used within the organization at any given moment. This significantly boosts the organization's overall security, ensuring that no unauthorized usage takes place that could put the company at risk of a breach.

Healthy skepticism
Another key best practice, according to Cobb, is to always treat any and all open source data and code with a healthy degree of skepticism.

"Application developers should never assume that data has been correctly validated, especially if functions developed in-house receive data passed by a third-party component," Cobb wrote. "The data may have been validated against a different set of requirements or rules."

The danger posed by an excessive amount of trust is most readily visible in the case of the Heartbleed vulnerability. The most significant security threat ever to strike the open source community was due primarily to the fact that everyone using the OpenSSL encryption library assumed that the software had been checked for security bugs, and yet no one actually took this step. This level of trust, while understandable, put countless organizations at risk.

Too frequently, companies adopt this approach to open source, essentially treating it the same way that they would commercial software. But whereas commercial software is produced by an known entity, the same is not true of open source solutions. And while there are organizations dedicated to ensuring the reliability of open source security, these efforts are simply not enough to guarantee the usability of any given solution.

The only reliable method for avoiding similar security issues in the future is to make sure that any and all open source code is thoroughly investigated by in-house employees to ensure that it meets security standards. 

Finally, Cobb recommended that every firm leveraging open source software develop an emergency response plan. Such a backup strategy is essential in case hackers manage to take advantage of a newfound security vulnerability in an open source code before a new patch is released. 

Learn more:
Top tactics to reduce your open source security risk free webinar
Eight considerations for managing OSS risks

Categories: Companies

Understanding Application Performance on the Network – Part IX: Conclusion

One thing I learned – or more accurately, had reinforced – from the many comments on this blog series is that there are often subtle differences in the implementation of various TCP features and specifications; TCP slow-start and Congestion Avoidance are good examples, as is the retransmission of dropped packets (and even the Nagle algorithm). […]

The post Understanding Application Performance on the Network – Part IX: Conclusion appeared first on Compuware APM Blog.

Categories: Companies

What’s New in Surround SCM 2014.1

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

Surround SCM 2014.1 has arrived! Surround SCM 2014.1 is loaded with a variety of new features, but my favorite is the web client. For the first time ever, you can review and fetch files from Surround SCM using your web browser. Be sure to read the full release notes for all the details.

Access Code and Other Digital Assets from Anywhere

Surround SCM 2014.1 comes standard with a web client that provides quick and easy access to source code and other digital assets stored in Surround SCM, from any browser with nothing to install. With the web client, you can:

  • Navigate branches and repositories
  • View file contents and history
  • Fetch files locally
Protect Your Valuable Digital Property

Surround SCM 2014.1 includes even more built-in security to protect your company’s intellectual property. Existing encryption of client/server communication has been improved and support has been added for RSA public-private key exchange to further protect communication between clients and the Surround SCM server. In addition, the Surround SCM server and connecting client will always encrypt credentials during the log in process regardless of whether encryption is enabled in the server options.

Work and Integrate with a Full 64-bit Application

Surround SCM clients (including CLI and API) are now 64-bit applications, enabling users to work and integrate with a true 64-bit client application.

Client Actions Are Up to 75% Faster

It’s now even faster to adding files and create branches.

File Sharing is Even More Reliable

A number of small improvements were made to file sharing, making share behavior more consistent and intuitive across repositories and branches.

Start Using Surround SCM 2014.1 Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon

Categories: Companies

Telerik Test Studio R3 2014: It’s All About User Experience

Telerik TestStudio - Thu, 09/04/2014 - 19:59

 

The Telerik Test Studio team just got its third major for this year product update out the door. Test Studio R3 2014 is packed with excellent UI enhancements that help optimize your Test Studio real estate and minimize the steps needed to take to get your job done.
Categories: Companies

Telerik Test Studio R3 2014: It’s All About User Experience

Telerik TestStudio - Thu, 09/04/2014 - 19:59

 

The Telerik Test Studio team just got its third major for this year product update out the door. Test Studio R3 2014 is packed with excellent UI enhancements that help optimize your Test Studio real estate and minimize the steps needed to take to get your job done.
Categories: Companies

ISO 29119 Draws the Ire of Testers in uTest Community

uTest - Thu, 09/04/2014 - 18:48

Earlier in the week, you may remember that 30-year IT vet James Christie posted his thoughts on why the ISO-Logonew testing standard released by ISO (International Organization for Standardization) is bad for the testing profession.

The post kind of blew up on Twitter, with testers from within uTest and the greater testing community immersed in a flurry of tweets and retweets to their followers. Michael Bolton even called it a “must-read.”

So why are so many people up in arms about this standard and tagging their Twitter posts with the harsh #Stop2919 hashtag? Well, you can be the judge and read the initial post from James to decide, but some of our testers took to the uTest Forums after the blog post went live to explain what ticked them off about it:

“Too bad we can’t impeach ISO 9000 [another standard from ISO]. I will not work for a company that requires ISO. I’m a process guy that loves to have a defined process that works for everything I’m doing. I don’t like process for the sake of process and that is what ISO feels like when implemented.”

“I left my last company because the industry they worked in was so heavily regulated — all we did was process, process, process. We never did any real work.”

“To say that you MUST test a certain way, no matter whether it is a tiny phone app or a massive mainframe control suite, is, well, really nothing short of insane.”

Testers in the outside world, we want to know: Is ISO 29119 a danger to the testing profession as a whole? What would be your reaction to someone that wants you to sign the petition to #STOP29119? Are standards (and certifications from organizations such as ISTQB) bad for testing in general, anyways?

If you’ve got strong feelings against (or for) 29119, we want to hear from you in the comments below.

Categories: Companies

Building Pipelines at Scale with Puppet and Jenkins Plugins

This is part of a series of blog posts in which various CloudBees technical experts have summarized presentations from the Jenkins User Conferences (JUC). This post is written by Harpreet Singh, VP Product Management, CloudBees about a presentation given by Julien Pivotto of Inuits at JUC Berlin.

Inuits is an open source consultancy firm that has been an early practitioner of DevOps. They set up Drupal-based asset management systems that store assets, transcode videos for a number of clients. These systems are setup such that each client has a few environments (Dev/UAT/Production) and each environment further splits into a one backend per environment and a number of front ends per backend. Thus, they end up managing a lot of pipelines for each Drupal sites that they setup. Consequently, they need a standard way of setting up these pipelines. 
In short, Inuits is a great use case for DevOps teams that are responsible for bringing in new teams and enabling them to deliver continuously and deliver software fast. 
There are simple approaches to building pipelines through the UI (clone-a-job) and through xml (clone config.xml) but these approaches don't scale well. Julien outlined two distinct approaches to setting up pipelines:
  • Pipelines through Puppet
  • Julien Pivotto
  • Pipelines through Jenkins plugins
I will focus mostly on the puppet piece in this blog as that seems to be a novel approach that I haven't come across before. Although, Julien does lean towards using standard Jenkins plugins to deliver these pipelines.

Pipelines through Puppet
Julien started with a definition of a pipeline:     A pipeline is a chain of Jenkins job that are run to fetch, compile, package, run tests and deploy an  application
And then he goes about how to set these chain of inter-related jobs through Puppet. Usually, Puppet is used to provision OS, Apps and DB but not application data. In his approach, he puppetized provisioning Jenkins  and job configurations (application data). 
jobs.pp: Manifest for standalone jobEach type of job and pipeline has a corresponding puppet manifest that takes arguments like job name, next job, parameters etc. Since the promotions plugin adds some meta-data into an existing job config and adds a separate configuration folder in the jobs folder, promotions have their manifest as well. Configuration changes in the xml are done through Augeas.

With the above approach on-boarding a team is easy: puppet provisions a new Jenkins with its own set of pipelines and jobs. History of configuration changes can be tracked in the source repository. 
Pipeline.pp: Manifest for a pipeline
However delivering these pipelines gets hard because you end up with a lot of templates. Each change to configuration requires restart to Jenkins which impacts team productivity.

Delivering pipelines through puppet is the infrastructure as code approach and although the approach is novel the disadvantages outweigh the benefits and Julien leaned towards using Jenkins plugins to deliver these. 

Pipelines through Jenkins Plugins

Julien talked about two main plugins to realize pipelines. These plugins are well known in the community. The novel approach is connecting these two together to deliver dynamic pipelines.

Build_flow plugin: define pipelines through groovy DSL's and constructs to do parallels, conditionals, retries and rescues. 

Job generator plugin: create and updates a new job on the fly. 

Julien then combines them both where starting jobs (an orchestrator) are created using build flow and subsequent jobs are generated by job generator. Using conditionals and parallel constructs, he can end up delivering complex pipelines. 




The above approaches highlight two things:


  • Continuous delivery is becoming the de-facto way organizations want to deliver software and
  • Since Jenkins is the tool of choice for delivering software, it has to evolve and offer first class constructs to help companies like Inuits to deliver pipelines easily.

We at CloudBees, have heard the above loud and clear in the last year. Consequently, the workflow work delivered in OSS by Jesse Glick offers these first class constructs to Jenkins. As this work moves towards a 1.0 in OSS, we will get to point where the definition of a pipeline will change from


     A pipeline is a chain of Jenkins job that are run to fetch, compile, package, run tests and deploy an  applicationto      A workflow pipeline is a Jenkins job that describes the flow of software components through multiple stages (& teams) as they make way from commit to production.
-- Harpreet Singhwww.cloudbees.com
Harpreet is vice president of product management at CloudBees. 
Follow Harpreet on Twitter. 




Categories: Companies

Re-Blog: Add Some Sauce To Your IE Tests

Sauce Labs - Thu, 09/04/2014 - 18:05

Sauce Labs hearts ThoughtWorks! And apparently the feeling’s mutual. Check out this great blog post mentioning Sauce Labs by Tom Clement Oketch.

See an excerpt below:

Using Sauce Labs with a Continuous Integration (CI) Service

Running your tests only locally will not get you much mileage, especially if you are working with a sizeable team. Using a Continuous Integration service is therefore essential. Fortunately, Sauce Labs has first class support for a number of Continuous Integration services including JenkinsBambooTravis and TeamCity. The preceding links should contain sufficient information to integrate Sauce Labs with each of those CI services. In our case however, we had already set up Snap-CI as our CI service of choice. Snap-CI currently does not provide such integration with Sauce Labs. We therefore made the following adjustments to include Sauce Labs in our build pipeline:

  • As part of our functional test stage on Snap-CI, it was necessary to set up a tunnel to Sauce Labs using Sauce Connect, otherwise the browsers at Sauce Labs would not be able to run against our application instance in the Snap-CI Build Pipeline. We came across this gist which we altered to suit the requirements of our Snap Build. The gist takes care of downloading, starting and waiting for Sauce Connect to establish a tunnel before the functional tests are actually run
  • The terrain.py setup remained largely unchanged, except for the use of environment variables rather than the explicit declaration of the Sauce Username and API Access Key. Given that Snap-CI exports a number of additional environment variables during each build, it was also possible to annotate the test descriptions with these variables. Using annotations such as the pipeline counter and the git commit subsequently made it easier to identify the appropriate test in the Sauce Labs test dashboard.

Are you in a position where you need to run IE tests without getting your hands dirty? If so, maybe Sauce Labs can save your time as well. If on the other handyou are more interested in evaluating some of the other options out there, then this guide is a good place to start.

Don’t miss the entire post HERE for more code and instruction.

Have an idea for a blog post, webinar, or more? We want to hear from you! Submit topic ideas (or questions!) here.

Categories: Companies

uTest Platform Update of the Week: September 4th Edition

uTest - Thu, 09/04/2014 - 17:32

Accept-or-DeclineOur testers on paid projects here at uTest are busy people – many of them have day jobs as testers. Thus, they pull off an evening Clark Kent transition into Superman to get even more work done in their spare time.

Aware of this, our Platform Team continually pushes to make the uTest experience more intuitive and time-saving for our busy testers. As part of this push, we’ll be updating you each week on the latest and greatest additions to the uTest Platform.

Here are the notable features launching today as part of the uTest Platform release for Sept. 4:

  • Intuitive bug list sorting: TTLs will be able to see bugs in order of report date, and testers will be able to see the most recently submitted bugs first
  • NDA improvements on test cycles: Testers won’t have to fill out NDAs to decline test cycles, and NDAs will have pre-filled fields for easier completion
  • Easier identification of tester roles on test cycles: When in a uTest cycle’s chat, a user’s name will be paired with a textual annotation and color scheme that matches their role (e.g. TTL/PM/CM/TM)
  • Updates to how you report and view new issues: When you begin a new bug report form, the subject line input will autofocus so you can start typing right away, and, after submitting a new bug, the bug you just submitted is highlighted in the bug list the same way that the last bug you had open is (different background color)
  • Quick navigation to test cycles via Chat sidebar: You will now be able to right-click on a chat room (test cycle) name in the chat sidebar on right-hand side of the tester interface to navigate directly to that test cycle

While we’ve highlighted these updates effective today in the Tester Platform, be sure to check out the complete announcement in the Forums on what these changes mean for you, and to ask any questions you may have about platform features – current or on the horizon!

Categories: Companies

Nexus 3.0 Technology Preview (Milestone 1 Release)

Sonatype Blog - Thu, 09/04/2014 - 17:15
The Nexus development team at Sonatype is pleased to announce the release of the first milestone build (M1) of Nexus 3. This release is a technology preview covering the open source version, Nexus OSS, focused specifically on the new user interface. Nexus Pro will be covered in the upcoming M2...

To read more, visit our blog at blog.sonatype.com.
Categories: Companies

CukeUp! NYC, Brooklyn, USA, September 30 – October 1 2014

Software Testing Magazine - Thu, 09/04/2014 - 15:28
CukeUp! NYC is a two-day conference and tutorials that explores various aspects of the Behavior-Driven Development (BDD) technique of software testing. Members of the Cucumber BDD tool’s development team play an important role in this conference. In the agenda you can find topics like “Living with Acceptance Tests: Beyond Write-Once”, “5 Things Cucumber is Bad At (and Why That’s a Good Thing)”, “Death By Specification”, “Implementing BDD utilizing Cucumber…the case studies presented”, “The Case for BDD within Embedded Software Development”. Web site: https://cucumber.pro/cukeup Location for 2014 conference: DUMBO Loft, 155 Water St, Brooklyn, ...
Categories: Communities

Nothing like a fresh start

PractiTest - Thu, 09/04/2014 - 14:00

Back to SchoolThis week my 3 kids went back to classroom after their summer vacations.  They were all pretty excited about going back to school and kindergarden, meeting their friends and (I guess) going back to the routine they know and like.

Personally, the thing I remember most about starting the school year was the feeling of a fresh start.   My personal and subjective illusion that at least at that point of time everything was possible, and that none of the mistakes I had made the year before had any influence or weight on what I could do and achieve during the year that was only starting.

I remember listening to the “speech” we got from my 5th and 6th great teacher, Mrs. Barleta, who uses to start the year by addressing the class and saying: “Today all of you start your school year, and today is the only day when all of you have a perfect score of 100 on your grades.  It is up to you to keep that 100 by behaving good and completing all your assignments in class…”

Needless to say, 5 or 10 minutes later I would already start bothering in class, and the teacher would start taking off points out of my perfect 100…

 

Work is not different from school on this respect

When you are just starting your job or your project, when you have not made any decision or taken any actions, at that point everything is possible.

Then, as you begin working with your “less than perfect application, you start running tests and reporting bugs.

ID-100147922Part of these bugs will angry some of your developers and affect your relationship with them…

As it always happen, you will also start running late with your test plan.  Some times this will be because of your mistakes and other times because of issues that are not related to you.  Still, people in your team will point this to you and tell you that you should have planned better…

And soon enough, you wake up one morning and get a sense that somewhere along the way you lost that feeling that everything is possible, and now you feel stuck in a situation that you don’t really like, but on the other hand you don’t know how to get out of.

What can you do then???

 

A new beginning starts in our heads

If you think about it, there is no reason why you should not be able to get a clean start at any time in your project.  You only need to make a decision to get rid of all the things that are weighing you down.

How do you do that?

Start by listing everything that is making you feel stuck.

Once you have this list in front of you, look for the ways to solve each of these issues.

If you have issues with members of your team, set up personal meetings (better do them over lunch or coffee, and outside of the office) where you can open up and solve these problems.

If you need to correct your plans or update your assumptions, better to do it now by calling a meeting with everyone who needs to be involved in this process.

If you have any other issues that you need to solve, look for the quickest and simplest way to solve them.  Waiting 2 more weeks won’t make the situation better, and it may actually make things a lot worst.

 

Clean up your desk to clean up your mind

I have a little OCD, so for me it always helps to clean my desk.

I literally throw away all the loose papers and unnecessary stuff that has accumulated in my desk and office.  Once I have a clear desk it helps me to clean up my mind.

ID-10010051For some people instead of cleaning their desks they need to disconnect for a couple of days and do something cool, like walking a mountain trek or windsurfing in their preferred lake or beach.

This is also OK, and if you manage to get rid of your bad feelings, this time off will pay itself more than double with the good work you will be able to achieve.

 

How do you do it?

In short, you need to look for the way to get your fresh start.

In the long run it depends ONLY ON YOU.

How do you manage to get a clean start?
If you have your own way of “cleaning up your desk” share it with us by leaving a coment!

Categories: Companies

The Sixty Second Team

Hiccupps - James Thomas - Thu, 09/04/2014 - 12:53
One of my team recommended The One Minute Manager to me in a recent 1-1. It's a slim book, not exactly a one-minute read but not far off. It takes the form of a parable about a man in search of effective management who encounters the One Minute Manager and his staff and learns essentially this:
  • set clear goals and monitor progress towards them
  • provide clear and timely feedback
There are, of course, homilies along the way, including "We are not just our behaviour. We are the person managing our behaviour." and "The best minute I spend is the one I invest in people."  and the writing, not unlike the similarly-structured Quality is Free, can be cloyingly, clunkily patronising at times. Even so, the core lessons are sound enough and it does no harm for a manager to be reminded of them.

But the aspect of the book that I find most appealing is that the One Minute Manager's team members use the same techniques on, for and by themselves and are encouraged and expected to be independent and independent-minded. I like my teams to be this way which is why I'm delighted when they point me at a resource that can help me to do my job better.
Image: https://flic.kr/p/65eNhg
Categories: Blogs

The Sixty Second Team

Hiccupps - James Thomas - Thu, 09/04/2014 - 12:53
One of my team recommended The One Minute Manager to me in a recent 1-1. It's a slim book, not exactly a one-minute read but not far off. It takes the form of a parable about a man in search of effective management who encounters the One Minute Manager and his staff and learns essentially this:
  • set clear goals and monitor progress towards them
  • provide clear and timely feedback
There are, of course, homilies along the way, including "We are not just our behaviour. We are the person managing our behaviour." and "The best minute I spend is the one I invest in people."  and the writing, not unlike the similarly-structured Quality is Free, can be cloyingly, clunkily patronising at times. Even so, the core lessons are sound enough and it does no harm for a manager to be reminded of them.

But the aspect of the book that I find most appealing is that the One Minute Manager's team members use the same techniques on, for and by themselves and are encouraged and expected to be independent and independent-minded. I like my teams to be this way which is why I'm delighted when they point me at a resource that can help me to do my job better.
Image: https://flic.kr/p/65eNhg
Categories: Blogs

Knowledge Sharing

Telerik Test Studio is all-in-one testing solution that makes software testing easy. SpiraTest is the most powerful and affordable test management solution on the market today