blog

Let's talk about testing

The new way of testing

This week, Hozan Said, our new Business Development Manager, talks about his impression of spriteCloud’s working culture.

I joined spriteCloud at the beginning of June and my first impression was really positive. The team wanted to make me feel at home. During the day, the CEO and COO and my new colleagues asked me several times if I was doing well and if I needed anything. It was an amazing environment. What attracted my attention was the mentality: work hard, play hard. Everybody has so much fun together, but they work hard too, so it doesn’t impact the quality of what they do. On the first day, we had lunch together, played table football, and tried out the VR stuff that we are testing. A whole new world was opening up for me! It was amazing to see how much freedom everybody gets, and that there is no hierarchy. They told me from the first day: “Please try new things, don’t be scared. If you fail, you fail and you learn. If you get good results, you will get a nice commission.”

Continue Reading »

An internship at spriteCloud

This entry is part 5 of 5 in the series Recruitment

We’re hearing from spriteCloud’s Commercial team again this week. Our new Marketing Intern, Rebecca Hogg, talks about what she has learned in her first month.

Learning the value of software testing

When I joined spriteCloud a little under one month ago, I was a total beginner when it came to software testing. The concept is seemingly easy to explain, but as I’ve learned, it goes much deeper. For example, did you know how many different things you can test when it comes to software? spriteCloud provides services such as functional testing, test automation, performance and load testing and mobile testing, and it doesn’t stop there. I knew software was complicated, but this is a real specialty. I’m still only scratching the surface when it comes to fully understanding what software testing is, but what I have learned has taught me that testing is a vital step in the software development life cycle.

Continue Reading »

‘Our biggest competitor is the option to not test at all’

This week, our Business Development Manager talks about the benefits of spriteCloud’s approach to software testing.

14 months ago, I joined spriteCloud as a ‘rookie’ in the software testing world. After being rapidly pumped full of information and presentations, the first customer visits presented themselves. After my first meetings with the responsible managers, it was clear that spriteCloud was offering something special. Even this non-technical business guy now knows the added value of external testing.

spriteCloud is a great company to work for in general, with short lines and creative business ideas that can be implemented a month after being brought up. It is an excellent environment for somebody new in the business. After my first few months as the sales guy for spriteCloud, it hit me that most of our clients found us through word-of-mouth, so our service was selling itself…

We need to conquer the world with spriteCloud

Nonetheless, like every company, we want to expand, or as our management team puts it: we need to conquer the world with spriteCloud! Therefore, we needed to listen more to the companies that we were serving, plus we needed to convince other companies why testing is so important for them. We needed to spread the spriteCloud message: Test your software, not your reputation! And so we did. Soon we found out that our service was very specialized and our market segment in the digital world was already strongly represented: the foundation was there, ready to expand! Testing for creative agencies on a project basis – a popular service we provide – is still pretty unique, especially with the flexibility that we offer as a service provider. We prefer software testing on-demand, without any tremendously long discussions about the scope of the project or pricing models, providing ad-hoc solutions by working together with the client.

Continue Reading »

Gonzo QA: Fear and Loathing at Scrum Day Europe 2014 (part 2)

This entry is part 2 of 2 in the series Gonzo QA: Fear and Loathing at Scrum Day Europe 2014

A savage journey to the heart of evidence-based management for software organizations in 1,000 words or less

Dateline: 3 July 2014, Amsterdam

(Read part 1.)

Lunch-time sandwiches behind me, Forrester’s Diego lo Giudice’s Keynote: The State of Scaling Agile In The Age of The Customer roared into life in the ‘Grote zaal’. Sporting a sharp goatee and an even sharper suit, Diego started talking at 160 words per minute. Having warmed up on his introductory slides, he passed 250 words per minute on slide 4 and was soon speaking at speeds exceeding the limit of normal human comprehension, around 500 words per minute. Facts and figures filled the air. Nobody moved for fear of getting hit. Towards the middle of the presentation, smoke was clearly visible coming from the left hand side vent of his jacket. ‘*’-uniformed roadies immediately appeared on the stage and sprayed his torso with a thick coat of fire-retardant foam, allowing him to continue to present uninterrupted. Diego’s 27,500 word presentation finished without warning to deafening silence followed by thunderous applause. There was 5 minutes left for questions but we knew we had just witnessed a tour de force and there was nothing left to say.

Continue Reading »

Gonzo QA: Fear and Loathing at Scrum Day Europe 2014 (part 1)

This entry is part 1 of 2 in the series Gonzo QA: Fear and Loathing at Scrum Day Europe 2014

A savage journey to the heart of evidence-based management for software organizations in 1,000 words or less

Dateline: 3 July 2014, Amsterdam

I approached Scrum Day Europe with a mixture of excitement and trepidation. Ken Schwaber was giving the opening and closing keynote speeches. Ken Schwaber! Ken co-developed the Scrum process and signed the Agile Manifesto. He founded the Agile Alliance, Scrum Alliance and Scrum.org and I was going to hear him speak. Would the first row of seats be reserved for acolytes dressed in white robes? Would the audience chant his name? Would there be fruit juice to drink at the end? The man who wrote ‘Scrum’s roles, artefacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum,’ does not sound tolerant of dissenters.

Continue Reading »

What’s the real value in QA for cloud consumer services?

I got to thinking about this – again for the umpteenth time – during an informal lunch conversation with a group of developers and QA’ers discussing challenges in their jobs. This friend of mine, who is a very senior individual at his social network startup, was telling us a story about the problems that he has with a group of external developers who build their service. They tend to be a bit like a group of cowboys that shoot code from the hip without thinking through what they are doing, or with much regard for what effect this has on the production environment. I said to him that it sounded like a recipe for disaster and asked if this resulted in a lot of catastrophic failures like their site going down. Surprisingly he answered, not really.

Their situation is they don’t have a dedicated QA group or tester to run regression tests on builds that come out. This is done by someone on their management team who has an intimate knowledge of their front-end application, and he manages to catch the really bad problems before they make it to production. I asked if this was always the case, to which my friend said, not all the time but generally. He went on to relate to me that one of the good things about them being a cloud service was that they could patch problems on the fly if they had to.

I agreed, in quite a few of the places I worked in, patching-on-the-fly was a standard tactic for fixing post deployment problems. But it’s time consuming for all the individuals that are involved, which if it turns out to be a lengthy issue to fix means time off core development work. If you’re doing releases every week, then this can add up to a significant amount of hours, all of which has to be paid for, either in people having to do more hours to meet development schedules, or development schedules being pushed back. In a worst case scenario, it’s both. The end result, your service delivery starts slowing down.

I’ve mentioned nothing about the aggravation that your users experience, but this is not really as serious I don’t think. After all users are a bit like young kids, they are easily upset, but they are also easily placated. As long as you fix things in a hurry and don’t make them wait too long to be able to get back to doing what they were doing, they will forgive you. It will even give them something to twitter about. I survived when my social network service when down for two hours… I read a BOOK! Which can give you enough infamy to get your name out there if you’re new. To be fair though, there is a line-in-the-sand to a users acceptance of failure, it’s different for each service, but once you cross it, users will start to chant your name in angry denunciation. This is bad because it soon follows that they go somewhere else. Typically once you’ve burned a user badly enough, they are never coming back.

I don’t generally put user satisfaction into a QA benefit for the modern world anymore. Even the most technically minded, and thus socially unaware software developer, keenly understands that user satisfaction is everything. It’s the one true deciding factor in whether an online consumer service lives or dies. This doesn’t need to be explained, everyone just gets it. Time however is something else. While everyone in a development group understands that time is of critical importance, you’d be hard pressed to get agreement on what’s the best way to use it. There are hundreds of documented ways to structure a project to -1- organise teams, and -2- organise development activities to achieve milestones. But the goal is always one thing; to build an application that consumers can use – and someone can make money from – in the shortest possible time.

For development, the real benefit in QA is in making things happen in “the shortest possible time”!

There is a time hit involved with getting a bunch of QA/test people involved on a project as they need time to make test cycles on builds. But if they are involved early enough, it means that they catch the bad problems before they become really bad problems. The worst kind of problems are those that take your site down. Once that happens, every manager and his team gets involved to work the issue until it’s resolved. If you’re lucky it’s a few minutes, if not, then the hours start stacking up.

While there are models for software development that are based around code going straight from development to production, it’s a theory I’ve never seen work in the real world. That’s not to say it can’t, it’s just to say I’ve never seen it happen. Eventually code going from development directly to production breaks production and chaos ensues. People are pulled off their core work to fix issues. The end result being lost time.

The goal then for any QA group is to structure itself in the most effective way to facilitate the rapid flow of work from development and turn it around through a series of test activities (cycles) so it can be deployed to production in the shortest possible time. I’ll be talking about this in more detail the posts to come.

Andy.

Reputation. Meet spriteCloud

Find out today why startups, SMBs, enterprises, brands, digital agencies, e-commerce, and mobile clients turn to spriteCloud to help improve their customer experiences. And their reputation. With complete range of QA services, we provide a full service that includes test planning, functional testing, test automation, performance testing, consultancy, mobile testing, and security testing. We even have a test lab — open to all our clients to use — with a full range of devices and platforms.

Discover how our process can boost your reputation.