[English Version]The Amazing Test Bash San Francisco ❤ — Day 1

Samanta Cicilia
10 min readNov 19, 2018
Test Bash SFO \o/

In the previous week I attended to San Francisco Test Bash, an event organized by Ministry Of Testing (Ministry of Testing).

For those who don't know, Ministry is the largest test community in the world, it was founded by Rosie Sherry, and has Meetups in several countries (here, in Brazil, we have the RJ and Recife meetups), The Club, Dojo and the Test Bash which are conferences with speakers from around the world (in this link you find all Test Bash).

The Conference at SFO had talks from different topics within the subject Software Quality: Leadership, Mob Programming, Test's Pyramid, QA Culture, Automation, Serverless, Alexa, Data Management, Production Testing, Subcutaneous Testing, Power of Models and Regression Tests.

Let’s see in this post a little about these topics covered in the event :)

Welcome \o/

First Day!

The event began with Elisabeth Hendrickson, which is author of Explore It!, the major reference in exploratory tests.

Her talk had the title “Influence > Authority and Other Principles of Leadership” (Influence is greater than Authority) where she spoke about leadership principles.

In this presentation she talked about how authority and leadership are two different things. Authority is more attached to being able to do something (whether by a statute or by reputation), leadership is something that is beyond the title you have. You can be a developer/tester in your team, whose behavior is of a leader and the team recognizes as a leader.

Another point very interesting was about “being gentle instead of being nice”, people often think that a good leader is that good guy, friend of everybody, but instead, a good leader is one who gives positive and negative feedbacks, being firm and gentle, but speaking and doing what needs to be done.

Some other things she talked:

  • lead by example;
  • do small things every day;
  • negotiate agreements;
  • give voice to the people of your team, creating spaces that allow them to be protagonists;
  • positive feedback is a more powerful force for change than criticism;
  • to solve problems, make them visible first;
  • be gentle, not nice;

Fear is a lousy compass

Finally, this is another important point: fear is a terrible compass! For a while, making management “out of fear” may even work (apparently), but this does not hold up. Be a kind leader and you'll have many positive results. Oh, and before I forget:

Don’t Shave that Yak!

Yak Shaving

Another interesting talk was Jasmin's Smith, “Going Undercover in the Mob”, she talked about the experience in Mob Programming with her team (ah, and Jasmin didn't have technical background!).

For those who don't know, Mob Programming is a development practice where every team (development, testing and product) works on the same thing at the same time!

Jasmine told us about her experience as a person who didn't know how to program when she participated in these sessions with the team. From these sessions she learned more about all areas of the product in which her team works and also managed to pass to the team her vision as a tester.

Some points about the talk:

  • + diversity: People from different backgrounds working together for the same purpose add a lot to the product!
  • + empowerment;
  • imposter syndrome: Jasmine went through a few bouts of this syndrome for fear of not knowing things or not learning, but the support of all team helped her to go ahead;
  • collaboration and learning;
  • empathy!

This video is very cool and describes a day of Mob Programming:

In the next talk, Adrian P. Dunston, who is a developer, told about “Tester at the Table and the Tester in My Head”.

In an irreverent way (his slides were a comic book story), Adrian told us about the tester in his head that helps him think about the quality of the products he is developing.

His slides are now available: https://goo.gl/Lg6zeo

Lessons learned in this talk:

  • Computing is about humans and their relationships (so our users must be in the spotlight, not just the technologies we work with);
  • Repetition is important to achieve mastery;
  • Make agreements;
  • Learn to argue (it’s not about winning a discussion but getting an argument);
  • Promote your work and from that spread the culture of quality to your entire team!

Climbing to the Top of the Mobile Testing Pyramid” it was Rick Clymer's talk where he talked about, as the title itself says, test pyramid for mobile applications.

This talk was about his experience in implementing the test pyramid for mobile. A major concern that ends up happening in this scenario is what should be test in emulators and what should be tested on real devices (and how to prioritize this given the huge variation of devices X OS X versions).

This post from Elemental Selenium talks a little about this subject: The Mobile Testing Pyramid.

Remembering that not only the front-end is made a mobile application, it’s important to cover the base of the pyramid with unit tests and the APIs. In the above layers you start investing in instrumented tests, behavior in emulators, and real devices.

Believe me, if you want, but this was all really at the first day!

The next talk was by Paul Grizzaffi: Extra! Extra! Automation Declared Software!

He has a really cool blog about automation: Responsible Automation.

The main message that Paul wanted to pass is that test automation code should be treated as Production code. It is important to create a sustainable framework, to use good practices, to create a scalable architecture, and so many other features that you need to consider when you are creating Production code. Many people start automating testing because they need to automate and don't invest in fundamentals: programming, good development practices, architecture, and so on.

Teams are often only concerned with the outcome of the test performed and not with the testing infrastructure.

As the lesson of this talk: we need to treat test code as the application code and not just be interested if the result was pass/fail. Create an architecture focused on maintainability, make code review, document well and keep in mind that the test code will also have a long life and you'll need to go back in for maintenance. :D

Angela Riggs talked about “Creating a Culture of Quality Assurance” (the slides are available now).

We know that leaving responsibility for product quality to a single role doesn't work, so it is important that everyone involved understands what quality is for that product and together work to achieve it.

Quality is more about mindset and culture rather than to tools and processes or to the role of tester/QA.

During the talk she told the experience of creating this Culture of Quality in the Vacasa where she is QA Engineer. Here are some topics she talked about:

Challenges to create this culture:

  • Change management;
  • Onboarding (new people in the company and new members in teams);
  • Changes are difficult and emotional;
  • Feedback;
  • Always include “whys” in relation to decision-making;

You’re creating a Culture that everyone supports, but make sure that the culture supports everyone.

Practicing culture (quality is everyone’s responsibility):

  • Management
  • Product
  • Development
  • Test

A great culture of quality is flexible, with the ability to meet changing requirements.

Benefits of this culture:

  • collaboration;
  • communication;
  • shared knowledge;
  • quality;
  • confidence;

A culture of quality is a culture of empowerment and trust.

The last but one talk of the day was by Glenn Buckholz about “How to Test Serverless Cloud Applications”. Serverless is a popular subject nowadays then Glen brought insight into how tests are in that context.

Okay, but what is Serverless???

-o-

According to Martin Fowler, in his article Serverless Architectures:

Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform. By using these ideas, and related ones like single-page applications, such architectures remove much of the need for a traditional always-on server component. Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services.

Well, access to the front-end and tests on it remain the traditional way (you’ll always be able to access a url and perform actions from there), but what about other types of testing? Or are there new types of tests to do in a serverless architecture?

Since you don't manage the infrastructure in this type of architecture, there is a “Local Tests” phase, to get quick feedback if your functions are working.

The unit testing part remains the same (faster and cheaper), but in the case of serverless it is necessary to have a strong investment in integration testing.

AWS Lambda Function with tests — https://goo.gl/soHhLS

For the UI testing part, the advantage is that you can run parallel tests in a simple way.

For those who want to read more about serverless testing, I indicate these posts here:

Ending the first day of the conference, it was the turn of the Dan Ashby and Richard Bradshaw talk about “Power Of Models”.

In this presentation they showed how models can help in representing the Test Strategy and collaborating with others. We (humans) use templates all the time to structure our ideas.

Modeling helps us communicate with others
Modeling helps us collaborate and solve problems
Modeling helps us consider different issues and challenge our current level of thinking
Modeling can provide visual aids to allow us to recall and remember things to help us with the previous three aspects

In this example he uses Visual Task Analysis to show a test flow, represented from each step, at which application layer it is called. From this model it is possible to think about which tests to do in each layer thinking about the best strategy/coverage.

In this other image we have an example of Test Strategy representation (much better than a plain text document).

At the top are represented the — Influences: Context, Constraints and Aspirations; — in green, the Test Approaches (automation, exploratory, etc.); — in red how the tests will be run; — on the side, what will be the Continuous Testing process; — and, finally, the Perceived Quality of this strategy.

Richard often uses Visual Thinking in his talks and this is awesome, at the end of the talk he made the challenge for us to start using and I’m risking some drawings:

by me :D

Conclusions of the Day 1:

I left the event and I felt the Caco in this gif:

OH MY GOD!!

A lot of content, speakers I always had for reference there in front of me sharing knowledge and what caught my attention was how much the event is DIVERSE!

This first day gave me many insight about things we already do in the Concrete and we can improve, as well as things we can experience and adopt.

tl;dr

The idea was to make a post about the whole event, but I really have a lot to share, so this one was about the first day and soon the summary of the second day comes out :)

Thank you for reading!

So, what did you think of this summary? Have you heard of these topics? Do you already do this in your company? Leave your comment here and we'll exchange ideas: D

--

--