The Curious Case of the Front End Button

How can we test buttons on a UI? In what ways can we approach our testing? In this post, I’d like to share some things for the curious mind to consider when testing buttons on a front-end/user interface. 

We were recently testing a feature which is going to be rolled out to every user on our platform via a notification. In doing so, our team found an issue with one of the buttons shown to the end user (shown below:)

Luckily the error was fixed before deployment, but finding it inspired this post. As we know, buttons can behave in countless ways on a page, so apologies in advance for the fact that this blog will only scrape the surface of what is a huge subject. Nonetheless, I thought it would be a good idea to share some tips and things to bear in mind if you’re testing buttons on the front end of an application – and I hope you’ll find them useful.

1. How does it look? The first thing the user does with a button is look at it – so let's consider the following:

 - How much text is on the button? If there's quite a lengthy sentence or call to action, could that cause some issues in relation to page responsiveness, as shown above? Additionally, is the font used compatible on other browsers, including older ones?

- Is the colour of the button consistent with the other aspects of the application? If it is, that might not necessarily be a good thing. Does the button call the user to an important action – for example, if it is missed could their account be affected? If so, then maybe the colour should be something contrasting that grabs the reader’s attention and suggests 'click me NOW' in tone (in red or orange, say) as opposed to a more casual 'hey there, why not click?' (if consistent with the usual colours of the application). Alternatively, if the application already uses red or orange colours in its branding, you’ll probably need to use an alternative colour to make the text stand out – something to think about. 

- Does it animate? When you hover over it, does your mouse cursor icon change? Does the button animate when you click on it? If so, you’ll need to start considering how this button will behave on mobile devices, where there is no mouse icon. You’ll also need to think about what will happen with other or older browsers, because the animations may only work on modern browsers. 

2. What does it do? We can now start thinking about how the button behaves. For example, is it a button that submits data? Can it be held down to increase the value in increments (like a counter button)? If so, how would this work on other devices? Does it take us to the correct place when it is clicked on? Is it dependent on mandatory fields? If any of those are the case, we should check that the button works and submits information provided when those fields both are and are not filled with data. 

- Where is it all happening? 

OFF the page: When we interact with the button, we can open our browser dev tools to monitor if there is any activity in the 'network' tab. If so, we can now open to a whole new world of opportunities (API testing, for example). Can we manipulate the HTTP traffic? (An excellent post/video on how to do this, by The Evil Tester, can be found HERE). Perhaps block the request to see how our application behaves in the absence of icons and/or buttons. When we view the requests allowed, should we be able to perform each one? (For example, if it accepts a ‘delete’ request, you may want to question why.) 

ON the page: Alternatively, if we click the button and there is no network traffic, we can then start thinking about possibilities in relation to CSS and Javascript, since the behaviour is happening on the page only. Do new fields open up? If so, do we have an option to go back and close those fields? What happens if we keep going back and reopening those fields? Do they just keep reopening down the page in a never-ending chain? Should they only open up once? You should also check this behaviour on various browsers and devices. 

There are so many different things that can happen on the page when interacting with buttons but, generally speaking, the main things we will probably have to consider in this instance will be compatibility (with other browsers and operating systems) and the performance of the site. Bear in mind that if we have a lot of stuff happening on the page once the button is clicked, we probably have large files stored, and they can slow performance, from as soon as when the site loads as it is first visited. 

ON AND OFF the page: Here’s something else to consider. If we are shown a message of some sort on the front end after clicking the button, does that message correctly coincide with what is happening in the back end? For example, you may get the message 'user successfully created' – but then find, when you check the back end, that there is no user, and vice-versa (reconciling front end and back end behaviours). It’s always worth double-checking.

3. Can and should we automate this? Does the introduction of the button create more work flows? Is the same button used in several places with the same function? If so, perhaps we could save ourselves some time by automating the clicking or hovering of this button, by verifying that it looks and behaves as we expect, or by automating the filling of data it requires. 

Allow me to briefly mention a project I once tested. It was a tool for doctors and healthcare professionals to use to register patients with a specific condition. It wasn’t your normal user creation form, and instead had many tabs containing mandatory fields. I couldn’t get to the next tab on the user creation form until those mandatory fields were filled in on each specific tab (confused yet?!). We had one button at the end of each form, which was used across five different tabs, and, when clicked, opened up a text box requiring more details before you could move to the next tab. Obviously this was very time-consuming – it would take approximately five or six minutes just to create one user. Automating this process seemed to be a natural thing to consider at the time. Whenever I needed to create a new user on the system, it was made a lot more simple and easy via the automated tests we created. OK, this example isn't button-specific, but it does show that there are things we can automate on the button itself, such as left clicks, right clicks and mouse hovers. 

It’s something to consider when testing front end buttons. Bear in mind, though, that just because you can automate it, doesn't necessarily mean you should.

4. Who can use this? What’s the demographic of your users? Do you know? (You should!) Is this button going to be equally usable for those users? Does it use clear text at a good size? Is the colour easy on the eye for those who have difficulty seeing? Can we use an alternative way of doing what the button is doing if the button doesn't work on older browsers or other devices? These are all important things to bear in mind, and it is all too easy to overlook them.

As I have mentioned above, the possibilities are endless when it comes to testing buttons on the front end. It is likely that you wouldn’t ever just test a button in isolation. They are usually brought in along with another page or field, so when testing you should also bear in mind how these components are going to work together.

That's all for now and I hope you’ll find this post beneficial. Do please do let me know what I've missed and what you’d add to the list of things to consider when testing buttons on the front end in general. 

Looking forward to hearing from you! 

@webtesthub

Read More

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