Showing posts with label eurotestconf. Show all posts
Showing posts with label eurotestconf. Show all posts

Sunday, August 18, 2019

#CodeConfident: Journey - Part 2

My Journey project made some progress! It's still far from where I'd like it to be, yet here's another part of my coding journal - including three more pairing sessions and a brief detour to my former Rest Practice project. Enjoy! :)

July 14

  • pairing session with Parveen Khan
  • when preparing for my pairing session, I removed all built directories and have the project build from scratch - which indeed proved my assumption that this would fix the profile service! :D
  • in the beginning I told her about the background of the app, did a short run through of the app, explained what had been generated and what I added or changed, and what are potential next things to do
  • Parveen wanted to explore the app and then do first changes together
  • when Parveen went through the app, we noticed several things, she raised lots of great questions and she triggered several ideas what to do next
    • TODO: the create / update challenge dialog showed the "influences" label in lowercase although it should be uppercase
    • TODO: the journal entry index page should sort entries by default by date in a descending way with the latest one on top (right now sorted by creation date)
    • TODO: for the index pages, the pagination thresholds should be defined, e.g. only showing 10 items per page
    • IDEA: Parveen asked me whether I wanted to use the app to instantly publish journal entries to my blog - and I thought of that indeed! Or at least to have a quick copy button for the description field so I could easily copy it over to my blog posts and make my own life easier
    • TODO: showing the challenge id for journal entries is not really useful, should rather show the tag instead (had that one on my list, yet it's great to hear confirmation from a different person that this should change)
    • TODO: the challenge delete dialog should not only ask for confirmation of the deletion but also inform what will happen with potential related journal entries
    • TODO: when trying to delete a challenge that still has journal entries, an unhelpful error 500 is thrown and the error message is not useful at all
  • then we went on with making small changes to the app and seeing their impact
  • for the challenge index view, we added a column for the hypothesis
  • for the journal entry index view, we wanted to do the same, yet decided not to dive deeper here for now and solve that puzzle yet
  • instead we changed the challenge detail view to not show the challenge id in the title yet the tag instead, and removed the tag from the rest of the detail page
  • IDEA: we found it would be great to see related journal entries also in the challenge detail view
  • Reflecting:
    • Lisi: having a practice project offers a great and safe learning environment to get your toes wet
    • Parveen: you need to have some idea of what app you want, then you start with small steps, then you get used to it, and you keep trying
    • Parveen: having me as trusted navigator gave her the confidence to do these changes herself; also, I gave her the confidence by telling her "it's fine, don't worry", "we can just delete it, we have it under version control" and letting her do it on her own and try things out; Lisi: it was super useful to practice explaining things I learned (some of them recently), especially in a simple way, really helps my own learning; this is also something such safe learning environments are perfect for
    • Parveen: was super great to both explore an app and make changes within just one hour! Now she understands why developers get into the zone, even forgetting to eat, doing things step by step; all this really helps to get into their shoes and create empathy
    • Lisi: was really cool, got a lot of ideas out of the session :D

July 14 (cont)


July 21


July 24


July 25


July 27


July 28

  • looking at examples from work
  • tried more things
  • really need to read more deeper first
  • nothing committed yet

August 11

  • pairing with Shivani Gaba
  • We planned to set out to pair on my Rest Practice project for which Shivani had feedback to share based on her experience with automated API tests.
  • Shortly before the call I realized that the framework used in this project was relying on Java 8 which I recently had removed from my computer so we could not run the tests. After spending some time back and forth how to install OpenJDK 8 so I would not need the Oracle version, we decided to go through the feedback first. (Later I found this site where I could download a pre-built version of OpenJDK 8 for Windows: https://adoptopenjdk.net/)
  • Instead of always using an explicit status code (e.g. 200), Shivani recommended to use predefined response status types so that the test becomes more readable and less error-prone.
    https://docs.oracle.com/javaee/7/api/javax/ws/rs/core/Response.Status.html
    https://www.programcreek.com/java-api-examples/javax.ws.rs.core.Response.Status
  • In the current tests I asserted for certain body properties. Shivani recommended to implement a JSON helper instead which would provide utility methods like comparing the actual response to an expected JSON. This comes in handy especially if you have a lot more fields to test for. Also, this helper could offer generic convenience methods for creating a JSON object with certain parameters, adding and removing properties, or merging JSONs. Shivani offered to provide a sample - thank you!!
  • Shivani recommended to store the complete response in a variable from which we can then extract headers, body, code whatever we need/want to use for each test only what's needed for the specific test.
  • All endpoints were repeated in each test. Shivani would rather extract them as global enums (e.g. something like "Employee.GET_ID"), or at least declare them as variable, and re-use them, which would also increase readability and maintainability. If they change, you only need to change them in one place.
  • One open question in the practice project was how to get a response without given/when/then when it's only about the setup. Shivani shared how she would wrap the setup in a custom method (e.g. a post method) to hide this implementation details from the rest of the test, which makes it more readable and more maintainable as well.
  • At this point we decided to switch to my Journey project and have a look at how integration tests are done there. I explained the background and purpose of the project, what JHipster already brought with it, and that most of the tests got auto-generated and need improvement.
  • We took the test for creating a journal entry as an example to start with. I shared that what surprised me with the generated tests was that they check the database directly instead of calling the API again to verify if the record really got created. This might be good as it's about testing the integration with the database, yet I was not so sure about depending on the database state here. Shivani did not work with Spring and its test context yet, yet this surprised her as well.
  • Shivani shared that oftentimes integration tests are only used for the happy path, yet they are perfect for negative testing as well. For example, what if a mandatory field is not there? How do we handle that? We decided to implement a test for that to learn how it's done with the Spring framework. We discovered we could simply set a mandatory field to null before creating the DTO out of the entity which led to a bad request we could assert for.
  • We learned more about how the Spring framework builds requests and uses matchers for assertions.
  • We did not yet find a way how to provide custom error messages this way, like we could do for AssertThat().
  • We found a more readable and re-usable way how to write the tests, extracting the expected response and the builder which made the test more lean. We could do this globally to reduce duplication.
    https://www.logicbig.com/how-to/code-snippets/jcode-spring-mvc-junit-test.html
  • Reflection:
    • I was really sorry for the rough start and the delay before we could work hands-on together. I was not as prepared for the session as I wanted to be, had a bad day. In the session I gained a lot new insights and good practices how to improve readability and maintainability of API tests. Thanks so much for sharing your experience Shivani!
    • Shivani shared she was happy to pair with me. It got her really motivated to work on her own project idea now; something she had in mind for longer yet did not start yet :)

August 15

  • Pairing session with Gem Hill on unit tests
  • Gem is starting her own testing tour and I felt super honored to be the first stop on her tour! :D For more details see https://letstalkabouttests.xyz/index.php/testing-tour/
  • We started with me explaining the background of my Journey project, what it's supposed to do and also the code generation part, showing Gem what's there.
  • We wanted to dive deeper into unit tests, and we had quite some generated tests to look into to understand them better and also critically question them.
  • We decided to dive into the frontend unit tests using Jest as Gem's team is now also working with TypeScript and Jest, so this was a perfect match; and also for me it was great as currently I am working on frontend unit tests as well at work in a similar setup.
  • I shortly introduced Jest and it's super useful watch feature where it runs all time in the background, running tests for changed files to quickly provide feedback while developing (my colleagues love that feature).
  • We decided to look at the test for the challenge detail component first as most simple starting point.
  • We went through the test from top til bottom, trying to formulate our understanding, making assumptions clear, voicing questions and parts we don't understand yet.
  • Then we had a look at the actual implementation to map it to what we saw in the test.
  • We noticed that the tested ngOnInit function only subscribed to the challenge, yet the subscription was not tested. This part is basic functionality provided from the framework - which is normally not what we want to test. So it's always the question where do we trust the framework implementation?
  • We had a closer look at the mocking part. Interesting to dive deeper into would be the ComponentFixture class which is provided by Angular as fixture for testing and debugging components. This is something we're not using at work so I'm curious to find out more.
  • The test is importing a test module which comes with a lot of mocks for services.
  • When looking at the test module we came across the same number used for ids again, "123" - it seems the JHipster developers used the same number for all kinds of ids. To make sure our test is independent we changed the id for the used challenge and the tests promptly failed. Here we could see how Jest points out differences. I am also using the Jest plugin for Visual Studio Code which even shows the error inline. That's a nice feature, yet for me it's easier and quicker to see what went wrong in the console output.
  • We decided to move on to another test and chose the assumed next smallest one, the one for the delete component.
  • Here we came across the fakeAsync() and tick() methods which caught our interest. Once again we enjoyed the Visual Studio Code feature to hover over a method to get its description :) We learned that tick() simulates the asynchronous passage of time.
  • We discussed spies which allow to mock return values of functions to stay independent from other parts of the app.
  • Gem suggested to interact with the locally running app and see what's actually happening. This triggered the idea that I should install the Redux DevTools so we could inspect even closer. For now, we deleted a challenge and checked the respective requests sent. This way we saw that opening the delete dialog sends a GET request for the respective challenge - why? We had a look at the implementation and saw the defined selector. Was this the reason? We checked all references yet it was only defined here. We could not yet clearly see how things connect here, something to find out later.
  • We had a look at the implementation for deletion and found a method to close the dialog on cancel. Once again we asked ourselves, is this worth writing a test for? Is it worth the effort of maintaining such a test? This should normally be code that's not touched very often so it's probably not worth it.
  • We discussed mutation testing, an approach my team is currently trying out and Gem used quite often in the past. This is a great way to see if our tests are actually valuable and would detect issues and where we are missing tests. In my team we plan to use this as better guideline for what to write tests for than mere coverage which is not as helpful.
  • Another part that caught our interest was that on deletion, an event gets broadcasted and the dialog closed. In the test, however, not the actual methods but respective spy methods had been used: dismissSpy() and broadcastSpy(). We assumed this makes the unit test even more "unit". Another point to dive into deeper!
  • We moved on to the next test, this time the more complex one for updating the component. Once again, we started from top, including the imports. Gem called out that it's interesting that a HttpResponse is imported, came unexpected.
  • We also once more saw that the test was named "Challenge Management Update Component", as it was generated - we both found it weird that the word "management" was included here.
  • We had a look at the test for saving. It's really great that the generated tests included comments for given / when / then which made them easier to read and understand. This test, interestingly, also showed a comment for the tick() method which the other test lacked!
  • We checked the differences for updating and creating a challenge, both on test and implementation side.
  • What caught our eye was a boolean called isSaving. We wondered what it would do? We decided to first interact with the app again to see what's actually happening. A GET request, a PUT request. Nothing unexpected. Then we had a look at the implementation for isSaving. And we found this boolean is set to true only during the time the actual saving process is taking place. The value is only used in the tests. We both found this very weird. We would not expect this kind of implementation just for the tests, we never saw something like this in the products we worked on. We would only expect to add this during debugging to see what's going on; yet for the test it felt strange and it didn't feel to provide any value. I took a note to remove this implementation later on.
  • Reflection:
    • Time was flying and we soon got to the end of our 90min timebox.
    • We both found it really nice to take time and dissect unit tests, challenging them, asking why, finding issues and questions while learning about the product. It proved again the point that you don't need to know code to the extent a developer does to be able to use your skills and strengths as a tester on code.
    • I absolutely enjoyed our pairing session. When pairing we both bring our skills, expertise and knowledge to the table, and Gem and I had both overlapping and differing knowledge which fit together nicely.
    • When pairing I realized how valuable it is to also look at the imports! I normally skipped them, yet we can already raise questions and improve our understanding here.
    • It was great that Gem reminded me to interact with the real product again. I tend to focus too narrowly on what's in front of me which in this case is the code base, so it's easy to get disconnected. I noticed this several times now already during my code-confident challenge, catching myself on things I should know better. Gem pointed out this needs a context switch which is not easy. I agree, and it also increased my empathy towards my developers a lot more.
    • Gem noticed me taking notes and realized she should also think about how to take notes better for her next stops on her testing tour.
    • Gem found JHipster really intriguing. All the weirdness and bloatiness aside it seems to be really valuable to quickly kick-start a project and be able to learn with it. She plans to generate her own project for further learning purpose.
    • We both found it super easy to pair with each other, even though we only met a few times in real life or virtually and paired only once before. Time flew by and we both were energized afterwards!
    • I'm super looking forward to hearing more about Gem's testing tour and the lessons she will learn on her way :)
  • TODO:
    • install the Redux DevTools
    • remove isSaving boolean

What else?

The next Ministry of Testing Power Hour is coming up! I'm excited to be the one answering all your questions about pairing and mobbing. Just ask them at the club, and on August 22nd I'll answer them from my experience.
Also, the call for collaboration for European Testing Conference is open! Seize the opportunity to participate in this amazing conference next year by proposing your session ideas. The submission alone is worth it as you will get invaluable feedback.
Posted by at No comments:
Labels: , , , , , , , , , , , , , ,

Thursday, February 21, 2019

European Testing Conference 2019 - Designed for Us

Last year I got selected to speak at European Testing Conference together with my learning partner, Toyer Mamoojee. It was such an inspiring experience that I knew I had to come again in 2019. And yet again it was amazing!
For this edition I was joining the conference as participant - nothing to do for me than learning together with great people of many different roles and perspectives, all interested in testing. After speaking at many conferences this was a really relaxed experience that I really enjoyed for a change.
Here are the sessions I attended, including my sketchnotes.
As always, I tried to get the most out of the event, not only attending all session slots (I felt I also had the energy to do so), but also making good use of the breaks to talk with people old and new, and of course using the time after the official program was over. After experiencing a lot of conferences during the last few years (a lot more than I ever imagined, thanks to my speaking challenge of 2017), I learned that the unofficial socializing part of a conference is usually the most valuable time spent. Attending sessions is great and a good learning experience, and yet exchanging knowledge and new things learned with my peers is unbeatable.

The great thing about European Testing Conference is that they design the conference so that plenty of these kind of informal learning opportunities and networking chances are available, the space for that is created by intention. You only have to seize the moment! To get further impressions about this very special atmosphere, check out the following links.
One conference was over, and the next one started! I felt really honored and lucky to get the opportunity to attend #ET19 just the day after European Testing Conference. This was my very first peer conference, and also one about a topic very dear to my heart: exploratory testing. For now, I can only say so much: it was great, and it was a lot to take in! I still have to process everything. In the meantime, check out Marianne Duijst's awesome #ET19 sketchnotes.
Last but not least, here are some of my favorite #ETCmoments of 2019! I'm already looking forward to the 2020 edition of European Testing Conference!
Posted by at No comments:
Labels: , , , , , , , , , , , ,

Tuesday, February 27, 2018

European Testing Conference 2018 - Coming Home

Last week I had the honor to join European Testing Conference as a speaker. It was my first time attending this conference, but it made me feel like I'm coming home. Here's why.

Arriving at Amsterdam

My travels went smoothly, but got even smoother after I arrived at Amsterdam airport.
It was an awesome experience to get greeted this way by Llewellyn Falco, Simon Schrijver, Maaret Pyhäjärvi and her sister. I instantly felt welcome.

After a short rest at the hotel I enjoyed the second highlight of the day: meeting my learning partner Toyer Mamoojee again in real life! Although we talk every two weeks, we had so many things to tell each other in person. And we also had a final task to do: a last rehearsal of the talk we were going to give the next day. Our chance to practice it for the first time face to face! Well, all our virtual sessions before paid out. Once again we learned how well we got to know each other since we first met at Agile Testing Days 2016.

Time for the speakers' dinner! I learned to love this part of being a speaker at a conference. The evening when we all meet each other before the conference starts is an awesome opportunity to get to know some old and new friendly faces, exchange experiences, and calm each other's nerves.

Conference Day 1: Telling Our Story on Stage

Although our talk was scheduled for the first conference morning, the first day started surprisingly calm. I slept well, nervousness regarding my upcoming talk was not kicking in already. When asking Toyer about it, he confirmed it was the same for him. This might be due to the fact that either of us had already gathered some speaking experience, or that we knew we will have the other one right beside us on stage; or maybe a combination of both. After arriving at the venue we made sure our room was prepared and our technical setup working. Now we were ready for the conference to start!

Franziska Sauerwein kicked it off. Being a developer herself, she made it clear that this is a conference about testing, explicitly inviting testers and developers side by side (as well as anyone else interested in testing). I'm really intrigued by this idea! Collaboration for the win. Another great point made: European Testing Conference was started to change the world of conferences, for attendees and for speakers; and that proved just about right.
After the opening, we all enjoyed Gojko Adzic's great keynote "Painless Visual Testing". An exciting story of an experiment that could have failed or succeeded - and turned out to become an even greater success than dreamed of. Make sure to check out his open sourced tool Appraise! Right after the opening keynote Toyer and I headed towards our room - it was about showtime for our talk "Finding a Learning Partner in the Testing Community". At first only a few people trickled in, but then more and more found their way to our room. Half of them were awesome people we already met and admired, and half of them awesome people we still would love to get to know. And what can I say? We finally shared our story how we found each other as learning partners - on stage! It was simply amazing. According to the feedback we received afterwards we managed to inspire a lot of people, just as we intended. In case you missed our talk but would like to learn more, here are our slides, here's our InfoQ Q&A about the talk, and if you happen to organize a conference yourself we offer to share our story again on stage! ;-) Finally, some impressions on our talk. Right after our talk we rushed to the next great session: a speed meet! As Llewellyn put it, getting 200 geeks to talk is an achievement in itself ;) This format is an awesome icebreaker and fit really well to Toyer's and my talk before. We all were asked to create a personal mind map with three branches: about our person, about our work, and about what happened last year. This was a great conversation starter for the limited time we had to get to know the other person in front of us. My personal highlight: This way I could finally speak to Gojko himself, who had joined our talk before so that we instantly had a great topic to talk about! He also loved the fact that I studied sinology, as "inspiration can be found anywhere". I absolutely agree. Afterwards: lunch break! Time to finally get to know João Proença better. He is part of the other pact group together with Christian Baumann and Sonja Nešić which emerged at Agile Testing Days 2017, inspired by Toyer's and my learning partnership. What a great new connection! Throughout the conference we had really interesting conversations and I learned we have a lot to learn from each other. In the afternoon I joined Amber Race's workshop "Exploring Your APIs with Postman". She did a great job at making people aware of what to look out for when testing APIs as well as in demonstrating Postman, a really valuable REST client with many useful features (if you now read about this tool for the first time, make sure to check it out). It seems many people really were not aware of how easily they could get started with testing APIs. Although I already knew a lot of what Amber shared, I still could note a few points to implement at work. The only sad thing for me was that the hands-on time during the workshop was very limited. I would have wished for more time actually practicing exploring an API within our group.

Well, it also had it's good sides. From the past conferences I've spoken at I learned that at the day that I have my talk, I will have a down phase where I will be unable to concentrate anymore and get distracted by the feedback on the talk coming in on Twitter. This time, this phase started in the workshop and unfortunately continued during Emily Bache's talk about "Testing Microservices". From what I saw and heard it was a great talk, and I would have loved to learn more about Emily's experience; but I just could not pay the attention it deserved.

Next up: lean coffee! I love this agenda-less format where participants can bring their own topics and challenges into the discussion. We speakers were asked to facilitate, and I happily focused on just that. After yet another break with snacks and great conversations (I love how this conference provides multiple opportunities for people to get to know each other and exchange experience!), it was time for the last keynote for the day. Lanette Creamer did a fabulous job, telling us how to "Test Like a Cat"; a very enlightening presentation with many invaluable reminders for us testers. Just afterwards I learned it was her very first keynote! She really should get invited by more conferences. Was that the end of conference day one? Not yet, as it ended by something I've never seen at a conference so far. And as I've seen it now, I wonder how any modern conference can do without. They scheduled a retrospective so that organizers can get instant feedback from everyone and see where they can immediately adapt. And they did solve what they could! Unbelievably awesome! After shortly returning to the hotel, many people still made it to the restaurant where everybody could follow-up on the day together, enjoy nice food and a free drink.

Conference Day 2: Too Good To Call It a Night

The second day started with yet another powerful keynote, this time by Zeger Van Hese: "The Power of Doubt - Becoming a Software Skeptic". I've enjoyed this talk already online, streamed by another conference, but it was just as good seeing it again. If you have the chance, check it out yourself!
After the keynote, it was workshop time again! This morning I decided to join Seb Rose and Gáspár Nagy on "Writing Better BDD Scenarios", as this is a topic I read a lot about but really lack practice. I was delighted that this workshop was really hands-on, triggering lots of discussions around how to best formulate scenarios to benefit from easily understandable documentation as well as maintainable automation.

After yet another lunch with plenty of healthy but really tasty food, I enjoyed one of my personal highlights of the conference: Alex Schladebeck with "Exploratory Testing in Action". And when Alex says in action, she means in action. She lived up to what she promised and tested live on stage, simultaneously talking about her own testing and then debriefing it together with the audience. For all live testing she only prepared the system under test and two charters, without practicing anything upfront. And she absolutely rocked it! Awesome concept, message, and delivery. I'm in awe of the courage she showed, demonstrating the whole room what testing is and how to talk about it while being authentic, highly entertaining, and knowledgeable. I guess the only thing to top this would be to have the audience select the system under test and charters live. Alex, in case you read this: challenge accepted? ;-) Next up I joined Mirjana Kolarov sharing her experiences about "Monitoring in Production". As my team is on our way improving our monitoring I could really relate to the talk and also gain some great tips. The rest of the afternoon was preserved for a longer open space. Participants brought forward lots of awesome topics, so it was hard to choose which ones to attend. I first joined an experience exchange on mind maps where I learned how other testers use them in many different ways to help testing. Afterwards I could contribute to the question on how to identify a good tester in an interview; a discussion which draw so much interest that it inofficially continued for yet another slot. Astronomer Pamela Gay got the honor of the closing keynote for the conference: "Testing v. Crowdsourced Data, or How I learned to stop worrying and Love the F-Bomb". What a wonderful, inspiring keynote about difficulties at a level that probably not many others are facing. You know, rocks are hard - literally and figuratively. Identifying craters on the moon so that spacecrafts could land safely is a very tricky problem for both computers and human professionals; but (lots of) humans prove to be good in solving it after all. You never heard of Pamela? Now you have, and you should remember her. Wanna help her map the moon? At the very end of the conference, you might have guessed it, there was yet another retrospective! This time using the input of the audience to craft a mind map to help planning for next year. One of the positive things people mentioned: Throughout the conference we enjoyed the notes of brilliant new sketchnote artist Marianne Duijst! Check out her collection of sketchnotes done by her and others during the conference, they are absolutely worth it. So, was the conference now really over? Officially yes, but inofficially it was still continuing! Many of us could not let go yet and rejoined at a nearby restaurant. And even after a great dinner we could not yet let it go and gathered in the hotel lobby for a few more drinks with absolutely awesome people. Although completely tired, having those invaluable deep conversations even after the conference officially ended, made me feel at home even more.

Saying Goodbye for 2018

The next day I finally and really had to return home. Tired, happy, full of inspiration, new friendships made, existing ones strengthened, keeping the conference spirit in my heart.

Last but not least I'd like to thank the wonderful organizing team Maaret Pyhäjärvi, Franziska Sauerwein, Llewellyn Falco, Peter, Alina Ionescu, Julia Durán, Simon Schrijver, as well as all volunteers helping European Testing Conference. You indeed do change the world of conferences - for both speakers and attendees. Many thanks for all your support and service, inspection and adaption, and most of all for providing the opportunity for everyone at the conference to learn from each other, together, with joy. THANK YOU.

I've never attended this conference before, but yet it felt like coming home. It had a kind of magic. The schedule was well balanced, the content awesome, the mixture of session types perfect, the speakers well taken care of. The people were amazingly inspiring and given the chance to have deep conversations with each other. I learned that European Testing Conference is all about the people. And these people are home.
Posted by at No comments:
Labels: , , , , , , , , , , , , , , , , , ,
Subscribe to: Posts (Atom)