Testing: More Creative Than You May Think

 

When we think about the term 'creativity', you may think of crayons, pens, paints, music studios and notepads among other things. Testing may not be what you would think of as being creative however, in this post I attempt to make the case that Testing can be one of the most creative roles one could have and I also respond to criticisms in relation to the 'robotic' nature of the role. 

Testing by its very nature demands creativity. Any passionate Tester will have thought about the different ways they can approach the application they are testing. They would have traversed off into the unknown crevices of the code, just wondering what could possibly be waiting for them. A mind filled with 'what-ifs and 'ooo what was that?' type of questions. Wearing different hats, looking at things from the end users perspective, considering the business objectives and just exploring the thing tested, learning and taking notes. Trying to figure out who they need to speak to in order get specific information. This is all part of Testing and requires a lot of creativity.

Often times however, Testers are not empowered. We are only ever reminded of our responsibility when bugs are found in production and things go wrong. The famous "well, who tested it?" line echoes in the minds of those that have been at the end of pointing fingers. Alternatively, we may never get the blame for anything or be even noticed at all, but have been reduced to running test cases written by somebody else, that read like they have been intended for a robot. Managers often want to see nice reports with big shiny green ticks next to each test - shiny ticks of course here mean, the application has ZERO BUGS and is in perfect working order! (I hope you could sense the sarcasm there). Testers are not robots. In environments like these, Testers cannot thrive, and I'd argue that they do not belong in them either. 

So, what is the reason for this post and why am I writing about creativity? As Testers we are neither business analysts nor developers. We are not dealing with the end customer directly, and we are also not fixing any bugs. We're kind of in the middle somewhere. Although I'd say that actually we're more 'around the outside' of all these processes as opposed to in the middle somewhere. If you're not a Tester, I know what you're thinking: .."Testers.. Creative?! Ha! How hard could it be?!" - we don't have a great rep. Or a rep at all sometimes. We're just somehow there in the shadows clicking buttons making sure things work - right? ... No! 

Back to my reason for this post; well, I stumbled across a comment online in response to somebody asking how successful they could be if they did freelance work as a QA/Tester, because they loved travelling but of course needed to make some money to get by.

The replies in the thread, in general were quite negative and this particular one, need I say, made me quite sad... 😞  (<-- sad James)

Here it is below:

"QA Sucks. Convert to a creative job asap while you are young..."

Uff..

Powerful stuff. 

I was sad because though I strongly disagree with this, I am going to assume that this person is speaking from experience and I felt bad for them. I have to admit, I have been on projects that have made me question my career choices however, upon reflection that's never really been because I am a Tester. It's usually down to flaws in processes or gaps in planning on the project. 

My response to the comment above is firstly, I have to point out that they have mentioned 'e-commerce' as a creative alternative. Hmm, I don't think we need to provide any arguments against that suggestion, but to address the programming/coding-related options listed as alternatives; I'd say that the majority of the time developers are faced with the problem of the client dictating how the thing you are building needs to behave, look and function. A Product Owner or Project Manager may not give you the option of HOW to come up with a solution, though they may mention 'yeah sure, build it however you wish but just make sure it does this thing exactly as I have described'... basically, 'you can pick any colour as long as it's red'..

Even the developers that freelance are still at the mercy of the client's wants and needs. Many developers do build their own solutions to problems via new applications or starting their own companies and that is great. Creativity thrives here I'm sure. But a lot of companies treat developers as 'resources'. The companies want something and the developers have the skills to build it so do as they say. (By the way, if you are in a company that present you with their requirements but give you complete freedom in how to build it, then stay!)

To summarise my response, programming/coding is very creative but within a context. Testing is the same, however there is less restriction on how we can perform or role because there isn't really a Testing deliverable as a product. This allows us some more room for creativity in my opinion. No client can EVER really tell you how to test, no Manager or business owner. They can contribute and advise but we have to maintain ownership of our Testing and the way we go about doing it. More specifically with clients, all they can really do is tell you want they want and how they want that thing to work. Testers try to ensure those things happen but at no point are told how to do what they do. We do however report on what we do, and should do so in a detailed yet clear way, whether that be via a detailed report on your findings or communicating them effectively to your colleagues/stake holders. Prior to this stage, our creativity is stretched as far as we allow it to be.

Using a search field as an example, the process of building it (or other features) at a high level, is usually:

Client wants a search field (or X feature) -> client tells Business -> Business tells Managers -> Managers tell Developers -> Developers build it -> build gets tested -> released to client

Now, throughout this entire phase we as Testers are involved, learning throughout the entire process. By the time it has been built, we have learnt as much as we possibly can about the context and all the complexities that by the time we actually physically test it we are able to explore the many possibilities. We aren't just going to check that the search field is present, we would explore the application addressing some questions like:

- Location of the search field. The client really needs this thing so is it easily accessible? (we can check this on numerous devices, what about devices that auto zoom into text fields? etc)

- Does it auto-populate results to help with long/complex terms? (can help us determine if it's javascript returning the results or at server level - we can then explore various changes/tests utilising the browser console)

- What results are returned? - Exploring data validation

- What is the source for the information that is returned? Can I access this source by some data injections? can I access server through various methods/attempts

- Should all this information be visible to me? Is there any legislation in the business domain that dictates this? Can I identify values in data which are anonymised? 

These are just a few questions, coupled with what we learn during our testing that guide our testing journey on the application. This is part of testing and this demands creativity.

The client never asks for what we test in detail, but we do it because our role as a Tester requires us to get creative. It's like detective work. Again, we wouldn't immediately think of detective work when thinking about creativity. 

It is not rare to find Testers pushing their limits with their creativity. Their ideas often push them to go off and learn new programming languages, tools and even build new relationships. Beautiful things happen when people are allowed to be creative, and Testing is no different.

So, no, QA doesn't suck and IS VERY creative, just like many other tech roles, but only IF you are providing your services to people that value your human abilities, as opposed to wanting robots doing their 'testing' *Cough* automation overkill *cough*

If you agree or disagree with anything I have mentioned in this post, please feel free to reach out to me on Twitter @webtesthub - I'd be happy to discuss. My views are only based upon my experience and are always subject to change! 

Read More

Moving into an Agile Environment

 

Moving into an Agile environment for the first time can be quite daunting – at least for me it was. In this post, I’ll be briefly touching on my experience moving roles into a company that adopts the Agile methodology for developing software. I’ll mention some of the things that really took me by surprise and will be comparing some of the processes and workflows against what I have previously experienced in other roles. 

The term ‘Agile’ is used very loosely and not all companies that claim to be Agile, are actually Agile in their approach to getting things done. There is also very little that is set in stone with regards to this methodology as it is by its very nature adaptive and ever-moving with the aim of continuous improvement. For this reason, one could read up on the subject and become either confused or cautious when considering adopting Agile or moving into an Agile environment. 

This was my experience. I had done a lot of reading up on the subject before starting my most recent role and could only previously define Agile by the vague principles listed here in the Agile manifesto: https://agilemanifesto.org/principles.html

That means, when asked in interviews or speaking about Agile in public forums I would parrot buzz words or buzz phrases (is that a thing?) such as “satisfying the customer”, “working closely with the customer”, “close collaboration with stakeholders” – the thing is, these things can be done in a waterfall approach to things. So in my opinion, Although Agile contains just a few core principles, its main value becomes apparent when people adopt those principles and actually start working that way.

What I mean is that companies/people will all ‘do’ Agile differently but will all have those basic principles at their core. So to address the title of this post, moving into an Agile environment is not really something you can prepare for to a great extent because it is implemented in different ways at different places, and often employers have their own interpretation of how they should get things done.

I had always thought my previous experience in companies was quite Agile, in that we worked closely with the business analysts and clients, oh and we also had stand ups every morning! Come on, this is as Agile as you can get! … or is it?

I think Agile is quite a natural approach to software development, especially for us Testers. All those test cases produced early on, only to have the client change their mind AFTER the application or feature has been tested… the pain..

To come back to my experience in my previous role, which was totally Agile (I thought), I felt after 6 years it was time to move on and explore new opportunities and the companies that I was applying to were all saying they were looking for Testers who understand what Agile is and have experience testing in an Agile environment. All good with me. I just pulled out some buzz words from the memory bank and was able to pass the phone interview. I had no idea how much I didn’t know until I started in my recent role.

Cross-functional teams and collaboration:

At my current place of work, they are Agile to the core so my transition was quite a shock to the system. The first difference I noticed when I joined was the arrangement of the teams. In my experience I have been part of a ‘testing team’, in that we sat separate from the developers (close by, but separate desks). We also sat separate from our product owners, business analysts and project managers. The setup at my current place of work is that we have what could be called ‘Agile teams’, which are essentially groups of people of different roles, working towards one vision in relation to what they are developing/working on. So when I joined, in my team we had another Tester, 4/5 developers, a tech lead, a principal engineer, a product owner and an Agile lead. We all sit together (although, COVID has obviously prevented this – Slack and Google hangouts will just have to do in the meantime) and we all discuss openly and work closely together. Each team in the company has their specific area of focus in relation to our application so there is also a lot of collaboration with the other teams also.

Breaking work into small chunks:

So the basic setup of a team was the first initial surprise. Secondly, I noticed the work was allocated via tickets. I have had previous experience with more feature-based releases or ‘Big Bang’ releases, meaning that the client wants X feature, we go away and build it, test it, then release the feature as a whole in one big release, usually out of working hours, so testers and devs staying back after work finishes. The work in my current role is split into small chunks and is released during and over two-week cycles. Going by what I have read and speaking to other testers in the community this seems to be the standard when it comes to an Agile approach to building software, however this was my first time experiencing this. My testing habits are greatly affected already by just these first two changes in environment, because I found myself apologising a lot when asking the other devs questions – previously devs would sit separately with headphones in working away. But here, everyone is well aware we are all about collaboration so barriers are not up in that way. Yes the headphones are on at times, but everyone knows the deal here so they expect discussions to start at any second. I no longer feel I have to apologise when I want to ask a question or starts a discussion on what I am working on. Now what I will say is I am not sure if this is a direct result of a company adopting the Agile mindset or down to the great culture at the company (it could be both) but it is certainly stressed in the Agile manifesto nonetheless.

The other way my testing habits were changed is that there is more control from the team as a whole over what goes into our application. As a tester I am getting much more of a say in setting the acceptance criteria on a chunk of work that comes in, way before it is even developed. Additionally, as the work is in small chunks, the scope of testing is more focused. We focus mainly on the acceptance criteria of what is being built, and also timebox our exploratory testing around the code that is introduced – and then run some basic sanity checks on the application with the help of automation to ensure nothing else has been broken. This assurance is then doubled by the fact all other teams are using the same code base and are deploying to production numerous times throughout the day, so we are constantly conducting sanity tests when testing our work.

Additionally, as mentioned above, we are deploying numerous times to production throughout the day so delivery as a whole is completely different to what I’ve experienced. I believe the term is, “continuous integration” (CI/CD) – basically deploying to one shared code base, numerous times throughout the day. This means no staying late, organising and scheduling a team to stay back after office hours after each release to ensure the release has deployed fine. The only time some of the team have had to work out of hours was when we had won a contract with a client overseas whose weekends start on Sundays. This approach to delivery also means we can rollback super quick, as well as release things to customers more quickly and efficiently. Happy clients, happy team. 

Inspecting and adapting:

The last thing I’d like to mention that really caught me by surprise, and was something I’d never had experienced before were the retrospective meetings, or ‘retros’. These are meetings with your team, led by the Agile Lead in which the team reviews the previous ‘sprint’ (usually a 2 week period in which a feature is worked on, or an agreed amount of work) and the team discuss the things they thought did not work, and the things they enjoyed and also things we should try in the next sprint! I had only attended meetings where previous work is reviewed i.e. if there had been any major bugs found – pretty much a lessons learned type of meeting. So these retros are really good if they are controlled and confined within the aims of continuous growth. In my first retro, I thought I had joined some type of post-mortem meeting where something had gone wrong because I started to hear for the first time, a team mentioning the things they were not happy with. These are very refreshing meetings if done correctly i.e. without any actions agreed on how to improve moving forward.

So to summarise, the following 4 things were very different for me and I had to adapt to them:

1. Team setup (different roles working together VS teamed up with others in the same role but on different projects)

2. Work flow (tickets in small chunks VS Big Bang feature releases)

3. Work flow pt.2 (collaboration throughout development VS testing when receiving the end of the build)

4. Continuous improvement (retro meetings, proactive approach VS reactive meetings, meeting only after issues are found) 

Moving into Agile sounds like a huge change, and to be honest it is. It can be intimidating when you are actually doing it for the first time however, the results if implemented correctly are great and work better for everyone. You have to really question the principles in order to really adopt them; only when you really believe in them can you actually work towards great outcomes. I had my gripes at first but I am happy to say, my experiences with Agile so far have been great. I have a few questions myself around certain aspects of it, which I am sure there are answers to but at the end of the day, the most important thing is always improving. If another methodology pops up on the scene, and I believe it to be the best possible way to get things done, I would ditch Agile and jump in head first. This would also be something that the creators of the Agile manifesto would also welcome because that’s what they encourage. As long as it is the best way to get things done in-house and for customers then let’s do it.

This is the key takeaway I’d like a reader to walk away with; we should embrace change for the better. We should always scrutinise what we are doing and the ways we work, in the hope to find ways we can improve. If you are not doing things according to the Agile methodology, but things are working for you, then that’s great too. As long as we always scrutinise and look for ways to improve. With that said, I’d definitely say based on my experience so far, that for testers the Agile approach works so much better, for the reasons listed above and many more. I’ll be exploring the benefits of Agile VS waterfall in my next post where I also hope to scrutinise why and how things do and don’t work according to what I have come to know so far. 

I hope this post has been somewhat beneficial and I have tried to reflect my experiences so far to the best of my ability. Reach out if you have any questions!

Read More

We are Testers, We Come in Peace

Testers can sometimes appear to be problematic in the software development process. The Project Manager is under pressure from Accounts to get a project delivered so that the money can come in, and there YOU are finding issues during testing and now the accounts team cannot invoice the customer when they initially planned to. 

Companies hire Testers to find issues before they get to production so this should come to no surprise however, due to gaps in processes often masked as being 'Agile', the pressure can build up and as us Testers are the last point of call before release, we can often seem to be the problem. There are many reasons for this issue coming up, from communication to the lack of understanding from other team members of what testers do. Regardless of the reason, it is vital to remember that Testers are on your side. Testers want to release software/applications of the highest quality containing the best user experience possible, which includes of course making sure the app does what it is supposed to do with the least amount of issues present in the app.

Why this topic? Recently I was involved in a project that was extremely complex. The application had many moving parts all working with each other. To top it off, there were also no requirements for the development of the application. The CEO saw a gap in the market and put the orders out. Development was quick for what it was, but in the stand ups I could sense the urgency and felt the pressure. 

It was then time to test the application. I produced my test plan beforehand so had my approach ready and did as much 'non functional' testing as possible before the application was deployed to test. During my testing I could see immediately that the application was rushed. It was riddled with UI issues. The data in the application was validated so no issues there and that was the main selling point of the application. I spent around two days doing some exploratory testing on it, and I'd note down every time there was an issue that needed further investigation. The rest of the week was spent investigating findings during the exploratory sessions and logging bugs.

The release date for the application was approaching so the CEO called a meeting to get an update on progress. PM: 'yes testing has now finished it looks like we are on track', Developer: 'There are issues raised but nothing major'....then an update from me, the Tester: 'The application has a lot of UI/UX issues present that really affect first impressions of the application. It isn't as intuitive as it can be, buttons don't work in places. I have a long list of all the issues I have found and I don't feel at this stage we can deliver the project for when you initially intended...'

**crickets**

All eyes on me. Some great updates there until the Tester spoke. The responses I received had me thinking two things...Firstly, I really have to sell testing and its value to the team, and ...I need to write a blog post about this. 

After feedback on my findings, they were dismissed and put on the project backlog because the main USP of the product was fine (which, by the way, you needed to interact with the UI to access). I then decided to reiterate the point to the team that, we are all working together to deliver a quality piece of software. We all want the users to love this product. We have to think about those things just as much as bringing the money in. Yes, they were mainly issues in relation to the UI but the user experience should never be underestimated. How many products are out there that do such complex things yet are just a pain to use!? It plays an even bigger role when you have other products doing the same thing.

Unfortunately, my 'we come in peace' speech fell on deaf ears and the issues I had found, minus one or two, were put on the product backlog. It's been demo'd to clients as far as I know, and... still hasn't sold. Is this because they didn't fix the issues I found? Maybe not, but there's fine line between rushing something out for the sake of some money. 

In agile environments, projects can move along so quickly that there are pressures that can arise. It is in these moments where companies must remember we are all a team, unified on the same goals. So when waiting to move that invoice out from the 'drafts' tab, just remember...We are Testers, we come in peace! 

Hope you enjoyed the read! PS, I'm a little more active on Twitter nowadays, so reach out if you like/disliked the post. 

All the best! 

@webtesthub

Read More

"So, What is Software Testing?" Software Testing Defined

In this post I explain the definition of Software Testing, what it is, what is isn't and then attempt to define what Software Testing is in my own words. "So, What is Software Testing?" Initially, in the early stages of my career, the answer to this question was not something I really thought about much. When I was studying for the ISTQB exam, I had no previous information or understanding on what Software Testing is and during the course we were given a high level, some-what technical definition in our course materials and at the time, the definition was gospel for me. It goes:

"The degree to which a component, system or process meets specified requirements and/or user/customer needs and expectations" (ISTQB Glossary, 2010 - the glossary has been updated since, here)

In short, testing detects, measures and improves software quality which is achieved via various processes and testing techniques/approaches.

I now knew what Testing was! Were anyone to ask me, I'd repeat the above, often sounding like a robotic parrot whilst doing so! I only started to really think about this when I started my first role as a Tester. The Project Manager would approach me and literally say, just do what you can to try to break the application. So my work environment started to shape my approach to testing. I'd now try to break applications. Data injections, load testing techniques and doing things that end users will never do. No doubt I had broken many applications working under this manager but I quickly realised, I was finding things on the applications that didn't necessarily work as they should BUT the system was not 'broken' by it. As an end user, am I most likely to get frustrated when I run a HUGE unrealistic query that doesn't return results OR when my surname is entered in a field on a sign up form, but doesn't carry over to my profile? 

Examples like these, show that Testers are not there to just break things. Had I only tried to break the application, I may have never raised those fundamental issues in relation to the end users' needs/expectations. 

Following this, I worked on another project which was the complete opposite. This time, the product met the specified requirements however, those requirements defined by the customer were FAR from quality, in fact they were poor. Detailed, yes, but the overall application they required, down to the appearance and functionality was quite bad and dated. How do I, as a Tester add to the overall quality of software? After all, this was one of the modules we had spent so much time on during the course. I'd scrutinise requirements and point out the potential issues but I would get the simple response 'It's what the client wants'. Other managers that I would come to work with later would encourage the feedback and relay this to the customer who would often agree and the documentation would then be updated retrospectively but before then, here I saw myself in another interesting situation, a Tester testing a piece of software with what are essentially, accepted faults in the application.

So we have two examples where I had to focus on two different spectrums of the Testing process. The first, I was told just try to break the application, which then dictated my testing approach, and the second example showed that Testing was overlooked in during the requirements stage. 

I mention these examples because I found that, though the definition of 'software testing' has the 'official ISTQB glossary' definition, over time my understanding of software testing through the various projects and teams I've worked with has shaped the definition to me personally. I say that to say, I have attempted to define Software Testing in my own words below, and I hope this helps you, the readers, in your roles/journeys as Testers:

Software Testing is the process of utilising an application, verifying it meets customer requirements by executing checks on what IS SEEN* and NOT SEEN** on the application under test.

*IS SEEN:

 - Front end functionality

 - Front end design

 - User Interface

 - User Experience

**NOT SEEN:

 - Requirements documentation

 - Back end/Server side

 - Back end/Databases

 - Back end/Source code

So, there you go. That's my definition of Software Testing which is SUBJECT TO CHANGE! I hope though, it still conveys that testing doesn't just begin once the application has been developed and it doesn't just mean you click buttons and try to break things. 

Thank you for reading! What do you think Software Testing is/isn't? 

All the best!

J Vickery

@webtesthub

Read More

Selenium IDE is back!

Selenium WebDriver creator, Simon Mavi Stewart (go tweet the legend here: @shs96c) has recently announced that the infamous Selenium IDE is making a return! He will be unveiling the new Selenium IDE November 14th via a webinar and you can attend by following: https://t.co/ivvfnEjC64

The Selenium IDE holds a dear place in my heart as I remember using it when I initially started to branch out into automation a few years back. I spent a good amount of time learning it and it really did play a big part in my development as a Tester. I wasn't very clued up in relation to automation (still learning) at that time and Selenium IDE was introduced to me by the lead Developer at the company I was working for. Looking back, I think he chose to introduce me to Selenium IDE because the learning curve wasn't as steep as it would have been had he introduced me to writing test scripts using Selenium WebDriver.

When it was then announced that Selenium IDE had been 'discontinued' my world fell apart for a few hours as this was my go-to for automation. With that said though, I'm thankful for this because it forced me to start learning how to automate tests using tools like STS and Pycharm utilising the Selenium WebDriver libraries.

I'm happy to see that it is making a come back and I do really feel it will help those that want to get into automation as well as add to the existing arsenal of tools we use as Testers. It will be interesting to see the different ways we can use this tool, which will be covered in the webinar above.

So, if you've never heard of Selenium IDE you might be asking yourself what it is.

Selenium IDE is a testing-framework which allows you to record, edit and playback tests on web applications automatically via a browser extension. For example, if you wanted to verify the functionality of a contact form or a registration form, this can be quite a tedious task when done manually. With Selenium IDE, you'd have this installed as a browser extension, open it, click record and fill out the form and submit. You'd then set the test pass criteria i.e, you tell the tool what to check to verify the test has passed. You can then play this test back over for the next time you need to verify the form submission.

I first used this on a healthcare application which required various information about a patient and their condition on separate tabs. So you'd have personal details on one tab, and all mandatory fields had to be complete before moving on to the next tab. There were about six tabs to go through before the user could sign up, so you could imagine how jarring it was to test different scenarios when adding profiles into the application! Oh the nostalgia. I can still hear the huffing and puffing now...

As mentioned above, there's a webinar on the 14th November and Simon will cover the purpose of using it and much more so go sign up!

Thank you for reading guys!

@webtesthub

Read More

Do Testers Need To Know How To Code?

Do Testers need to know how to code? 

A common question I’m sure. I’m also sure there are many opinions floating around in relation Testers and coding. My thoughts on this are directed towards the Tester who has just got into the industry and working on their craft. A Tester that doesn’t have a tonne of experience under his/her belt as they are the ones (as I did) most likely to ‘Google’ this question.

If you’ve stumbled across this post after a ‘Google’ search, that’s a great indication that you are thinking about things or at least exploring ways of potentially enhancing your skills as a Tester. When I Googled this topic around two years ago, it was under the context of ‘worry’ in an ever-changing industry. Am I up to scratch? All the Testers online seem to know so much about coding, a lot of technical terms used – a lot of which I don’t understand. If this is how you are feeling, honestly, do not stress it too much. As mentioned above, if you are reading this post after searching around online on the topic, this is a sign that you are a great Tester and are passionate about your craft.

So, with that said, I’d start my answer by first asking how would you define your role as a Tester? Are you verifying that an application does what it is supposed to do against some requirements documentation? Or are you looking at going into automating tests? White box testing etc?

The question of knowing how to code is answered off the back of those questions. ALL Testers however, SHOULD have a good knowledge of how the application they are testing works. I.E, what things/components affect other things/components. What does each component do? This will open so many more scenarios for you when preparing test cases, thus adding that extra layer of quality to the product being delivered.

Understanding how the components work in the application you are testing, can also help greatly when reporting bugs found. You will start to speak in a way that the developers understand. You can also help point them in the right direction for a fix. Additionally, knowing how the application works will also allow you to get an idea of what components of the application will be affected once this fix is deployed.

So, what am I saying? In my opinion, Testers do not need to know how to write code, but they need to know and be very familiar with the application they are testing. Sometimes this means you need not know the ins and outs of the language it’s developed in and other times it requires an understanding of this at the basic level. So it all depends on what you are testing. 

In my experience, up until automating our regression tests, I didn’t feel the need to know how to code. I simply verified the application was doing what it should be doing, based on requirements documentation. I would scrutinize the requirements, often finding issues in them, catching them early and when I’d draft my test cases I’d be exploring the various ways I could potentially break things in the applications, however that was limited to what the user would do, nothing too technical beyond that.

99% of my testing during the first 4 years as a tester (you can check how I started here), has been on web based applications which of course hugely influences my opinion on this matter. The value of the most successful application I was involved in centered around the data sets it used in the tool. In order to do the best job I could on the application I had to take a step back. No more basic login permission checks, submitting forms, checking fields etc. I took a step back, spoke to the developers. They mentioned the tool is built using java, and using x y and z data sets. I then spoke to the account manager for the product, to get and understanding of how the users use it and where the value is in the tool. I then concluded the value is in the data sets, and then began to learn about the data and get an in depth understanding of it. 

How is it, that my team found issues with the data and graphs after it had passed unit tests and validation by the analysts who are specialists in their languages? Those being SQL and Java. I believe personally that it is down to my team being more familiar with the tool. Again, as mentioned above, understanding the components and how they work together.

To conclude, in my humble opinion, which holds no weight at all in the industry, is that Testers do not need to know how to code but they need to be very familiar with the application they are testing which requires a process of thinking and assessing how the application works. Following this assessment, it may be that you need to learn/grasp the basics of a language such as Java, but even then, you don't need to walk away after as a Software Developer. You have to view the languages used for coding through the lenses of a Tester. You do not need to know how to code, but IF required, you should know how code works. 

With that said, there is one major factor that contributes to this issue. You may have read this article and thought 'but James, all of the jobs on the market are asking for experience using the various languages mentioned' - this is true. From my experience, the majority of the Testing jobs on the market demand that applicants have some experience using languages such as Java, Python etc. I think this is somewhat down to the fact that some employers don't actually really know what they are looking for in a Tester. Perhaps they assume that because their applications are built using X language, this means the applicant MUST be familiar with the language in order to do a great job. Again, do employers actually know what they want from a Tester?

My final words on this are, as a Tester, you want to be the best as you can be in your craft, so definitely invest some time in studying object orientated programming. This will give you a high level understanding of how programming/coding works, which can then be applied to various languages. The only real things that change between the languages are a few extra functions and the syntax used for those functions. 

I hope you enjoyed the post and I welcome any feedback you may have. You can contact me via twitter @webtesthub - come say hi!

All the best! 

@WebTestHub

Read More

How I Got Into Testing

"How did you become a Tester?"

A question I have had to answer many times, mostly after having tried to explain what I do in my role to a non-technical person. I have also been asked this in job interviews and so thought a fitting first post would be in relation to how I got into testing and became a full-time tester. 

Towards the end of 2012 I was working for a company doing basic administrative duties whilst considering my career options. I did not plan to get into the admin role and prior to this I was in university finishing off my access course to degree level education when the university fees increased in the UK. This happened on the exact year I had to apply for my degree, so of course I was unable to continue with university but had rent and other living expenses to pay for. I was really frustrated at the time and started looking for jobs to cover expenses. I then got a call for the admin role mentioned above and accepted the role. Back to the end of 2012 and the company I was working for had some serious financial issues and they had to let me go. As 2013 came in, I started to apply for roles again and I was offered a role as first line support administrator for a small start up company. The role involved answering calls and offering support for the web applications the company had developed/sold. A few months into the role and I soon started to receive a lot of support requests following product deployments in which customers would mention the aspects of the applications that had broken following a fix or maintenance/update. After a good few of the complaints, the Directors were discussing the need for getting a tester. I sat near the recruitment team and overheard them setting the requirements for the role. The Directors then asked me to run some basic checks/tests after each product release and raise any issues before the clients find them (risky, I know!)

I would then try to put myself in the end user's shoes and run some basic scenarios on the tools and would always find issues. I then started to research online, common issues found in web applications and tried to apply these techniques when testing the applications. I would send off my bug reports in the form of spreadsheets to the lead and only developer who would then fix them in production! 

Upon seeing my bug reports the Directors then offered me the role of a Tester in their company on the condition that I attended a Software Testing course and passed the exam, to become ISTQB qualified. I agreed and signed up to the next available course and purchased a book that would help prepare me for the course and exam. ('Software Testing: An ISTQB-ISEB Foundation Guide' which can be found on Amazon)

The course took place over the duration of three days with there being an exam on the third day. I found the course to be excellent for me as it covered the basics of testing and really helped develop the mindset I should have for testing, as well as basic principles. Unfortunately due to the size of the company I was working at, and the nature of the products developed there, I would say about 60% of the theory in the book would not be applied at the workplace however, with that said I did pass the exam on the third day and was very happy, and ready to pursue my new role as a tester. I worked for this company for around 7 years and brought a lot of the principles of testing into the company, changing/amending existing processes, bringing testing as a key part of the delivery process. It took time, and a relatively lengthy company presentation to change the thoughts and ideas in the company but I enjoyed every moment of it. I can honestly say I really enjoy what I do. The company had also hired an apprentice in 2015 and I trained him up from scratch and now he has moved on to better things as a, you guessed it, Software Tester! Even though he originally joined as an IT apprentice! Something I am very proud of.

Since then, I joined a larger company, which had around 50+ testers. They were a much larger company and worked closer to the Agile/Continuous Integration workflows. It was during this role I started to change a few of my opinions on specific aspects of testing such as the need/importance of test plans, test cases and test automation (end to end testing). Those opinions will of course be published and each of my posts is definitely subject to change.

Moving forward, I am immersing myself into the community more, and with some great help from coaches such as Matthew Parker and all of the amazing guys from Ministry of Testing, the Evil Tester and many more! I hope to build on my technical abilities and continue to grow in the field with the goal of eventually giving back and helping other testers become established, gaining confidence in their fields.

Thank you for taking the time to read! Please let me know your thoughts and how you got into testing! via email or Twitter @webtesthub

All the best!

James

Read More