TestBash Essentials Brighton 2019

There’s a tool to aid our testing that we all have access to all the time. It’s hidden in plain sight, you just have to know the secret code to get to it. This secret tool? The browser’s developer tools, of course! Learn how the developer tools in your browser can give you insight into what your application is really doing, access to artifacts vital to testing (like cookies and cache), and learn to speak to your application directly, like never before. Unlock a whole host of information about your application, and release your inner super sleuth tester

Welcome to Testbash... Don't Panic. Seriously... that comes way later. 

I will be your guide in this special place. Testers have come here from across the globe (or flat plane... depending on your physics preferences) to exchange ideas, trade in techniques and generally immerse themselves in the world of software testing today. But what are these terms we hear?

"Test Charters"?

"Heuristics"?

"Oracles"?

"What do you mean by that's checking, not testing"?

Seriously, where's my babel fish? How am we supposed to understand all this amazing ideas if we are using terms that nobody has ever used back home?

That's where the Guide comes in. This immersive, interactive and friendly book will help you navigate every new challenge you might encounter while exploring the world of Testbash. From the great debates of automation, to the dangers of testcases... from the fall of waterfall to the rise of agilefall...  the Guide will help establish a safe baseline of where we are, how we got here, and why it might matter. Also, the Guide come with a nice head called Martin who talks to you so you don't have to read it.

Now, sit back and enjoy the conference.

Are you in the proper mode to find your median, or do you just feel mean? Whether you are trying to judge if your application is ready for Christmas shopping season or validating a machine learning algorithm, an understanding of statistics can help you be a more effective tester. In this talk, Amber will draw on nearly 20 years of experience with testing everything from handwriting recognition algorithms to high volume game APIs to show how a few basic statitical concepts can move your testing beyond just average.

Those teams working in an agile fashion will usually bring the tester in as early as possible in the development cycle — often during the planning stages — to find potential problems before they create work to fix. But checking for potential technical problems is only a small part of what the QA team can do in this stage.

The QA team has a wide scope to make the product as good as it can be. This allows the tester to use not just their technical knowledge, but their non-technical knowledge, in their quest for quality. 

In this talk, we will be outlining those non technical disciplines that a tester has, from historian to lawyer, and even spy. Testers will come away from this talk full of ideas of questions to ask of their product, while other members of the team will come away with a greater understanding of the knowledge a good tester can bring to the table.

Items covered will include accessibility, data protection, misuse of a product, and being culturally sensitive.

When I started in my new team, I realised that I was the first tester the team had had. Up until that point, the only testers that were involved with their project were the ones that tested in Production after they were finished building the feature.

The thing is, testability had never been an issue for this team - until I joined. My first few weeks was spent asking for things, asking for test data, asking for more test data - eventually asking to learn how to create test data (from a separate team). I asked to learn how to edit the html, to test different scenarios because the test data was missing. I wanted access to github so I could see the pull requests being done to address different stories in JIRA.

I wanted it all! I was a demanding tester.

And after a while, things got easier. I was even able to help developers make testability easier on their local machine, so they could debug faster.

I want to share my story on how I learned to ask for increased testability, and how I learned what exactly testability means, after I realized this what I had been focussing on this whole time.

This session would break down some techniques on how to approach researching for a given domain(s) which involve the software under test.

This session would seek to give the attendee a way to develop simple personas, understand market pressures, and research competitors.

This could be considered a mini workshop or interactive talk. The goal would be to get the audience to do quick research katas which might be shared later with their development groups.

Katas could be, but aren't limited to:

• Domain identification
• User persona/Typical User identification
• Competitive Analysis:  Looking for domain competitors or near domain competitors. Also includes future feature identification.
• General Domain research: What information is out there about your company. What information is out there about your competitors. How do I find it.
• Internal research techniques: Who can I talk to about the product outside of development. What information is available internally. What sales pitches, informational materials, or help guides tell you or your users. Are they correct?

The goal would be to tie these activities together to testing. As an informed tester is a better tester. Likewise, an informed development group is a better development group.

After spending countless hours in testing GUI and backend, numerous bugs are encountered in production. What’s missing? Due to crunch of resources and time, API testing is generally skipped and that’s where lot of bugs resides. However, noticing the increase in number of APIs used for development of years, it’s crystal clear that API testing is the new king!

GUI testing revolves around user’s experience, look & feel of the product. Can we justify applying same approach for testing APIs?

If yes, how? If no, then what crucial scenarios should be covered, what are prerequisites needed, what is a must to-do checklist for API tests? If you are less associated with API and lack answers, don’t worry. You are not alone.

Shivani had faced similar situation when she didn’t even know “A” of API testing. Based on her experiences at Kreditech and XING, she’ll explore what the API testing is all about, its core values, test strategy, common API testing mistakes and how to avoid them. Join the talk to know about her tale of shifting perspective from browsers, button, textboxes to requests, response and endpoints.

Takeaways

• How to perform API testing keeping in mind user’s perspective.
• Tools that can make life easier when it comes to API
• Art of using techniques of UI testing in API testing
• How to motivate your team for contribution in stable APIs

Ever wanted to test all the things but forgot something along the way? 

Ever wanted to look at the vast testing universe and plan what direction you want to go or what you want to learn next?

Ever wondered how much you know or wanted to measure or evidence this to someone? 

Well now there’s a one-stop shop to help you remember, plan your learning or show someone what you know.  A resource that will not only inform your decisions but hopefully inspire them!  A source so awesome it will let you look at your project from not just a test but from a manual, technical and a personal perspective too.  A visual heuristic that can help shape your learning, show the value testing brings and can assist in identifying the ‘what and how’ of a testing strategy or approach.

Introducing the Periodic Table of Testing.  A visual heuristic of the testing universe covering everything from manual to technical testing, from personal drivers to work methodologies.  In the beginning, I was a business user who did some testing.   It intrigued me and became my career.  I was ok, I tested what it should do.  The more I got into testing the more I read and learned, the more sophisticated I thought my testing became.  But essentially, the more things I uncovered lead to even more things I didn’t know I didn’t really know! The more I read the more confused I became about what there was, how it all connected and what paths of learning I could/should follow.  When to use what, how much of something should you be aware of, particularly specialisms like security.  There seemed to be multiple opinions, often contradictory, about what I should and shouldn’t be learning.  So I started making my own ‘list’ which grew and grew.  I tried various ways to visualise the information until I tried the table and that seemed to work well.

As well as highlighting how the table can be used I’ll share some of my experiences such as; the first time I had to do some testing on user access I thought I’d done well, thinking of different scenarios… until there was a production issue!  I’d covered user access but not all the roles.  From the investigation I found there were individual and service account permissions that were not taken into consideration.  That was when the ‘UA – User Access / Permissions / Roles’ element was born.  This led me on to thinking about penetration testing and looking at possible attacks.  Had the table been around then, I would have been able to at least ask questions that might have helped identify our test environment was set up quite differently to live.  

The long term goal of the table is several fold.

• To make the viewer aware of the possibilities available to new, current and potential testers
• To help shape learning paths
• To help people show their current development
• As a reminder or prompt when creating tests
• As a support for test advocacy showing the multi-dimensional range of testing
• To use as a basis to identify the potential scope of testing in projects 
• To start conversations and provoke thought

In creating the table and developing it to the point where it adds value to the above I’ve also been able to categorise the table into three distinct areas.  Those that really must be considered for every project, fundamentals, accessibility, data, etc. Those that should be considered dependent on the project, operating systems, capacity etc.  As well as those that could be considered. As part of the session you will also learn that no technique or ‘element’ lives in isolation.  Personas for example expose user journeys and tours. Accessibility testing exposes poor design and usability.  I’ll work through the tables sections explaining their aim, why they are split in that way and looking forward, what possible inclusions or changes are under consideration.  I’ll show how I think the table can be used to scope projects, direct your learning, help you gather evidence for your end of year reviews and even create better job descriptions and advertisements.

I’m not looking to make money by selling this.  I don’t even have advertisements on my blog, I just want to share my ideas to help people and keep improving it so it can be of more value to more people.  

For a while now, the motto for agile testers has been: ‘acquire more technical skills so you can support the team better’. However, you almost never hear the motto for developers: ‘improve your testing skills so you can support the team better’. Even in an agile context, you still see testers doing the bulk, if not all, of the non-automated testing.

But wouldn’t it be more effective if the testers teach the whole team how to explore? Can you imagine the power of a whole team being able to test an application effectively?

Exploratory Testing is great to teach others because it uses everybody’s unique point of view, experience, and biases when interacting with the application under test. As a tester, you can take the lead in switching your teams' mindset with regards to quality and test responsibility, even if you are a junior tester. You can do more than you think!

In this talk, I will share how I started this challenge with my team by organising Exploratory Testing Sessions. What was successful? What was hard? My goal for this session is to inspire you to try this out with your own team.