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