To start testing Salesforce SOAP API with SoapUI, follow the quick steps below:

1. Register a Salesforce developer account.
   • Make sure to register a developer edition account from https://developer.salesforce.com/signup   Do not register from www.salesforce.com, as you won’t be able to ‘generate wsdls’ which will be needed in the next step.
2. Reset Salesforce Security Token
   • Login to the developer account, go to personal settings -> reset security token,   you will receive an Email with security token info.  Make note of it, it will be used when test web service authentication in later steps.
3. Download WSDL file
   •  Go to Setup -> Custom Code -> API,  right click ‘Generate Enterprise WSDL’ link and save file to your local.
4. Create a Soap Project in SoapUI and import the WSDL file
5. Use SoapUI to test Login service in Enterprise WSDL
   • Expand the SoapBinding node from left navigation, double click Request 1 under ‘login’ to create a new login request.
   • Fill in parameter values in the request message body
     • username (same as your salesforce user name)
     • password ( here password should be your Salesforce login password concatenate with your security token)
     • remove ‘?’ from other fields
   • Submit the request, and you should get a response successfully.
   • Fix TLS version issue (when necessary )
     • In case you got below error in response message as I did: “UNSUPPORTED_CLIENT: TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https”,  you’ll need to make changes to SoapUI to have it use higher version of TLS.
     • If you are on Windows, follow steps in this post.
     • If you are on Mac, you’ll need to find file /Applications/SoapUI-X.X.X.app/Contents/vmoptions.txt, and add a line to the bottom:-Dsoapui.https.protocols=TLSv1.2 
   • Analyse Response from Login request,
     • Notice element sessionId, serverUrl in response message body, they’ll be used in subsequent requests.
6. Once Login successfully, test subsequent Enterprise services, E.g. queryAll
   • Double click ‘Request 1’  under queryAll, to create a queryAll request message
   • Fill in sessionId in message header with sessionId obtained from Login response.
   • Fill in queryString such as “SELECT id FROM Account”.
   • Fill in batchSize such as 3 for example.
   • Change the request Url from default to serverUrl obtained from Login response.
   • Submit the request, you should be able to see list of accounts in the response message.
7.   You are all set to go. Have fun!

Story Point estimation is a critical technique for project planning and team velocity tracking in an agile project.

Usually, to estimate the size of a user story , we tend to compare it with the standard user story which already has a fixed number of story points. We get the feeling how big the user story is by comparing it with the standard one, and then we get the story point number for this new user story.

However, user story point estimation more than often is quite confusing for developers.  In blog: Quantitatively Measure Story Points in Color,   Ethan Huang has introduced the challenges that could happen during user story point estimation, and he has provided a technique which could help us analyze and estimate story quantitatively.

There are still some challenges though:

– How to estimate research work such as developing a POC?

– Suppose there are different work types, like web development,  ESB integration, and reporting in the same project,  how shall we compare them and estimate them with the same measurement – story point?

– Also, for project management, can you tell how much research work in your project? How much routine non-research development work in your project?

These problems can be solved to some extent by adding the “Story Type” or “Story Implementation Type” concept into your story planning/estimation.

–          In your product backlog or user story planning tool, add a new sheet “Standard Stories”, where you can define a table of standard stories. Each Story Implementation Type has at least one standard story and non-change story point with it.

–          In your product backlog, add a column “Story Type” or “Story Implementation Type”.

–          When estimate a user story , always refer to the “Standard Stories” sheet.  Estimate it by comparing with the standard story of the same Story Type.

Benefits of this approach:

–          Easier to estimate for developers.

–          More accurate estimation.

–         Clear view of total story points, as wells subtotal of each story type.

When to use:

When a project implementation requires disparate technologies, or requires significant research work.

Tips:

As “Story Implementation Type“ looks more from developer’s perspective rather than from user’s perspective. It is only a technique to help developers/project managers estimate more accurately. It does not help when gather requirements.

How do you think?

Perficient’s China Global Delivery Center was established in 2004 and is located in Hangzhou, China.

As an employee of this company for more than three years and a citizen in Hangzhou, I am more than proud to introduce this wonderful city to you – the best business and tourism city in China.

Hangzhou, as the capital of Zhejiang province, is located along the southeast coast of China, and it only takes 40 minutes by the newly built high-speed railway from Shanghai.  Hangzhou is a key national tourism city, historical city and vice provincial level city as confirmed by the State Council. Hangzhou is renowned as “Paradise on Earth”, “Cultural State”, “Home of Silk”, “Tea Capital”, “Town of Fish and Rice”.

Hangzhou – China’s Best Tourism City:

Hangzhou is renowned for its historic relics and natural beauty. It is often known as one of the most beautiful cities in China. It has been ranked as one of the ten most scenic cities in China.

Hangzhou – China’s Best Business City:

Since 2005, Hangzhou has consistently been ranked number one on Forbes magazine’s annual ‘China’s Best Places for Business’ list. The survey looks at the quality of the labor force, business costs, market size and capitalization to find the top business cities in the country.

Welcome to Hangzhou!

Further reading:

http://www.chinadaily.com.cn/bizchina/2008-09/03/content_6994208.htm

http://en.wikipedia.org/wiki/Hangzhou

Most people might not think test data preparation is important in software engineering. However it becomes an improvement area as more and more companies start to apply TDD (test driven development) now. Managing test data differently may impact your project more than you think.

First, let’s look at a question many developers might have:  How to prepare test data for integration tests?

Here “integration tests” means writing reusable tests to test server side integrated functionalities, not to test user interface. The difference between unit tests and integrated tests could be summarized as: Unit tests ensure we do things right, Integration tests ensure we’ve done right things.

To explain the problem of test data preparation, let me describe a little bit.

Traditionally, test data preparation is like:

– Tester/BA writes test case documents. Test data disperses in test case steps.

– For developer who needs to write integration test code to ensure user story functionality, he has to prepare test data by self. The test data is in format of SQL or XML aiming to be used by code.

Problems are:

– It is hard and painful for developers to prepare test data because of lack of business knowledge and real life data. To translate each test scenario into test data correctly is not an easy job. In result, the reality is in most time integration tests only cover main test scenarios or even no integration test at all. The testing work is left to test team when UI testing.

– Neither test case document creation nor developer’s integration test data preparation involves customer. The test data is created by imagination.

Questions for improvement:

– Instead of having test data multiple places, can we reuse single source of test data which provides multiple views for both customer and developer’s usage.  (More about single source, see here)

– How to involve customer into test data preparation and even test cases effectively?
Solution 1 – Eclipse TPTP:
The first thought came into mind was using Excel file. The idea is to store test data with test scenarios in Excel file in certain format. Use the Excel file to confirm with client. Then use the same file as input for developer’s integration testing. We just need to build a simple utility to pull Excel test data into test code, execute tests, then update testing result back to the Excel file. And this way we can integrate with XUnit well.

Eclipse Test and Performance Tools Platform (TPTP) has already implemented this thought about using Excel for single source test data.  Check it out.

Solutions 2 – FIT / FITNESS:
The other choice is FIT.  You will find that FIT actually solves the above problems perfectly!
And it has the additional benefits:
– Test data and executable test cases are defined early which is perfect for test driven development (TDD).
– Test case is determined.  Client can “feel” the requirements. Developers have clear goal to achieve.

FIT can help greatly in applying TDD successfully.

Comparison – Eclipse TPTP Vs. FIT
Now we have two options for “single source test data”:

Although Eclipse TPTP has some limitations and is not perfect for TDD, in some cases we might still consider using it. Because:

–  We can still do some interactions with customer using the Excel data file.

– It is a lightweight tool, and is easier to be applied in projects.

Finally, will you start considering improving your test data management and try to make test data single source?

Thanks!

In the previous post, we talked about some major challenges we experienced in an integration project. In this post, I will share some suggestions on how to solve these problems. I also bring the discussion about using “Agile” or “Check Point Control” in integration project plan.

Based on the previous post, it becomes natural that below items are important for managing an integration project in control:

1. Remove dependency on single integration environment

2. Manage cross team dependencies

3. Avoid vague integration design

4. Adapt to changes

5. Plan properly

Let’s discuss them one by one.

1. Remove dependency on single integration environment

– We established another integration environment offshore (duplicate from the original one). We also build mock up environments for end systems, so that we can run end-end integration testing without depending on any other parties.

– Another reason for doing this is that offshore continuous integration also requires for a dedicated integration environment.

2. Manage cross team dependencies

Define project coordinator and cross team meetings

To solve the problem that each team has their own schedule, it is important to define a formal project coordinator role to coordinate between teams.

The coordinator needs to make sure all teams reach a consensus on the integration plan. Keep tracking each team’s status, make sure their schedule meets integration plan and keep the integration plan in good shape.

This could be achieved through periodical meetings which involve the coordinator and all the team leads.

Increase visibility of dependencies and issues

– Use wiki pages for publishing cross team artifacts (requirements, designs, interface definitions, etc).

– Use issue tracking tool for tracking cross team issues. – Jira is a good choice.

Each team should follow a high quality standard

This is to ensure high quality of each component (through unit test normally). In result, it will smooth the cross team integration work.  –  Cross team integration testing will not start when component’s unit test still fail.

3. Avoid vague integration design

In my opinion, a “detailed” integration design brings below benefits:

– Expose potential integration issues on the table early. This allows teams to have enough time to go through communications and solve issues.

– Smooth the work of implementation and integration. Things underneath get clear. This makes the most uncertain part ( implementation and integration ) estimable.

– Have the senior resource deal with the most challenging work.

A good quality integration design could include:

– A flow diagram and descriptions.

– Interface definitions and mappings.

– A list of technical difficulties and solutions.

– End-end test data if applies.

– A solution prototype if necessary.

The “detailed” design doesn’t need to be complex though.

Ensure integration design quality

– Design quality can be verified through cross team design review meetings.

4. Adapt to changes

Track changes on Wiki.

– Keep cross team artifacts up to date on the wiki page.

– Configure auto Email notifications to related parties when changes on Wiki.

– Once a change is handled, add a note on the page to indicate you have taken care of the change.

Write reusable tests and set up continuous integration.

– Reusable tests include: reusable unit tests, reusable integration tests, reusable functional tests. The GDC has tremendous experiences in applying continuous integration and test driven development. We have good experiences regarding setting up automatic testing framework and continuous integration for integration projects as well.

5. Plan properly – using check points

– We can define several “check points” representing states in an integration work bundle’s life cycle. Such as: Requirement review -> design review -> implementation (unit test pass) -> integration test pass-> functional test pass

– Having the check points defined will help us control quality of each step, know the exact status or bottleneck of the project clearly.

– It also helps plan and track the project. We can plan an integration work bundle across multiple iterations.  Each iteration should achieve one or multiple check points completion, depending on complexity of the work bundle.

– We’d better plan enough time for integration designs. Consider separating design and implementation into multiple iterations to ensure quality.

Discussion: Agile vs. Check Point Control

Somebody can’t help asking: you are not doing agile here! Well, yes, this is a little different as our traditional agile.

As in traditional agile, we tend to focus on a small piece of work per iteration. We do simple design, and then quickly start building functional deliverable. This allows us to adapt to frequent changes and always deliver high value features to client. The reason we don’t do that in integration projects is because of integration projects’ nature. Cross team dependencies and the invisibility to other teams’ work could cause significant cross team communications, and is often a long process. That’s why it is hard to do simple designs and then start implementation right away in an integration project.

As far as using control points here, I would suggest that normally, we should plan work on check points one by one. Means the next check point work should not start before the previous check point achieved (Exception – test team can start integration test cases development when development team is still working on implementation, because they both depend on the design). This is to ensure quality of each step and avoid insufficient input for the next step. However, in some cases, if the integration is quite simple, this rule may not need to apply, the steps can still overlap. Then it becomes more “agile”.

In my opinion, choosing “agile” or “check point control” is all about balancing. If more “agile” – means simplified design, no strict check point control, work steps overlap. In result, we have light process to go through, and are more adaptable to frequent changes. But we have less control on the project and are very dependent on people. If we don’t have right people, the project could easily be in risk.  On the other case, if we do less agile, and more check point control, then we’ll have a heavier process to go through, and we are not able to adapt to changes quickly, yet we’ll always have the control of the project.

In my opinion, “check point control” should be more suitable for integration projects which have longer schedule, not straightforward, and involve multiple teams. Just because pure “agile” is hard to apply in this case.  We still embrace agile as much as we can. Examples like that we make sure high value integrations always get delivered first, and we stick to the test driven development approach.

It is exciting to see so many integration projects pop up in our offshore global delivery center (China GDC).  As we know, most integration projects are very often challenging. Since I have worked as the offshore team lead in a mulit-shore integration project, I would like to share what I learned with you.

First, I’d like to list several problems the team faced in the early phase of the project.  – I think they might be typical for many integration projects.

Case 1:

Only one central integration environment was used by both the onshore team and the offshore team. Several environment issues occurred, and it just failed to work. This blocked the whole team, from being able to do any integration testing. Let’s call this case as – single integration environment dependency.

Case 2:

Based on the plan, the team needed to complete an end to end integration by end of the week. Though the team had completed the integration component, and was ready for the end-end testing, we were told that the end system functionality (developed by another team) was not ready yet. The integration was delayed. The team had to switch focus unexpectedly.

Or, the two teams did start the integration testing. But due to lack of unit tests, it turned out to many integration test failures. The two teams had to work together to debug and fix issues one by one. Apparently, this is not a very efficient way to work since it causes waiting.

To summarize, an integration project often involves multiple systems, thus requires for multiple development teams. This results in cross team dependencies. If not managed carefully, the dependencies will become issues.

Case 3:

Usually, each development team only has knowledge about his part in an integration project. A tech lead of the integration team would have limited knowledge about functionalities, interfaces, limitations of the source system or target system. This often leads to vague design if without enough attention.

When an integration team member starts to work on an integration task, he could find out that the integration interface is not clearly defined yet, even the integration solution is vague and has many things to be finalized. He will need to work out design details with his tech lead as well as the end system tech lead. Unfortunately, it is very likely that the end system lead will be overwhelmed at that time. Because so many integration designs and interfaces need to be finalized at the time! Communications go back and forth between the integration team developers, end system developers, tech leads, end users. Deadline approaching, a solution has to come out, implementation is in hurry, and unit testing? No time! Also notice that in this process, the senior guy who originates the design, is in the supporting role. The owner of the integration is the developer. Do you see the problem here?

Case 4:

Many changes occurred during the development work. A lot of effort was spent on dealing with changes due to lack of reusable tests.
– As an integration project, changes could occur in source systems, target systems, integration components, or interfaces. Changes could break working functionality unexpectedly, and cause significant effort on manual testing, debugging, defects fixing, etc.

Does these above sound familiar to you? Or are you experiencing the same things now? I hope not,

Well, with such a number of uncertainties, a single integration would be hard to estimate. How could we manage an integration project in control?  Fortunately, I think we figured out the solutions during the project, and that is what I will share in my next post.

What are your thoughts on this? Thanks!