Our new app, The Enterprise Mobility Benchmark Tool, has just been launched and is here to help in forming your mobile strategy.

In order to address the mobile strategy of your business and unleash the full potential of mobile computing, knowing where to start is the crucial first step. Once this is established you can address your eventual goal and how to reach your mobile objectives.

By using our Enterprise Mobility Benchmark (EMB) tool, your business will be provided with the benchmarking information needed to address mobile strategy and optimise your mobile computing potential. Sogeti’s tool evaluates your responses to a number of benchmarking questions; thus allowing an assessment to be made regarding your current enterprise mobility status. The tool then helps you to design and manage your future mobile strategies efficiently and effectively. 

The Enterprise Mobility Benchmark tool is based on a proprietary framework that is an essential part of Sogeti’s Mobile Strategy offering. Every strategy engagement focuses on the same six critical areas:

• Objectives – What you want to achieve from your mobile strategy
• Management – How to manage your strategy day to day in your business environment
• Technology – Which technologies to use to advance and make the most of your mobile capabilities
• Scope – Managing the stakeholder expectations for your strategy
• Policies – What are the ground rules and how should they be enforced
• Measurement – How to check whether your mobile journey is on track

The EMB tool is already helping businesses like yours to make clear, informed decisions by assigning scores to each of these areas of these key business areas – consider them musical notes!

Our framework and approach are innovative, helping to transport you from a cacophony of mobile experimentation to a more harmonized enterprise mobility solution.

The EMB tool runs on iPads and iPhones and is simple for all users across the business to learn and utilise. Furthermore, Sogeti have help at hand in the form of our mobile experts who will ensure you realised the greatest benefit possible from the tool.

If you are interesting in finding out more about our EMB framework and the app itself, as well has how Sogeti can help you benefit from the tools available, download the Enterprise Mobility Benchmark Tool Brochure here.

We also have a white paper available on the topic of Mobile Security which can be found here.

Also known as chain testing, and often abbreviated to E2E testing, end to end testing involves testing the flow of an application from start to finish to make sure it is meeting the needs of its designers and users at every stage.

Why test systems end to end?

Today’s software systems are often extremely complicated, and many are connected with a number of sub-systems; some of which might be completely independent, hosted in different locations or managed by external resources. If one part of the interconnected whole fails, the entire system is at risk. Testing the whole system from start to finish verifies the overall system flow and detects potential problems.

End to end tests compared to system testing

Distinct from system testing which concerns only the main system and its specified requirements, end to end testing checks an application’s integration with external interfaces as well as validating the software system itself. It identifies system dependencies and makes sure the components and the systems exchange the right information. End to end testing also checks that the integrated components of applications work exactly as expected, testing the entire application under a variety of real-world test environments to validate interactions with upstream and downstream systems.

What is the process?

1. Identifying and documenting the system’s / sub-systems’ processes
2. Identifying and documenting testing requirements
3. Designing and testing appropriate hardware and software
4. Developing test coding and design, methodology and standards
5. Setting up the test environment
6. Designing and tracking test cases
7. Test execution
8. Reporting and providing input/output data

How do we ensure the success of E2E testing?

There are some important considerations when undertaking E2E testing. The first key consideration is that this type of testing must be conducted in an environment as near as possible to the target production environment, including all information transfer protocols, firewalls, load balancers etc.

And, as with all development and testing, another significant success factor will be the clear definition, documentation and acceptance of objectives, responsibilities and expected outcomes at the beginning of the test phase, by all stakeholders including members from different teams, departments and potentially even different companies. 

What are the benefits of E2E Testing?

E2E testing can be used to address a wide number of issues with different types of testing including functional, performance, operational and user acceptance testing and so it is a great method to use across the board.

E2E is also the most comprehensive testing method possible to carry out before your applications go live. E2E testing will therefore give you the very best indication of how your application will perform, and will ultimately help you to deliver you the most efficient and robust systems.

When does end to end testing take place?

End to end testing usually happens after functional and system testing have been completed.

When considering a new test provider you need to take transition seriously, and that means having a thorough approach to change. Successful transition involves merging two or more sets of testing system landscapes with two or more sets of business processes, migrating the lot seamlessly to arrive at a leaner, more efficient offshore model.

Transition is mission critical and businesses can’t afford to lose anything in translation. It’s often very complex too, and a Big Bang approach isn’t really appropriate – it’s far too risky! That’s why Sogeti tackles transition differently.

Instead of going for broke, we build momentum through a carefully considered, phased approach, which can take up to five months. That way we get quick wins in place early and avoid the typical bottlenecks caused by slowing down the entire transition to suit the pace of the slowest component.

What about the people side of transitioning?

As you can imagine, there are often implications with transitioning the personnel within test teams. The Transfer of Undertakings (Protection of Employment) Regulations, or TUPE, protects employees’ interests when their role is transferred from one owner to another. Sogeti are dedicated to best practice in this area, ensuring that transferred employees enjoy exactly the same  terms and conditions as those present in the team they are transferring to.

We’re determined to maintain people’s enthusiasm and commitment by endeavouring to provide employment at locations and job levels compatible with individuals current positions, and we always act in line with TUPE requirements. During the last decade we’ve been involved in just under 5000 TUPE transfers from 86 different companies and our approach is rooted in the fabric of our business. Almost a third of our employees have come to us via TUPE transfer and analysis proves they have better retention rates: 92% as compared to 89% for people employed via other channels.

Examples of seamless Sogeti transition 

• We transitioned 2,300 people at a large central government organisation, taking them on a transformational IT journey involving 600 IT applications, eight critical development programmes and more than 160 more live projects.

• At a leading car manufacturer we took responsibility for more than 300 critical applications, using robust, explicit knowledge transfer processes that worked a treat.

• We successfully transitioned the principal mission-critical systems from three incumbent suppliers without service degradation of any kind, for a large UK Police Authority.

If you aren’t currently getting the value you expect from your test provider, then perhaps it’s time to consider transitioning. It’s not always the easy approach but more often than not it can lead to much greater things. If you have any questions, or would like to find more information, please email us.

Non-functional testing can only be carried out after functional testing. So what’s the story?

About functional testing

Functional testing involves meticulously testing a piece of software against your business’ specific requirements. We can either take the functional specification you provide or use design team-led specifications generated by our designers. It includes, but is not restricted to:

· Unit testing to make certain every component of the whole project delivers its functionality as defined by the project
· Sanity testing to make sure critical functionalities are not broken after a build
· Integration testing, either top down or from the bottom up, to ensure the whole project delivers the desired functionality when individual components are brought together
· Regression testing to spot late-coming defects and hitches which may have been introduced as changes were made to the system before going live – regression testing ensures functionality included in the system, before the changes under test are introduced, are not impacted
· Pre user acceptance testing, both alpha and beta, plus user acceptance testing
· Black / white box testing techniques, looking at the software on the surface / in detail
· Global and local testing

About non-functional testing

We carry out non-functional testing based on your business’s performance requirements, with test scenarios defined by you. It includes:

· Load testing, stress and volume testing to ascertain the capabilities of the software, and ensure it is scalable and stable
· Performance testing to make sure it meets your accepted speed, responsiveness, stability and scalability requirements, and the desired level of user satisfaction
· System testing to make sure the whole works as well as the sum of its parts
· Data conversion testing
· System and network security tests, to ensure required levels of authentication, authorisation, availability and confidentiality of data
· Ergonomics testing
· Compatibility and migration testing to make sure it dovetails seamlessly with your systems
· Installation testing, to check it works in situ
· Usability testing to ensure the best possible end-user experience
· Operational readiness testing, to make sure you’re ready to turn on the switch

If you’ve ever experienced the stresses of testing at the end of the development lifecycle you’ll appreciate how resource-hungry and fraught with danger it can be. Almost every software design project comes with a few minor loose ends – it’s the nature of the beast – but there are plenty of ways to minimise them. Here’s our guide to easing the squeeze for smoother, cleaner, less stressful and more cost effective software system delivery.     

1. Testing earlier on in the development lifecycle
 
The earlier on in the development cycle you start testing, the better. Testing from the offset means you can tackle issues and bugs as they arise rather than having to un-pick large amounts of work, wasting time and money. Testing isn’t just using the software. It’s looking at the design and the requirements. Building the tests at the same time as the system is being designed or developed means important questions can be asked much earlier in the life cycle.

2. Requirements and definitions
 
Requirements are rarely (if ever) set in stone. The process of developing software and systems and the questions that are then asked means that designs continually evolve and change. This is not a bad thing. Good systems evolve and respond to changes in the requirements over time – it’s the same when they are being built.

While it might seem like a good idea to try and define and pin down the requirements up front the truth is that you cannot. Instead ensure that the requirements are kept as clear and precise as possible and that they are updated. Expect to make changes and welcome them.  Have a process in place that allows the information to be quickly communicated and expect to update test cases, use stories etc. as the requirements change.

3. Buy-in from all stakeholders and users
 
When all the people involved have fully bought into the project, things are much less likely to unravel. You need a rock solid team who know exactly what their responsibilities, aims and objectives are. A successful project involves all the stakeholders and developers and managers and IT departments and suppliers working together.  When people feel that they are part of the project then they are more likely to be part of the solution than the problem.

4. Project management excellence
 
Great project management helps projects stay within the specified boundaries and puts quality at the heart of the development cycle. Time management, quality management and scope management are key to successful project delivery.
 
Getting it right with Sogeti
 
Our PointZero vision means we’re focused on getting things right every time. It’s an umbrella view designed to ensure the optimisation of the overall application lifecycle from the very beginning, which means we don’t waste time and money on rework.
 
Shift Left in action as showcased first at TestExpo 2012, allows us to harness the value of PointZero, as it enables us to establish quality measures from the offset, and bring them into play much earlier in the project lifecycle, therefore moving left along the timeline. As a result our clients benefit from fewer change requests, faster delivery and lower overall costs.

In the last in our series of posts about testing on the cloud we’re looking into some of the operational challenges you might experience when implementing cloud testing.

Operational Challenges in cloud testing

Despite the clear benefits, there are still some areas where testing on the cloud has limitations which organisations need to be aware of. We explore these below, with pointers for how they could be overcome.

Infrastructure requirements

It is vital that Infrastructure requirements are rigorously set, because the very flexibility that the cloud offers for testing environments can actually become a risk if the requirements for those environments are inappropriate. Results will then be poor, and negative perceptions of the cloud as a test environment will result from what was really lack of attential to requirements around the infrastructure. Using a simple checklist will help reduce this risk to a minimum.

Legacy systems

Most types of services and systems (including legacy systems) can be virtualised, however 5-10% of all systems cannot and, therefore, migrating a project to the cloud takes a lot of effort that can easily be overlooked. By using robust interfaces with these legacy systems, the risk posed by disjunction can be reduced. An example might be using a VPN connection between the cloud and the client’s own servers to create a connection between legacy and cloud systems.

Security issues

The well-publicised scepticism around security in the cloud and the problem of controlling access to cloud servers are issues that all service providers are working hard to overcome. Fundamentally the nature of cloud computing means the data from one consumer is often stored alongside the data of another. To some extent the challenge of confidentiality is being met through encryption, which is often used to segregate data-at-rest. However this is not a cure-all, and a thorough evaluation of the encryption systems used should always be undertaken. In addition, backup is not ‘out-of-the-box’.

Evolving fast to meet a growing need

Given the benefits we explored earlier in this series, and the challenges highlighted above , there is a clear role for experienced service providers with testing expertise and multiple technical skills, such as Sogeti and the Capgemini Group, to help clients adopt the most appropriate and relevant Cloud Testing roadmap.

For example, we have already developed a number of services that will enable client organizations to leverage the advantages of Testing on the Cloud and avoid any pitfalls.

These services include the provision of a suitable owned or shared test infrastructure for a range of test environments and test levels, such as performance testing as indicated above. In addition, we offer  SaaS or STaaS (Software Testing as a Service) with ‘pay as you go’ test tools.

For many enterprises, there is a significant cost and license commitment in using test management tools. However on the cloud, if a new project needs to use test tools for a short to medium term, these can be used (and paid for) when required and only then!

By utilizing Software in the Cloud, organizations can enjoy significant pricing benefits, not least because it becomes possible to more precisely judge the actual usage and pay according to use, rather than having annual fees.

We anticipate that clients will have a growing, on-going need for new specialist services that create real added-value through pay-as-you-go pricing models. So, if after reading through this series of blog posts, you have questions about the topic or feel that Sogeti could help you in testing on the cloud, please don’t hesitate to email us.

Sogeti and our partners, UNICOM are very pleased to announce that the much anticipated TestExpo™ 2013 will be taking place in London on Thursday 24^th October.

TestExpo™, the UK’s premier software testing event, is now in its 17^th year and we expect this year’s event to be the best yet, with lots of new, insightful content and ideas from leading industry experts.

The event was originally started as a way for Sogeti to contribute to the testing community through knowledge sharing and learning. Over the years TestExpo™ has grown into a highly valuable forum for debate, discussion and networking, and TestExpo™ 2013 promises to be a fantastically collaborative, informative and engaging event.

Following the feedback  that you – the delegates –  provided in the surveys we ran earlier this year, we now plan to introduce a number of structured break outs to provide our attendees with the opportunity to interact more, learn about joint opportunities and have their own say on the processes and tools they use.

On top of this, TestExpo™ 2013 will showcase all of the usual captivating keynotes, presentations and case studies which will be delivered by renowned thought leaders and experts in the field of testing.  Delegates will have the chance to view demos, discover new techniques, and find information on the latest Testing and Quality Assurance topics that impacting today’s businesses in the TestExpo™ exhibition.

Registrations for TestExpo™ 2013 are now open and, with an Early Bird discount available for bookings before 5^th July 2013, now is the perfect time to register for your place. Click here to find out more and register.

Stay tuned for more updates around sponsors, topics and what you can expect from TestExpo™ 2013!

We look forward to seeing you on 24^th October,

Sogeti UK

I was recently in a meeting where question of the agility of a supplier came up. The discussion quickly reached an impasse as we struggled to reach an agreement on whether or not the supplier could actually be classified as ‘agile’. The reason for this dispute is, I feel, interesting enough to prompt this blog.

So what caused the disagreement? Well essentially it came down to different views on the ‘meaning’ of Agile.

I accepted the supplier as agile because during a previous meeting with them we had discussed working processes, and I had found their attitude and approach embraced the values in the Agile Manifesto. My colleague, on the other hand, would not accept them as agile because the working processes did not match those that he associated with agile; to him agility was defined by a set of processes, while to me agility was defined by the attitude of the people involved.

 This difference can be clearly seen in considering the question in my mind: ‘Could you have an agile waterfall project?’ To my colleague, the idea of an agile waterfall project is as much of an oxymoron as that of a solid liquid. To me there is no rational argument for regarding this as an oxymoron and I see no barrier to having a waterall project done in an agile way.

So what is my argument for viewing agile as attitudinal rather than procedural?  Looking first at the agile manifesto we see agility expressed as a set of values, and not as a set of processes, and the supporting twelve principals are expressed not in terms of prescriptive processes, but in the ways of behaving whilst executing a process. Across all of these values and principles, the only one that really seems incompatible with using the v-model is that of delivering working software frequently; and it seems a weak argument to argue that the v-model is incompatible with agile working on just these grounds.

It appears that the desire to define agility in terms of process has nothing to do with the principles of agile software development. The first value in the agile manifesto is that individuals and interactions are valued over processes and tools, and to define agility in terms of processes is therefore highly contradictory. To consider where this idea comes from let us look at all the right hand elements in the agile values – they are all focussed on removing uncertainty; or, in reality, creating the illusion of removing the uncertainty (borne out by the history of IT project failures). It seems that what sets agile apart is the willingness to not just live with uncertainty, but to turn this uncertainty into an asset. After all, an approach that anticipates uncertainty must be inherently flexible.

Now a team may be using a set of processes and tools associated with agile working (such as SCRUM, Kanban or TDD which are useful tools and processes), but following these processes and using these tools does not mean that you are working in an agile manner any more than playing a musical instrument means that you are playing in a creative manner. Using tools developed by the agile community with an attitude that seeks certainty will make them as inflexible and ineffective as the tools they were intended to replace.

Conversely using v-model processes and tools while applying an agile mind-set will expose in them unexpected flexibility. Working with the v-model does not require heavier documentation, tighter contracts, or more rigid plans than working in SCRUM, nor does it require you to value processes over people. Such things are the product of fear of uncertainty and the risks associated with it, and fear will stifle a SCRUM project just as readily as a v-model project.

When it comes down to the wire the benefits of agile software development come not from which tools and processes you use, but from the attitude of the people involved.

Keen to learn more about testing within an Agile approach? Register now for our webinar on 3^rd July, where we will be discussing how testing should be regarded as an integral part of the Agile development process to support the project team in delivering on time, on quality and to budget. Find out more and register.

In the sixth in our series about testing on the cloud, we’re taking a look at test environment delivery scenarios.

Test Environment delivery scenarios

We have outlined below possible scenarios which organisations can choose from when picking the most appropriate test environment and test tooling  from the cloud.

Test scenarios

• Private IT Vendor Cloud for Managed Testing Services: With a wide range services necessary in a Managed Testing Service, the capabilities of this infrastructure need to be flexible and scalable whether on or off-premise, or global or local (according to data management regulations). Clouds can be created with their own server parks, in which the server is divided sbetween the different projects when those projects need the capacity, creating a more flexible server organisation. The clients (test) data will reside outside its premises, on the test cloud.

• Private or Hybrid Cloud at Company’s own locations: Using existing owned infrastructure and maintaining a high level of control by keeping it on-site, this a relatively risk-averse option. Keeping test data and applications on site, it offers more than test infrastructure, opening up other cloud computing options.

• Hybrid Cloud offered by IT providers and serviced by IT vendors: Outside the client’s firewall, clients use the IaaS from a partner company to build Development and Test clouds available only for them, which are then managed by IT vendors for the client. Such clouds offer flexibility to increase or decrease capacity as required.

Test Tooling from the Cloud

SaaS offers great value in using test tools from a cloud environment, recognizing the dilemma of cost and license commitment that many organizations face when wanting to use test tools.

Test tooling from the cloud provides a quick and efficient service-based solution. Test teams can purchase ‘on demand’ (or by subscription model) the download and subsequent use of these tools, hosted on the cloud, as and when they are required for a specific project or program.

Whenever a new project needs to employ specific test tools for a short to medium amount of time, cloud-based test tools can be used. In addition to the benefits of greater flexibility in tool usage, there is also minimal investment or reduction in license fees, and the elimination of ongoing tools maintenance further increases cost savings.

In this way, the cost of tools is reduced because it is better aligned with actual usage, availability is immediate, and by using the tool consistently over a group of projects, increased standardisation and a quality management ethos is embedded.

If you’ve been keeping up with our Testing on the Cloud series, you should have a good idea of where to start, and be aware which type of cloud and test environment would work best for your business. Next week, the last in this series, we’ll close with a deeper dive into the operational challenges behind software testing on the cloud.

Sogeti’s trend lab, VINT, recently released the third report from our four-part Big Data research series, which aims to put visions into perspective and create clarity around the use of Big Data.

The third report, published on 9th April, moves on from the definitions and uses for Big Data which were explored in Report 1, and goes beyond the deeper social analytics and behavioural predictions discussed in Report 2, to arrive at perhaps a much more prudent and current topic: how to benefit from these fantastic opportunities without breaching privacy , or losing the trust of your customers.

“Privacy, Technology and the Law” addresses the idea that current privacy legislation is falling short and becoming inadequate as it is quickly outpaced by Big Data technologies. The explosive growth of digital personal data is enabling organisations to better monitor and predict people’s behaviour all the time, and as Big Data and its applications increase in capability, there is also an increased pressure on the privacy and protection of data. VINT contends that, with a good balance between corporate and individual interests, everyone can reap the benefits of Big Data.

Menno Van Doorn, co-author said on the topic of data privacy: “Any organisation which uses the currency of personal data must be one-hundred-percent transparent and able to protect it. It is not only consumers who are undereducated on the kind of privacy-sensitive information that is distilled from Big Data and its predictions”.

The report elaborates on the work of Ann Cavoukian, the Canadian Information and Privacy Commissioner, and offers seven recommendations for data-driven organisations to avoid issues with breaches of privacy, and to personal data in a responsible manner from the start. The recommendations are as follows:

1. Privacy-by-Design: The organisation should work proactively and preventatively. Before collecting data, the organisation should first decide on the conditions of collection and data use which must be met along the way – in other words, don’t wait until you are sued for breach of privacy!
2. Make the guarantee of privacy the default setting: Ensure that maximum privacy is set and guaranteed from the off, so that individuals don’t need to worry about the protection of their privacy
3. Integrate privacy in the design of IT systems: Make privacy standards part of the design and architecture, and in the requirements from the start of the development of each application. Privacy should be an essential component of functionality.
4. Full functionality in relation to privacy: Avoid false contradictions such as privacy vs. security. Organisations must show that the two can co-exist.
5. End-to-end security across time: Store all data securely at the end of the process, or destroy it at a chosen time.
6. Transparency is key: It must be clear to all stakeholders what happens to their personal data. Anyone who wants to find out how their information is being used should be able to do so easily, anywhere and at any time.
7. Treat the privacy of individuals with respect: organisations must ensure that the interaction with their stakeholders is good, and should explain clearly and simply what is happening to build a relationship of trust.

This report is available to download here, along with its two predecessors “Creating Clarity with Big Data”, and “Big Social: Predicting behaviour with Big Data”.

Look out for the next report in the series which will be available in the coming months, and will put forward a Big Data Business Roadmap focussing on the practical application of Big Data and analytics.