Search for:

Installing a SOAPSonar License Server

SOAPSonar comes in a per seat and floating license models. Floating license are popular for occasional users and offshore sharing as they allow SOAPSonar to be installed on as many users machines as you would like, and only counts concurrent users.

The license controller application is only used briefly on checking out of the license and checking the license back in. The instance of SOAPSonar still runs on the local machine. As such minimal “server” load and network is required. The license controller is in fact a small process that runs on a windows machine, which requires a static IP address. On my machine its says its using 20,000k of memory, about 33% of chrome and the entire file is only 4.2 MB.

1. To install the license Controller start by downloading it from here. Install this on your server with Admin Rights. Once installed, although I try keep this post up to date, please check immediately if this is the latest version.  To do this, run the license controller and select Updates, Check for Updates.

1. Check for updates

2. Make sure the the process is running and automatically starts on your server. If the service is unavailable, license will not be available to check in or out. Right-Click on the icon in your tray, and select Manage Licenses.

2. Process

3. Every server is fingerprinted, and your licenses tied to that server. Select File, Show Server ID, and copy this value. Send this FingerPrint ID to [email protected]

3. Show Server ID

4. Your license will then be generated by Crosscheck Networks for that server ID, and we will send you back your license key. Select File, Add Licence Key and paste your license. Select OK. Each group of licenses should now show as a line item.

4 Add key

5. Select File, Preferences, and confirm and on the License Server Settings tab, confirm your port number. Run cmd, then enter ipconfig to get your IP address. These are needed for users to connect to the server.

5 port and IP address

6. On the second tab, Client Installation Version Control, you can set the minimum or maximum version and the download location to ensure that your team uses the same release. This is helpful if you sharing projects.

Versioning

7. Statics offers a way for you to see which users use what licenses and how often. Enabling planning between seat and floating licenses.

7 Statistics

 8. On a workstation, download and install SOAPSonar. Its important to do this by right clicking on file and run as admin, for access to .Net libraries. Select Registration, Use License Server. 8 Check out

9. Enter the IP address and Port of your license server, Select Key Type and Request License.

9 connect

If you have any question, please just reach out to me.

 

 

 

 

 

 

ST3PP Presenting at TASSQ in March

Join us at TASSQ this March the 25th in Toronto at the The Albany Club – King & Church Streets 5:30 pm networking 6 pm dinner 7 pm presentation. March’s presentation will be done by ST3PP’s me, Ivan Flowerday. Visitors and new members are always welcome at TASSQ and attendees include anyone who has an interest in software quality, or software testing, whether they work for a large corporation, a small software house, or whether they are independent consultants.

ST3PP’s mission is to Align the domains of Tools, Process and People, to achieve excellence. At TASSQ, I will be sharing some thoughts and ideas collected by meeting with a number of QA and Development organizations. The session will also be interactive, with attendee participation.  Although it will cover all 3 domains, no specific organizations Tools, People or Processes will be used. The intent being to generate ideas or thought that members can further investigate, and perhaps apply in their teams. Similar to much of ST3PP ahead newsletter.

To give you some idea of what I will be discussing you can read a detailed look at service plan costing

We look forward to seeing you there and please stop by an introduce yourself if you have not already.

 

 

KPI – Identifying Areas in Process that Requiring Tuning

Both Six Sigma and CMMi focus on creating and managing a feedback loop. Assessing the current status in your organization and then identifying areas for improvement.  To do this, KPI or Measurement Objectives are needed to measure the effectiveness of your organizations Tools, People and Processes. Measuring details like Defect Density, Test Coverage, Total defects, reliability etc. Then collecting the relevant data and analysing these measurements to provide insight into the the results, set goals and track progress.

One of my favourite tools or methods to visual and analyse KPI is via Pareto Graph. Its simplicity makes the 80/20 rule stand out to any level of an organization. In the above example the first 7 groups of defects is clearly well over 80% of the all defects. The impact of addressing the others being minimal, while a small change in the first 3 could have major impact to your organizations quality.

Potential issues with Pareto Graph.

Although extremely helpful in identifying areas that need to be addressed, there are some potential pitfalls on relying on Pereto analysis too much. These include

  1. It is important to define and group the categories correctly. They need to both be precise, so that there can be little doubt as to which category the defect fits into and they need to be of a suitable granularity. Making larger groups, can make addressing the sub issues in the groups difficult, yet making too many sub-groupings can result in loosing the visual effect and intent of the pareto.
  2. Selecting appropriate time periods is important. Measuring only a single release cycle or team, can result in wild fluctuations in results. Consolidating multiple teams, releases etc can cloud visibility into a particular team or release issues.
  3. If changes are made to the Tools, People and Process, to address the issues identified in the  pareto chart, adding them to the same period will not offer any insight into the effectiveness of these changes. These changes need to be compared to a previous baseline. Baselines however can become rapidly dated.
  4. Pareto analysis is draws focus on areas of greatest need, but a laser focus only on those areas, can rapidly destabilize others. Some of these other fixes could be potentially low hanging fruit requiring little effort to resolve.
  5. Although Pareto analysis identifies common areas that may require focus or consideration, it does not supply solutions.

Poll

What I have learnt is that when someone sits down and actually gathers the information and generates a Pareto chart for analysis, they are almost always surprised by what is revealed. For benefit of all,  I wanted to take a short Poll.  First off, looking at teams that do use pareto analysis and teams that don’t.  What I would be interested in seeing, is if these teams see common or different set of issues. In other words, does doing a pareto analysis change peoples list of most common defects. The results will be collected privately and consolidated by me, and posted at a later date. Comments at the bottom of the page posted before hand for public, but comments in the poll kept private unless you stipulate in them you wish to be mentioned.

Please take a minute to weigh in and help others ST3PP ahead.

[contact-form subject=’pareto analysis’][contact-field label=’Screen Name’ type=’name’ required=’1’/][contact-field label=’Does Your Organization Use Pareto Analysis’ type=’radio’ required=’1′ options=’Yes – we review them frequently,No – I have never seen one for my organization’/][contact-field label=’1 – Most Common Defect Group’ type=’select’ required=’1′ options=’Business Changes – Missing or added business functionality,Design Defects – Missing or incorrect architecture requirements,Developer Defects – Missing or defected functionality in code,Environmental Defects – Versioning%26#x002c; enablers or other other site issues,QA Defects – Incorrectly identified as a defect,Other – Please describe in comments’/][contact-field label=’2 – Second Most Common Group’ type=’select’ options=’Business Changes – Missing or added business functionality,Design Defects – Missing or incorrect architecture requirements,Developer Defects – Missing or defected functionality in code,Environmental Defects – Versioning%26#x002c; enablers or other other site issues,QA Defects – Incorrectly identified as a defect,Other – Please describe in comments’/][contact-field label=’3 – Third Most Common Group’ type=’select’ options=’Business Changes – Missing or added business functionality,Design Defects – Missing or incorrect architecture requirements,Developer Defects – Missing or defected functionality in code,Environmental Defects – Versioning%26#x002c; enablers or other other site issues,QA Defects – Incorrectly identified as a defect,Other – Please describe in comments’/][contact-field label=’4 – Fourth Most Common Group’ type=’select’ options=’Business Changes – Missing or added business functionality,Design Defects – Missing or incorrect architecture requirements,Developer Defects – Missing or defected functionality in code,Environmental Defects – Versioning%26#x002c; enablers or other other site issues,QA Defects – Incorrectly identified as a defect,Other – Please describe in comments’/][contact-field label=’5 – Fifth Most Common Group’ type=’select’ options=’Business Changes – Missing or added business functionality,Design Defects – Missing or incorrect architecture requirements,Developer Defects – Missing or defected functionality in code,Environmental Defects – Versioning%26#x002c; enablers or other other site issues,QA Defects – Incorrectly identified as a defect,Other – Please describe in comments’/][contact-field label=’Private Comment To Me’ type=’textarea’/][/contact-form]

 

SOAPSonar with HP Quality Center Integration

SOAPSonar is a HP Software Certified Application and provides native integration with HP Quality Center allowing test run information to be published directly into HP Quality Center. Tests can be run from either within a Quality Center project, or separately from the SOAPSonar console or command-line interface. SOAPSonar also provides an HP Quality Center console allowing browsing Test Instances, Test Sets, Defects, and Attachments. SOAPSonar projects can now be managed and stored directly within an HP Quality Center project. Read More

Performance Tuning Mobile API – Introduction

Mobile applications offer a number of unique challenges with regards to testing, adding complexity through an expanding number of variables. Along with usual testing concerns, there is an array of devices, with an uncertain network and the emerging mobile services standards themselves.  Business people wish to focus on the user’s experience, attempting to gain some level of certainty in what is still a very uncertain and emerging world. Specifying requirements to developers and QA that can be extremely difficult or costly or even impossible to validate.  Let’s take a poorly crafted requirement “the application screens will refresh in less than 3 seconds on devices and networks”.

When in field testing, a device consistently requires more than 3 seconds to refresh a screen, what is wrong? Did Developers or QA fail to meet with the requirements? When performance is poor, how do developers and testers pinpoint the problem? Is it even a software issue that can be fixed? Is it perhaps the devices memory/CPU load, the screen size or storage space, the client software, or perhaps bug in that particular version or OS. Perhaps it’s the geographic location of the user, the wireless provider, the type of network the user has, the user’s physical location and signal strength. Or perhaps it’s one particular service, identity, encryption, authentication or some 3rd party service used by the mobile application. There are literally thousands of possible causes and combinations, making it impossible to consider, test and validate them all. Tuning however for the best chance of success is possible.

With the problem being the number of variables, it is no surprise that best practices usually involve dividing these variables into groups and then testing to understand the impact each particular group can have on performance rather than attempting to test for every permeation.  By breaking the entire experience into smaller components, and understanding the impact of each component, variances can easily be identified. Although every organization and application is different,   let’s looks at 4 groups.

  1. Client – The device, its operating system, and applications on it, including the your own.
  2. Network – wireless and wired communication from wherever the client is to the Ethernet port of the API.
  3. API – The Services that are Consumed by the Mobile Application
  4. Enablers – The services, like Databases, Identity, 3rd party etc that support the API.

This can be represented as:

User Experience = Enablers + API + Network + Client.

The next post is on understanding the impact of client and on ways to isolate and understand the impact that client has on your overall performance for troubleshooting.