In the beginning I was too afraid to pair myself. I wasn't ready to fail safely. Now that the last year taught me so much that I decided to go on this testing tour, this was the perfect opportunity for me to finally make it happen. And I'm really glad about it! Here's what I learned pairing with Dianë.
Yay, the 4th stop on my #TestingTour is done! Finally had the chance to pair with @dxhymshiti, setting up the basis for automated acceptance tests through the UI from scratch together. Learned a lot again! Thank you Diane, already looking forward to our next session! :D— Elisabeth Hocke (@lisihocke) 6. April 2018
The Idea
When first agreeing to pair, we considered to practice exploratory testing together, on any application. When making things concrete, however, we found that Dianë currently has a task on her list which she hardly finds time for but which would make her tester life easier. So we decided to give it a shot and pair on setting up automation through the UI for one of her team's applications. In addition, Dianë wanted to learn more about Cucumber, and I wanted to finally try out the Screenplay Pattern I learned about at last year's Agile Testing Days.
We both researched a bit about our topic before and started the session by sharing our ideas. I came from the perspective of what we are using in my product team which is SerenityBDD together with Cucumber. The latest version does support and even favor the Screenplay Pattern. However, we have quite an old version in place as well as a lot of legacy and anti-patterns in the code from our initial learning phase. I was eager to learn more about the newest version as input for completely revising our tests. Dianë's team instead is using Protractor for another application, and she thought about trying it out in combination with Cucumber and the Screenplay Pattern for this new use case. As our target system under test was Dianë's, we decided to go for her approach, follow a tutorial she found to get started and then continue from there. We also agreed on the following.
- We used Dianë's laptop as it shows an English keyboard layout which is easier to use than my German one.
- We connected an external screen and used the laptop screen as additional one.
- We paired strong-style, switching navigator and driver roles every four minutes.
- We tried out MobTime, a mob timer application I haven't used so far, running on my laptop standing at the side.
Achievements, Challenges and Other Lessons
When following the tutorial steps on how to setup Protractor in IntelliJ, we were delighted how smoothly and quickly it went. It only took us a few minutes to have a first example test running. We only stumbled once when IntelliJ complained about our spec file. Seems we missed to copy over the closing brackets from the tutorial example; easily fixed. Speaking of the tutorial itself and other resources we came across during our session, several issues quickly caught our eyes, like having step 9 before step 8, or checking for the "4rd" element. Documentation can be buggy, too, it also needs to be tested. Besides such more obvious things like ordering or grammar, it might not fulfill the need of the one who's reading it. If that's the case, sometimes you need to switch to another resource.
We came across two question marks right in the beginning.
- How to name the kind of tests we intended? They got sold to the team as "acceptance tests". The team also had another set of "end-to-end" tests defined already (by the way, I love Katrina Clokie's post about the different meanings of end-to-end). Dianë and I were both not quite convinced regarding this kind of naming. We were feeling confused about the many different terms many different teams use to refer to the same or often different kind of things. To not get stuck, we decided to go with the communicated name of "acceptance tests" for now and postpone the final decision.
- How to add the new dependencies to the existing project? The tutorial let us install everything for our local environment. But what about running the tests in our build pipeline on the server? Even though we frequently discussed automation setups and testing requirements with our developers, we normally only built upon what's already there and rarely set up things from scratch. We decided to postpone clarification of this part as well for now. Still, I could share what I learned from my developers, like the handy shortcut of copying over the needed Gradle dependency statement from the Maven Repository, for example for Selenium.
After successfully having our first dummy example test running, we wanted to adapt it to be a real example for the actual system under test. Once again we noticed how often IDs are missing on elements to have them easily located; it seems people have to make an extra effort to consider testability when developing web pages. Well, we used this circumstance to refresh our locator knowledge and how to validate selectors using the Chrome DevTools.
All in all, the first steps were pretty straight forward; and then we stumbled heavily. We "just" wanted to verify that the expected page had been loaded. So we located an element and wanted to see if it's present. But no such methods were offered on the element! We checked the already existing Protractor tests in the other project and found that the expected methods were indeed offered on elements. What did we miss when setting up our automation basis then? The whole rest of our session we tried to find out where the mistake in our thinking was, trying out different things and searching for answers online. We generated further ideas what to try but could not find the solution yet. However, due to our Google research, I learned about how others search for answers. Dianë for her part suggested to search for a video and then quickly scanned through it to see if the content was helpful. I never realized before that YouTube offered shortcuts for that!
- L: jump 10 seconds forward
- K: pause/play video
- J: jump 10 seconds backwards
In Retrospect
First of all, collaboration was nice and easy. Only very few times we ignored the timer and continued with our previous roles of driver/navigator. Rarely we mixed up the roles, like having the navigator type keys or the driver deciding what to do. All in all, everything went smoothly. Well, we know each other for two years already, so trust, communication or general understanding was not an issue at all.
Working on a foreign computer and setup is still hard. Even though I did it now several times due to frequent mob and pairing session, my finger muscle memory still wanted to go for a German keyboard layout and my eyes had to scan the English keyboard for the needed characters. On the level of "Where was the semicolon again?" I always need a short period of actively having my brain switch to the other keyboard layout. Same with picking up different scrolling directions. However, during this session the two screens confused me several times. We had them standing one behind each other instead of side by side, which triggered a severe "on which side of the screen can I move my mouse to the other one" kind of problem.
The mob timer program we used this time was surprisingly great. After the disappointment of last time, I didn't expect the next application I tried to work so well, but it did. It was yet another recommendation taken out of Maaret Pyhäjärvi's and Llewellyn Falco's awesome "Mob Programming Guidebook". I hesitated to try this one as I favored web applications and this one needs to be installed on the computer. But the setup is very easy, the UI simple and clear, when the timer runs it's only displayed really small on the bottom of the screen so it's not disturbing, and as soon as the timer is up it pops up to the foreground. This application had us to confirm starting the next round just like the last one did, but this time I did not feel annoyed by it, rather supported by the tool. Next time I would love to give MobTime another try, but running on the laptop we actually work on.
We started out very fast and straight-forward towards our goal, and then got sidetracked and confused in trying to find out what we were missing. Unfortunately this did not bring us closer to our original goal of trying Protractor with Cucumber and the Screenplay pattern. We couldn't even touch those topics. The session was still valuable for both of us and we had to create a basis anyway; but we definitely lost our focus. In hindsight, I think we should have shared our initial preparation for the session instead of doing it on our own. A different kind of start might have helped us to get farther towards our end goal. Another option would have been to begin our session with googling for the main intention we had. When I did so while writing this blog post, I came across a really promising framework which seems to fulfill all the initial intentions. Serenity/JS seems to combine everything we wanted to try: Protractor, SerenityBDD, Cucumber, the Screenplay Pattern. I also quickly found tutorials and getting started projects. Would love to try that next time! Really happy that Dianë and I already agreed to have another pairing session.
No comments:
Post a Comment