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 »

The zombie Scrum apocalypse is upon us!

A couple of weeks ago, I met them. In real life. Scrum zombies! It was at Scrum day Europe 2016. Scrum day is not their natural habitat, they were brought in by two highly skilled Scrum zombie fighters as examples of what can happen when you are touched by the Scrum zombie virus. The zombies were examples shown in the workshop, ‘How do we survive the zombie Scrum apocalypse’ by Johannes Schartau and Christiaan Verwijs. I am going to summarize their workshop and then elaborate a bit more of what I think is the role of the tester in fighting the zombie Scrum apocalypse. For a more detailed view on zombie Scrum, please check their blog.

What exactly is the zombie Scrum apocalypse? And more important; am I already a zombie, maybe even without knowing it? The main problem with zombie Scrum is that it looks like Scrum; the team consists of a Product Owner, Scrum master and a Development Team. They follow the Scrum events; they work in sprints, do sprint plannings, have a daily scrum, sprint review and a sprint retrospective. They have the Scrum artifacts. But they are missing out on the purpose of their work; they don’t seem to deliver working software at the end of the sprint. They miss out on what is the core of Scrum.

Of course, there are other symptoms. Zombie Scrum teams desire no contact with the outside world; they don’t want to get involved with their customers, they don’t care if their poorly built application breaks the end-users machine. They did their job; delivering code. QA failed to catch the bugs, design failed to create a nice look. Not their fault! Whether or not their sprint succeeds or fails, the zombie Scrum team is not affected by it. They don’t try to improve, they just sink in the swamp they created for themselves. They become numb. In a worst case scenario, the Product Owner is absent most of the time, the Scrum master has multiple teams to take care of, developers are often being swapped between teams, so there is no stability. Zombie Scrum teams go through the motions of Scrum, but miss out on the fun in Scrum.

There are many causes of zombie Scrum. Probably the most well known cause (I guess we have seen it all) is the company that want to adapt this fancy new way of developing working software (#hype!). They rename the project manager to Scrum master, start to work in sprints, call the development team Scrum team and there you have it: the company is Scrum. The team slips in a non-productive way of acting-Scrum and starts showing above mentioned symptoms.
Another cause may be the lack of urgency zombie Scrum teams feel. They don’t feel the urgency to connect with their customers to deliver valued, working software. They don’t feel the urgency to learn from their mistakes. Every situation is different however, so take a moment to think about other possible causes of zombie Scrum.

So, having read all this and getting a little depressed by the fact you recognise some of the symptoms; what are we going to do about his? And, for me as a tester, what can I do? How can I contribute to healthy Scrum? As a tester, you are usually working in close collaboration with the developers and the product owner. Talk to them about quality and the importance of delivering working software. Help the product owner by testing his requirements beforehand. Clear requirements will help the developers build working software within the sprint.
Personally, I think the most important way of improving the way your Scrum team works is by talking about what you are building and how you are building it. Talk about your definition of ‘done’. If your team doesn’t have one, try to establish one. Make sure quality assurance is an important part of it. When you are testing, make sure to check if the definition of done is met. If not, discuss your findings with your developers; how can we make sure the software meets the definition of done and we can meet the goal of Scrum; deliver working software every sprint.

There are more ways of improving your Scrum team as a tester, but most of them come down to communication. Communicate with your team about the process and about how you contribute to the sprint goal. Raise your voice in the retrospective. Talk about the purpose of Scrum and make sure you are contributing to it.

If you think you are in a zombie Scrum team, don’t get depressed. Show your team that when you improve, there is fun in Scrum!

The Rising Recognition of Software QA

Tech blogger Kris Köhntopp was interviewed by the German language PHP magazin on his Google+ post on the Heartbleed bug. I’m not going to comment on the interview much, except to mention it’s title:

Qualitätssicherung bei Software ist alles andere als ein gelöstes Problem

Or, in English:

Quality Assurance in software is anything but a solved problem

Well, he’s right. The problem isn’t of course that we don’t have tools and processes to deal with QA. The problem he refers to is that those tools and processes rarely encompass all software any given business relies on.

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.