Skip to content

Feed aggregator

The technical aspects of GWT (Google Web Toolkit) DFE (Data Format Extension) in LoadRunner

HP LoadRunner and Performance Center Blog - Tue, 04/26/2016 - 22:38


I would like to introduce you to some of the advanced LoadRunner Google Web Toolkit features. Let’s take a look at troubleshooting items that occur during Code Generation and/or Replay phases. We will identify existing problems and suggest ways to fix them, enabling to regenerate good scripts.

Categories: Companies

New Version of QAComplete Released

Software Testing Magazine - Tue, 04/26/2016 - 22:06
SmartBear Software has announced a new version of QAComplete, the most flexible software testing management tool for managing requirements, tests and defects in one place. With this release, SmartBear changed QAComplete’s user experience to support Agile testing practices. QAComplete 11.0 comes with improvements to user experience, including entirely new reporting and fully customizable dashboards. The new reporting engine provides users an ability to customize reports, while allowing QA managers to get a global level view to measure the effectiveness of their testing process as well as traceability across tests, defects and requirements. Further, customizable dashboards, along with custom filters, gives different members, including business users, developers and quality engineers, an ability to present data based on their specific use cases and within the context of the parts of their project. These dashboards can then be saved at the individual level, rather than at the global level, enabling users to keep track of and plan their specific test efforts. The drag and drop functionality of dashboards, combined with specific prepopulated dashboards, makes the process of visualizing data easier. The new release of QAComplete has additional UX and security improvements, including: * UI Facelift: The login page and splash screen of QAComplete have been completely revamped. This includes a brand new title bar on the top for easy navigation. * New Password Security Features: Security administrators can enforce stronger password rules such as a combination of alpha, numeric and non-alphanumeric characters.
Categories: Communities

Appium 1.5.2 Released on Sauce

Sauce Labs - Tue, 04/26/2016 - 16:23

We are pleased to announce the release of Appium 1.5.2 through npm and on Sauce Labs! This is a bug fix release that deals with many issues with 1.5.1, including a major bug where large Android applications would cause Appium to run out of memory and die.


  • deprecated --command-timeout. Use newCommandTimeout desired capability instead
  • ensure implicit wait can be set through timeout method
  • add better logging for EPIPE errors


  • make sure ipa files are handled correctly for installing on real devices
  • ensure that existing SafariLauncher on device is used instead of rebuilding and reinstalling
  • fix issues with getting webview contexts on real devices
  • add full timeout support through timeout method
  • make sure Xpath searches respect implicit wait timeout
  • make sure bare Instruments process arguments are accepted


  • fix failure when apk file is too large
  • re-implement setting geolocation so it does not use Telnet
  • add support for Chromium browser
  • fix issues with flick
  • fix bug where touch action release would throw an error
  • fix bug in later Android SDK version where noticing a newly started avd would fail
  • implement autoWebviewTimeout
Categories: Companies

Emotions in Software Testing

Software Testing Magazine - Tue, 04/26/2016 - 15:23
People are the most important success (or failure) factor in software development projects. This is also true in the software testing field. In his article “Testing Your Emotions”, Stephen Janaway explains why it is very important that software testers understand their emotions as they can be a great heuristic to guide testing. The article starts by presenting an example where communication is bad between a software developer and a tester. it then provides a definition of the term “emotion”, explaining the difference with “feelings” and “moods”. It then presents some emotional models that are available and that can help better understand emotions, more specifically the Plutchik’s Wheel of Emotion. Plutchik’s Wheel of Emotion by Machine Elf 1735 – Own work. Licensed under Public Domain via Wikimedia Commons – The second part of the article explains how to apply the Plutchik’s Wheel of Emotion model to team situations and to software testing. If used correctly, emotions are an effective tool to find defects in software testing activities. They are particularly valuable for the defects related to performance,  usability, reliability and of course functionality problems. Stephen Janaway conclusion is that “Emotions are also a powerful testing heuristic and if you feel something when testing then it is sensible to act on it and consider delving deeper into the problem. As a tester you act as a proxy for the user, and by understanding your emotions more effectively then it allows you to understand the user better.” Read the complete article on [...]
Categories: Communities

JavaScript Testing and Code Analysis at Facebook

Testing TV - Tue, 04/26/2016 - 09:25
Avik Chaudhuri, Software Engineer at Facebook, and Jeff Morrison, Software Engineer at Facebook discusses how Facebook handle software testing and code analysis of its JavaScript code. To encourage engineers to continue to make changes to the codebase, we spent some time identifying various important traits around automated testing, and used our insights to build a […]
Categories: Blogs

Jenkins 2.0 is here!

Over the past 10 years, Jenkins has really grown to a de-facto standard tool that millions of people use to handle automation in software development and beyond. It is quite remarkable for a project that originally started as a hobby project under a different name. I’m very proud. Around this time last year, we’ve celebrated 10 years, 1000 plugins, and 100K installations. That was a good time to retrospect, and we started thinking about the next 10 years of Jenkins and what’s necessary to meet that challenge. This project has long been on a weekly "train" release model, so it was useful to step back and think about...
Categories: Open Source

.NET Speakers to Hear

NCover - Code Coverage for .NET Developers - Mon, 04/25/2016 - 12:00

Listening to experts in our field is one of many ways we can learn and help improve the applications we build as members of the .NET community. We think you should make it a point to hear these two .NET speakers if you get the chance.

ncover_mvp_caleb_jenkins_twitterCaleb Jenkins

Caleb Jenkins is an International Speaker, Author and Senior Manager at Avaya – leading development teams in North America, Ireland and India. He has led teams of people for the last 15 years, and recently managed the UX product design team at Sabre GetThere, co-chaired Sabre’s Employee Innovation Council #BringIt, and was a Principal Agile Coach for Sabre Airline Solutions working with international development teams around the globe.

Longtime community leader, 6 time recipient of the Microsoft MVP award, and former Microsoft Developer Evangelist – working with some of the largest organizations in the region, Caleb is a Microsoft Certified Solution Developer, Certified Trainer and .NET architect. Caleb has helped to design and implement enterprise .NET Solutions for some of the largest companies in the world.

Caleb lives in the Dallas area with his wife and their four children. Follow him on Twitter @calebjenkins or at his blog.

ncover_mvp_niraj_bhatt_twitterNiraj Bhatt

Niraj Bhatt works as an Enterprise Architect for a Fortune 500 company with an innate passion for building and studying software systems. He is a top rated speaker at various technical forums including Tech Ed, MCT Summit, Great Indian Developer Summit, Tech Days, Virtual Tech Days, etc.

He enjoys working on IT innovations that impact enterprise’s bottom line, integration and architecture of systems, performance tuning, & review of enterprise applications with a specialized focused on enhancing team’s productivity.

When he’s away from his laptop, you will find Niraj enjoying automobiles, pottery, rafting, photography, cooking & financial statements though not necessarily in that order. See what he’s up to now on his blog and on Twitter @nirajrules.

The post .NET Speakers to Hear appeared first on NCover.

Categories: Companies

Let’s Test Stockholm, Sweden, May 23-25 2016

Software Testing Magazine - Mon, 04/25/2016 - 11:00
Let’s Test Stockholm is a three-day conference on software testing that take place in Sweden. The Let’s Test conference is organized by software testers for software testers with tutorials, sessions and workshops. Fiona Charles and Rob Sabourin will provide the keynotes. In the agenda of the Let’s Test Stockholm you can find topics like “You Have to Fail in Order to Practice Being Brave”, “A Many-Faceted Path in Testing Leadership: From Downtrodden to Dictator, from Doctor to Diplomat”, “Task Analysis and the Critical Incident Method – Discovering What Matters”, “Board Games For Testers”, “Tester Scavenger Hunt”, “Understanding and Testing RESTful Web Services”, “Testing, Wine, and Food: A Demonstration of Our Favorite Things Being Related to Each Other”, “Improv(e) Your Testing: Tips & Tricks from Jester to Tester”, “Exploring Best Practices”, “Review by Testing: Analyzing a Specification by Testing the Product”, “Testing Fundamentals for Expert Testers”, “Testers as respected business problem solvers – a true story”, “Can playing games actually make you a better tester? Exploring the science behind games”, “We Can’t Know Everything – Promoting healthy uncertainty on software projects” or “Realism in Testing” Web site: Location for Let’s Test Stockholm conference: Runö Conference Centre, Näsvägen 100, 184 92 Åkersberga, Sweden
Categories: Communities

ANZTB Test, Melbourne, Australia, May 27 2016

Software Testing Magazine - Mon, 04/25/2016 - 10:30
ANZTB Test Advancing Testing Expertise Conference is a single day software testing event that takes place every year in Australia or New Zealand. It features international and local software testing experts sharing their experience and thoughts on current software testing topics. In the agenda of the ANZTB Test Advancing Testing Expertise conference you can find topics like “Solutions Testing in the Cloud with Agile Teams”, “Outcome-based Testing Models”, “Testing Outside the Digital”, “Pros and Cons of a Mature Testing Approach for Gaming Software”, “Security in Mobile”, “Continuous Delivery and the Changing Role of the Tester”, “Grand Test Auto – Gaming from a Tester’s Perspective”. Web site: Location for ANZTB Software Testing conference: Pullman Melbourne on the Park, Melbourne, Australia
Categories: Communities

Patterns of Resistance in your Agile Journey

Resistance is a common reaction to a change initiative. As organizations attempt to grow or improve, it must change. Change can occur for many reasons. When moving to an organization that is embracing Agile, there is often a need for a significant culture change since Agile is effectively a culture change.
Agile brings about a change in mindset and mechanics, which affects both employees and customers. Whereas change can create new opportunities, it will also be met with resistance.  Agile change really isn’t any different than any other culture change, ergo the resistance will have similar patterns.  There are many reasons for resistance. Here are some of the patterns:  
Here we go again! It is comforting when things remain the same. Employees have seen change efforts come and go without any true commitment and may attempt to wait the new ones out.
  • What can you do?  The commitment to change must be clearly stated.  The change initiate must be treated as a program, with clear motivations and rewards for change.

Fear of the unknown.  Change is often defined by a journey into the unknown and it natural to resist what we don’t understand.  For most, it is unclear what the change will entail.  
  • What can you do?  Leaders should provide a vision of what the new world will look like 

Lack of communication.Employees need to know what is occurring to them. As information trickles down from the top, the message can be lost.
  • What can you do? Plan for continuous communications at all levels is important.  Include various communication channels and messages from as many champions as possible. 

Change in roles.Some employees like to retain the status quo and do not want to see their roles changed. When roles are vague, some don't know where they fit in the new culture, making them feel excluded. When they have no say in their new roles, they can feel alienated.
  • What can you do? Discuss the role changes with employees.  Give them time to adapt to the roles or give them time to try new roles.   

Competing initiatives.Introducing an agile initiative when there are already multiple initiatives occurring can lead to employees feeling overwhelmed, causing them to resist. Hardly an auspicious start!
  • What can you do?  It is important for management to prioritize initiatives and focus on the higher priority ones.

Change for people, not leaders. When asked “Who wants change?”, everyone raises their hands. But when asked, “Who wants to change?”, no one’s hand goes up.  This can be particularly true with leaders.  Leaders want change to occur within their teams but are not particularly interested in changing themselves and this may be been prevalent in past change initiatives.  
  • What can you do? Acknowledge the change that the leaders must make and convey the leaders’ commitment to change. 

New management's need to change something. New leaders often feel they must show they are action-oriented. They may reason that the change that worked in their previous company should work here. Some know their term is short, so they are not interested in long-term change. Some are unaware of what it takes to affect culture. Employees who are used to this scenario may resist. 
  • What can you do?  Avoid what may appear to be random changes.  Ensure the Agile change is aligned with better business outcomes and not just to do Agile. 

It will not always be possible to identify and manage all types of resistance.  However, it must be treated as a real and tangible activity.  It is better to start addressing resistance to change in a pro-active manner. The more you review and enact the "What can you do?" tips, the more likely you will increase your changes of a successful Agile change (or any culture change).   
Categories: Blogs

The Sauce Journey – From Star to Scrum

Sauce Labs - Fri, 04/22/2016 - 15:00

When I first started at Sauce, one group within the Engineering organization was called *Dev, referred to in conversation as “StarDev.” *Dev was so named because they were the wildcard development group – some of their work touched on this part of the infrastructure, or this part of the product, or this part of the Web interface, and so on. As a result of this interdisciplinary approach, much of the product and operational development fell under their purview, but it was difficult to tell exactly what it was they were responsible for. What was even more difficult was that when it came time to undertake actual projects, there was no clear delineation of what role *Dev needed to play in their development.

When you see the emergence of a group like *Dev, it’s a clear sign that your engineering organization has reached an evolutionary stage common to startups. That’s the stage where you go from a handful of people sitting in a room together hacking out code, to trying to formalize responsibility for parts of the product while also engaging other stakeholders within the company, like Product Management. The tendency in these moments is to think in terms of silos – this group is responsible for operations, this one for the front-end interface, this one for backend infrastructure, this one for testing, and so on. The problem with this approach is that it almost always results in organizational mutations like *Dev. because the nature of today’s software and technologies doesn’t recognize such neat distributions of responsibility. This is especially true of PaaS, IaaS, and other cloud-based offerings, that are themselves hybrid service/product offerings. I saw this phenomena occur when I took the reins at Although the team had grown to more than 30 engineers, they could only work on one project at a time. The whole team “swarmed” on a given feature, since nobody owned any one piece of the service. The first change that I made was to organize the team into smaller scrum teams that each owned a feature from end to end. This simple reorganization unblocked the log jam that had been created by the swarm mentality, and allowed teams to work on multiple projects at once.

When I first became aware of the existence of *Dev at Sauce Labs, I knew that the company was ready to take the next step in its evolution. In its interdisciplinary nature you could see that there was a clear recognition of how to approach the development of our offerings, but the organizational concept was too rooted in traditional, hierarchical managerial structures. What we needed was to get back to those small handfuls of people who could focus on specific projects, but have some method for guiding ourselves to specific goals, and make sure we we were on track.

This is the point at which introducing an Agile Scrum approach to development is the critical catalyst for the transformation from Engineering to DevOps. DevOps, like *Dev, is essentially interdisciplinary, but needs the project-oriented approach to getting things done that Scrum provides to keep it from losing its organizational coherence. By thinking of our work in terms of Epics that describe ongoing areas of activity, which in turn are made up of smaller Stories that are, in effect, composed by the teams that work on them, we have a conceptual framework for our activity that embraces the interdisciplinary demands of DevOps. By then tackling these stories in two-week sprints, we are able to define the specific tasks that are required to accomplish our goals, and measure our progress against them. While this may not immediately achieve “continuous development” or even “continuous integration”, it’s only by breaking down the tendency toward silos and monolithic organizational structures that we can then start to think about the changes in tools, systems, and processes that would be necessary to achieve those states.

We introduced Scrum at Sauce in the first quarter of 2016, and since then a few things have happened.

Code quality improved dramatically. We reorganized into small scrum teams, each responsible for one area of the service. In the past, engineers were responsible for multiple areas of the code, and were always working on multiple projects, thus often losing focus and lacking ownership of code. Scrum teams were given ownership of a single part of the codebase, and were able to focus on one thing at a time. It was also made clear that teams were absolutely responsible for the quality of their code. All of this combined to create a sense of “pride of ownership”. And as we all know, people always treat their own cars MUCH better than rental cars. The result here was the same – exponentially better quality.

We discovered a lot of problems! At first, this was startling to the team. But I assured them that this was normal, and exactly what we wanted. These problems were not new, they had always been there, but had been swept under the rug, masked. Since everyone was so frenetic and unfocused prior to scrum, we hadn’t noticed all these issues. The clarity that scrum gave us about these issues forced us to face them, rather that ignore them. The key things that we found were around technical debt. We put all of these into our team backlogs and started to figure out how to tackle them. We didn’t like what we saw, but at least we knew what the reality was.

We realized how thinly spread we were. Before scrum, all the developers were incredibly busy, but we were not getting things done at the pace that we expected. When we broke out into scrum teams, each with a distinct responsibility, we saw what the problem was. We were trying to do way too much given our capacity. Putting all desired new functionality, enhancements, bug fixes, infrastructure work, security improvements, and technical debt into backlogs showed us that demand was significantly higher than supply. This forced us to prioritize the work, and to pare down work to the most important features. That forced us to listen even closer to our customers so that we knew what was most important to them. And finally, it helped us decide what level of capacity we wanted so we could make better hiring decisions.

The move to scrum created a much more satisfied team, all around. The DevOps team was happy because they now had clearer focus on on their responsibilities. I made it clear that we had to set a sustainable pace, because this is not a sprint (no scrum pun intended!), nor is it even a marathon, this is something that we should be able to do indefinitely. Burned out engineers only make things worse. And, finally the product and sales teams were happier because they saw that things were getting done, albeit in smaller increments. Overall, everyone felt that we were getting unstuck, and bringing clarity to our work that removed the “wildcard” factor that had previously dominated.

We have a long way to go on this journey to DevOps, but I think we’re off to a great start.

Categories: Companies

Mastering the Essentials of UI Automation—Webinar Q&A Follow Up

Telerik TestStudio - Fri, 04/22/2016 - 02:54
Wednesday, March 25, Dave Haeffner, joined me (Jim Holmes) for a webinar targeted at helping teams and organizations start up successful UI test automation projects. This webinar was based on a series of blogposts on the same topic hosted here on the Telerik blogs. You can find the recording of the webinar hosted online and you can sign up to receive a copy of an eBook assembled from those same blogposts. We had a very interactive audience for the webinar. Unfortunately we couldn’t answer all questions during the webinar itself. We’ve addressed quite a few of the unanswered questions below. 2015-04-03T20:07:39Z 2016-04-22T00:37:52Z Jim Holmes
Categories: Companies

Possible Jenkins Project Infrastructure Compromise

Last week, the infrastructure team identified the potential compromise of a key infrastructure machine. This compromise could have taken advantage of, what could be categorized as, an attempt to target contributors with elevated access. Unfortunately, when facing the uncertainty of a potential compromise, the safest option is to treat it as if it were an actual incident, and react accordingly. The machine in question had access to binaries published to our primary and secondary mirrors, and to contributor account information. Since this machine is not the source of truth for Jenkins binaries, we verified that the files distributed to Jenkins users: plugins, packages, etc, were not tampered with. We...
Categories: Open Source

Pipeline 2.x plugins

Those of you who routinely apply all plugin updates may already have noticed that the version numbers of the plugins in the Pipeline suite have switched to a 2.x scheme. Besides aligning better with the upcoming Jenkins 2.0 core release, the plugins are now being released with independent lifecycles. “Pipeline 1.15” (the last in the 1.x line) included simultaneous releases of a dozen or so plugins with the 1.15 version number (and 1.15+ dependencies on each other). All these plugins were built out of a single workflow-plugin repository. While that was convenient in the early days for prototyping wide-ranging changes, it...
Categories: Open Source

Fake Backends Testing with RpcReplay

Testing TV - Thu, 04/21/2016 - 20:46
Keeping tests fast and stable is critically important. This is hard when servers depend on many backends. Developers must choose between long and flaky tests, or writing and maintaining fake implementations. Instead, tests can be run using recorded traffic from these backends. This provides the best of both worlds, allowing developers to test quickly against […]
Categories: Blogs

Regression Testing with Diffy

Software Testing Magazine - Thu, 04/21/2016 - 20:22
Your team has just finished a major refactor of a service and all your unit and integration tests pass. Nice work! But you are not done just yet. Now you need to make extra sure that you didn’t break anything and that there are not any lurking bugs that you have not caught yet. It’s time to put Diffy to work. Diffy is an open source tool developed by Twitter to find potential bugs in software services. Unlike tools that ensure that your code is sound, like unit or integration tests, Diffy compares the behavior of your modified service by standing up instances of your new service and your old service side by side, routing example requests to each, comparing the responses and provides back any regressions that have surfaced from those comparisons. Video producer:
Categories: Communities

Closing Gap between EUE, Application & Infrastructure Performance

FixStream Meridian with DC RUM I’m excited to co-author this blog with Bishnu Nayak from our new partner FixStream. I’ll write the Dynatrace perspective to set the stage, then let Bishnu add more details on how FixStream’s Meridian offering extends the definition and implementation of comprehensive performance visibility. At Dynatrace, we – along with our […]

The post Closing Gap between EUE, Application & Infrastructure Performance appeared first on about:performance.

Categories: Companies

What I Learned Pairing on a Workshop

Agile Testing with Lisa Crispin - Thu, 04/21/2016 - 18:20

I pair on all my conference sessions. It’s more fun, participants get a better learning opportunity, and if my pairs are less experienced at presenting, they get to practice their skills. Big bonus: I learn a lot too!

I’ve paired with quite a few awesome people. Janet Gregory and I have, of course, been pairing for many years. In addition, I’ve paired during the past few years with Emma Armstrong, Abby Bangser, and Amitai Schlair, among others. I’ve picked up many good skills, habits, ideas and insights from all of them!

The Ministry of Testing published my article on what I learned pairing with Abby at a TestBash workshop about how distributed teams can build quality into their product. If you’d like to hone your own presenting and facilitating skills, consider pairing with someone to propose and present a conference session. It’s a great way to learn! And if you want to pair with me in 2017, let me know!

The post What I Learned Pairing on a Workshop appeared first on Agile Testing with Lisa Crispin.

Categories: Blogs

What’s New in Surround SCM 2016

The Seapine View - Thu, 04/21/2016 - 14:30

Surround SCM 2016 is now available and it includes some great new features you don’t want to miss out on. Here’s a quick look at what’s new.

Capture electronic signatures and run audit trail reports for compliance purposes

To meet Title 21 CFR Part 11 compliance requirements, you can enable electronic signatures for workflow states to track when files move to the state and who signed off on the files in that state. Signature records are stored in the mainline database, and you can run audit trail reports to validate and review the records during an audit or for other compliance purposes.

Perform the following tasks to capture electronic signatures and create audit trail reports.

1. Configure workflow states that require an electronic signature. You can add new states or edit existing ones to change the signature requirements. More info


2. Configure compliance server options to specify the electronic signature settings, such as the signature components and the certification message to include with signatures. More info


3. Users responsible for signing off on files set states on files and enter their electronic signature. More info


4. Create and run audit trail reports to review electronic signature information, such as when files entered specific states and the users who entered signatures. More info


Reset files to default workflow states when versions change

Administrative users can configure workflow states to automatically reset to the default state if the file version changes. This helps ensure files are not left in an incorrect state when they are updated. For example, you can configure the Reviewed state to reset to the default state to automatically restart a review workflow when additional changes are checked in. More info

Run reports from the Source Tree window

There are two new ways to run reports on files from the Source Tree window.

You can quickly create and run one-time use reports from the Tools > Quick Reports menu. You no longer need to open the Reports dialog box first to create reports you don’t need to save. More info

You can also create custom shortcut menu items to run saved reports when you right-click repositories. Before you can run reports this way, you need to create a plug-in for the menu item and add it to the repository shortcut menu. More info


View syntax highlighting in the built-in file viewer and editor

Enable syntax highlighting to show specific text in different styles and colors in the built-in file viewer and editor. This makes file contents easier to read when you view and edit files, perform code reviews, and search for text in files. More info


Learn more about Surround SCM 2016

Check out the release notes and help to learn more about Surround SCM 2016.

Categories: Companies

Cambridge Lean Coffee

Hiccupps - James Thomas - Thu, 04/21/2016 - 08:24

We hosted this month's Lean Coffee at Linguamatics. Here's some brief, aggregated comments on topics covered by the group I was in.

It is fair to refer to testers as "QA"?
  • One test manager talked about how he has renamed his test team as the QA team
  • He has found that it has changed how his team are regarded by their peers (in a positive way).
  • Interestingly, he doesn't call it "Quality Assurance" just "QA" 
  • His team have bought into it.
  • Role titles are a lot about perception: one colleague told him that "QA" feels more like "BA".
  • Another suggestion that "QA" could be "Quality Assisting"
  • We covered the angle that (traditional) QA is more about process and compliance than what most of us generally call testing.
  • We didn't discuss the fairness aspect of the original question.

What books have you read recently that contributed something to your testing?
  • The Linguamatics test team has a reading group for Perfect Software going on at the moment.
  • Although I've read the book several times, I always find a new perspective on some aspect of something when I dip into it. This time around it's been meta testing.
  • The book reinforces the message that a lot of testing (and work around the actual testing) is psychology.
  • But also that there is no simple recipe to apply in any situation.
  • We discussed police procedural novels and how the investigation, hypotheses, data gathering in them might be related to our day job

When should we not look at customer bugs?
  • When your product is a platform for your customers to run on, you may find bugs in customer products when testing yours.
  • How far should you go when you find a bug in customer code? 
  • Should you carry on investigating even after you've reported it to them?
  • In the end we boiled this question down to: as a problem-solver, how do you leave an unresolved issue alone?
  • Suggestions: time-box, remember that your interests are not necessarily the company priorities, automate (when you think you need lots of attempts to find a rare case), take the stakeholder's guidance, brainstorm with others, ... 
  • If the customer is still screaming, you should still be working. (An interesting metric.)

Categories: Blogs

Knowledge Sharing

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