She used this one neat trick to model JSON as classes in C#, and her audience was stunned!
I recently presented my talk Testing RESTful Web Services for the first time at the QL Technology Conference in Detroit. In this talk, I cover why we should test web services, and how to test RESTful web services both with tools like Postman, and C# and NUnit.
I was not prepared for, mid-demo, resounding applause from the audience. I was demoing a cool trick I learned from a teammate, and apparently it was new magic to the audience. Awesome! So I decided to blog about it, to spread the word of this fancy magic and help everyone save time when testing RESTful web services within Visual Studio.
What was that magic? It’s the ability to take a JSON response and quickly turn it into a class – a super fast way to model JSON responses!
Huzzah!
If you already know how to do it, awesome! Spread the word!
What you need:
- a JSON response to copy/paste
- Visual Studio, with a solution loaded (we’ll use C#, not sure how it works with other languages)
I’ll use the same examples from my talk – it uses the gitter API (http://gitter.im).
First, create a new class file in your project:
- Right-click in Solution Explorer where you want the file to go
- Select Add -> Class
- Type a name and click Add
Then, paste the JSON as classes!
- Copy the JSON you want to model as a class
- Inside the class file in Visual Studio, put your cursor inside the namespace
- Choose Edit -> Paste Special -> Paste JSON As Classes
- Much rejoicing!
You’ll need to clean up the class a bit, but it will definitely save you time!
I hope you’re able to use this neat trick to help you in your testing of web services!
You will want to choose your JSON responses for modeling carefully – make sure it has all of the potential properties! Otherwise, down the road when you’re deserializing, you’ll hit a failure because the JSON will have an extra property that your class is missing.
Any other neat tricks you can share?
CAST 2016 Recaps
CAST 2016 was held in Vancouver, BC. This was my first time to Vancouver, but I love the Pacific Northwest, so I was pretty sure I was going to love it there. Spoiler alert: I loved it in Vancouver!
I’m so happy I got to attend CAST this year, after missing last year due to project work. Since I first attended in 2014, I knew that CAST was a can’t-miss conference for me for as long as it runs. Putting the “confer” back in “conference” is the style that really appeals to me – as an audience, we’re not just talked at; we engage in active discussion. Everyone is part of the conversation.
This year, I feel like I learned things about myself as a person and as a professional, as well as some solid takeaways to implement at work. Some of the best takeaways came from side conversations, which is true to the spirit of CAST!
On the first day of CAST, I attended two tutorials:
- What Catalyzes Testing? Testability with James Bach
- Learning To Say No with Fiona Charles
Here’s the link to the Storify for day 1: https://storify.com/g33klady/cast-2016
On the second day of CAST, I attended the following sessions:
- Opening Keynote: Automation, Software Design, and the Human Factor with Nicholas Carr
- Babble & Dabble: Creating Bonds Across Disciplines with Katrina Clokie and Carol Brands
- Afternoon Keynote: Test Management Revisited with Anne-Marie Charrett
- Cooperating to Exercise Judgment and Skill: Requirements with Julie Lebo
- How King Uses AI in Testing with Alexander Andelkovic
Here’s the link to the Storify for day 2: https://storify.com/g33klady/cast-2016-day-2
On the third and last day of CAST, I attended the following sessions:
- Opening Keynote: Neuro-Diversity & Software Development with Sallyann Freudenberg
- Alpha Testing as a Catalyst For Organizational Change with Steven Woody
- How Do I Reach The Congregation When I’m Preaching To The Choir with Erik Davis and Rob Bowyer
- It’s Certainly Uncertain – Fostering Healthy Uncertainty on Software Projects with Fiona Charles
Here’s the link to the Storify of day 3: https://storify.com/g33klady/cast-2016-day-3
Of course I did some sightseeing in Vancouver! Here’s a collection of some of those posts:
https://storify.com/g33klady/aside-from-cast-in-vancouver-bc
Kalamazoo X 2016 Recap
Basically, Kalamazoo X 2016 was fucking intense. I’m still processing, I may have more to write later, but I had to at least Storify and get out some thoughts before the initial bits went away: https://storify.com/g33klady/kalamazoo-x-2016-tweet-recap
I’m proud to help make sure KalX happens, and I hope to help make it happen every year. I need this conference – it speaks to me differently each year, it gives me what I need to hear and feel. I think I heard someone say it’s like the Room of Requirement of conferences.
One note – I feel like we need to rebrand it. It’s not “soft skills” as people know it. I don’t know what to call it, though.
I witnessed some people on their phones playing games, and initially I was like “ugh, wtf”. But after talking with one of those people, I realized – this shit is too intense. They’re trying to detach! I now have some empathy for those folks, but I feel like if they come in thinking “I’m going to learn to be better in meetings!” and we throw KalX at them, we might make some people lose their shit…
BestConferenceEver = KalamazooX
KalamazooX is the “non-technical conference for technical people”. It really is the best conference I’ve ever attended, and I go every year since the first one I went to – no exceptions. The best part about this conference, is that it’s SO FREAKIN’ CHEAP for the value! At $75 for standard registration, $35 for students, even with travel and hotel, you’ll end up paying way less than any other conference’s cheapest tickets.
This is my “official” blurb about KalamazooX – how I feel about this amazing conference, from last year:
I’ve only attended 5 or 6 different conferences in my career, but the feeling and motivation I get after KalamazooX is incomparable. The single track, back-to-back talks are intense and life-changing. I’ve meditated and made gratitude lists, been inspired to speak at conferences, laughed, thought deeply about my life, cried – all during KalamazooX. The X conference is definitely one I will never miss – it’s always first on my calendar with time blocked off to go. I can learn the latest technologies and best practices at any other tech conference or online. What makes KalamazooX different is the work we’re putting into ourselves – it doesn’t only change our professional lives but our personal lives as well, all in one amazing conference. I always leave the X conference a different person than who I was when I walked in.
This year, 2016 KalamazooX will be held at the Fetzer Center on the WMU Campus in Kalamazoo, MI, on Saturday, April 30. There’s an amazing list of speakers, like every year – Christina Aldan, Kate Catlin, Ed Finkler, Leon Gersing, Jay Harris, Cory House, Lauren Scott, and Alan Stevens.
Do yourself a favor, and sign up for KalamazooX! It will absolutely change your life!
Suggested (to me) Books on Leadership
I recently tweeted for suggestions on books about self leadership, and leadership in general – especially books that personally helped people. I wasn’t looking for “I heard this book is great” but rather “this book helped me to become a better leader” etc.
I’m compiling the list here because I got a variety of suggestions in various tweets, and I want to have a definitive list when I go looking for books and not have to troll through my twitter mentions 😛 But also compiling here as it may help others!
Several people suggested Becoming a Technical Leader by Gerald Weinberg, along with Weinberg’s Secrets of Consulting, and Becoming a Change Artist. I should just read all of his books I guess…
One Minute Manager by Kenneth Blanchard and Spencer Johnson (blog post w/ suggestion here: http://qahiccupps.blogspot.co.uk/2014/09/the-sixty-second-team.html)
The Power of Servant Leadership by Robert Greenleaf
Tribal Leadership by David Logan (as well as the TED talk: https://www.ted.com/talks/david_logan_on_tribal_leadership?language=en)
And of course, Jim Holmes’ book The Leadership Journey – I read what he has so far, and am excited for him to finish it (nudge nudge)!
Thanks to @spectacledbear, @qahiccupps, @jessclancaster, @codebully, and @pkirkham for their suggestions!
CodeMash 2016
CodeMash 2016 was awesome, as per usual. This year, I think we had a much larger turnout of testers than before. We even had some testing related open spaces!
I wasn’t able to go to all of the sessions I wanted to, but I live-tweeted the ones I did attend! I ended CodeMash with about 400 tweets, according to the rough count I got from Twitter (top is day 1 of CodeMash, before I started tweeting, bottom is after my final CodeMash tweet on Friday):
The big screens in the main hall where my face was far too often (tweet)
Here’s the Storify of the Precompilers I attended, which were
- Python Koans with David Stanek
- Creative Collaboration with Doc Norton
- Testing RESTful Web Services with Mark Winteringham.
https://storify.com/g33klady/codemash-2016-precompilers
On Thursday, I attended the following sessions (which are in the Storify link below them):
-
Is your API leaking? Breaking APIs to increase security with Joe Kuemerle
- A whole team approach to testing with Jon Kruger
- Accessibility of the modern web with Brian Greene
- Growing a Testing Whole Quality Team The Hard Way with Jim Holmes
- Open Space – tester lean coffee
-
How do we solve for XX? with Kate Catlin
- Jam Session!
https://storify.com/g33klady/codemash-2016-day-3
On Friday, I attended the following sessions (which are in the Storify link below them):
- Oppose Your Impostor! How to Be Freed From Feeling Like a Fraud with Marueen Zappala
- How to Stop Hating your Test Suite with Justin Searls
- Automation in Testing, Go Beyond Test Automation with Richard Bradshaw
- My God, it’s Full of Tests with Kyle Lewis
- Open Space – testing discussions
- Secrets of Success in the Style of Glee with Jennifer Marsman
Coding the right thing: not just for developers
This tweet came across my feed recently and I emphatically agreed:
It occurs to me, however, that we as testers sometimes don’t see ourselves falling into the category of needing such advice. There’s the oft repeated “coding the right thing rather than coding the thing right”:
We throw together a script that walks through the application, that performs a particular use case, and we run it and we have this sense of security that if it passes, we are ensuring good code is going out the door.
But are we, as testers, doing due diligence with our code, the same way we expect the developers to? Are we doing design reviews to ensure we’re actually coding the right thing? Are we getting code reviews? Are we reviewing and refactoring our own code as the application code changes? Are we pair programming? From what I’ve seen, some of us are. Many are not.
We cannot advocate that “test code is as important as application code” if we don’t treat it as such. We can teach almost anyone how to write a script to automate use cases of an application. We should be teaching them how to think more – what will this code actually do? What does it accomplish? If it passes, what does it prove? Am I actually asserting anything, or am I just having it click buttons and fill in fields with no actual check in place? It is one thing to write a script to assist you in manual testing – perhaps to get you to a certain point so that you can get to the real testing quicker. It is another to write such a script and treat it as the test itself.
If you write test automation, I challenge you to reconsider what your code actually accomplishes, what a passing check means. Reconsider the design and architecture choices made. What did you mean to do? What did you miss?
I challenge you to treat your code as if it is application code. I challenge you to treat your code as you want the developers you work with to treat theirs. And remember that test automation is not testing (at least not until the machines take over) – you need a brain to test.
Should All Testers Be Automators? The Argument I’m Tired Of, But I Argue Anyway
It has come up recently, in several conversations – what is the ideal tester skillset on a team? Some folks are in the “make them all automators” camp, or “teach them all programming”, or even “get rid of manual testers”. I find that I have strong feelings in this argument, but perhaps my thoughts aren’t all together enough to make my case during these conversations. So here I’ll be spelling out my arguments, and the supposed counter-arguments, about the ideal tester skillset.
This is, of course, my opinion. You are certainly free to use the comments to pose yours 😀
What is the ideal project delivery team?
I feel like this is a good place to start, as it lays out my overall viewpoint on an entire team’s structure.
My ideal project delivery team (Agile of whatever flavor, because Waterfall is nowhere near ideal for me):
- 3-5 developers
- 1-2 business analysts
- 1 tester focused on automation (test engineer, software developer in test, whatever you want to call it)
- 1 tester focused on manual (“analyst”)
- PM, PO, etc. etc.
Argument 1 – you don’t need two testers, the automator can do manual testing too
My problem with this argument is that when you have one tester on a team, there is hardly any time for automation. I, for instance, was the sole tester on a greenfield project. There was so much prototyping, trying things out, trying another newer technology out, etc. that there was no time to do automation. Nothing was automatable because it was going to have to change the next iteration anyway, so why even start?
If the project is in a state where the automator can actually write code, that’s where the majority of their time will be spent. Probably by choice. If I’m writing code, I feel like I’m getting more done – something much more tangible than a test case passed. And automation suites are in constant need of updating and maintenance, especially in a continuously changing codebase.
The fact is, if you want one tester to be on the team, they’re going to split their time between automation and manual testing. They’re going to do manual testing enough to get their automation test cases written. Which means that the amount of exploratory testing that should be done will not get done. Yes, automation helps to be able to do more exploratory testing. But if you’re working on that automation, you’re not doing as much exploratory testing either.
My Stand: two testers, each with their own focus, means you’re getting full attention on automation and on manual testing at the same time. One tester doesn’t have enough time to do both to a high enough degree of attention.
Argument 2 – well, can’t a BA pick up some of the manual testing?
Sure, a BA can do some testing. I hope they already are! However, a BA is someone that is closer to the business or to the client the software is for. They should be testing on a UAT kind of level. I wouldn’t expect a BA to know all of the various types of testing they can perform against a piece of software to the depth that a tester would.
Absolutely a BA’s experience is a benefit to the testing of the software being developed. But a BA also has other obligations – they have to research and write stories, collect acceptance criteria, and interface with the client/end-user. They also don’t have time to do two peoples jobs!
My Stand: a BA should do the job of a BA – yes they should do testing, on a UAT level. Testers are valued for their ability to think differently than other roles on project teams. Each role should be able to do its job.
Argument 3 – at least teach all of the testers how to code!
While I agree that anyone in a software testing role should understand how code is written, I feel that a “basics of programming” and “data structures and algorithms” classes would be enough. I don’t think that everyone has to know how to code. Not everyone wants to, and not everyone is adept at it and THAT IS OK! If a manual tester can’t code, that absolutely does NOT mean that they aren’t progressing in their career. If they are keeping up with technology, they understand the base architecture of the software project they’re working on, then they don’t need to know how to code to test!
What does any tester need to know, in my opinion?
- basics of programming
- data structures and algorithms
- how web services/api’s work at a base level
- how to use the browser debugger (if testing a web-based app)
- how to troubleshoot various applications (debug logs, Fiddler, etc)
- the technologies being used to create the application they’re testing
- what they are at a basic level
- how they’re being implemented
- how to find out what code got built or pushed to their test environment – what changed, what to test
- how to ask questions when they don’t know something
- what questions to ask
- how to just fucking google it sometimes
- of course, standard testing stuff (exploratory, boundary, security, etc etc etc)
The important things for a tester to know are how to talk to the people around them, and various ways they should test the software they’re testing. Yes, understanding how a developer works, or what they need to do to go from requirement to finished software, is incredibly important for anyone working in software to understand. But they don’t need to know the difference between a List and an Array in C#, and when to use each.
Hey, understanding the limits of an int and how you can test a field that has an int datatype is great. Knowing how to see in the database that the field for a phone number has a float datatype and understanding that you can just put in a bug without testing the frontend because wtf were they thinking – that’s invaluable.
My Stand: So yeah, the more you know, the better. Knowledge is power, after all. But you don’t have to be able to write code to be a good tester. Period.
Argument 4 – we should just automate everything and get rid of manual testers
Lets go back to that “standard testing stuff” and “basics of programming”. Testers have a job because developers are human, and they make mistakes. Also, writing code is fucking complicated.
You can automate a lot of things. But you can’t automate a brain, curiosity, a set of eyes that see that weird thing happening on the taskbar that your automation didn’t catch because it’s not a HUMAN and you didn’t tell it to look there so IT DIDN’T!
A computer will do exactly what you tell it to. It can’t explore, it can’t see those subtle differences, or even the big honkin’ bugs unless you code it to do that. But then there’s always something else that your code is not specifically asked to do so it won’t do it.
I personally still feel squeamish about CI. I don’t like the thought of code going straight to production without a set of eyes on it. I will never be ok with CI.
Please, if you haven’t read it or you need a refresher, check out James Bach and Michael Bolton’s definition of testing and checking (automation = checking, btw, not actually testing): http://www.satisfice.com/blog/archives/856
My Final Stand: We need manual testers. We need automators for the regression checks, unit and integration checks, etc. But we will never NOT need people whose sole job is to manually test an application.
So there you go. We should absolutely not get rid of manual testers. Manual testers are not “at the end of their careers”. Manual testers, that are good at what they do and continue to learn, are indispensable.
Arguments? Further points? Let’s chat 😀
Agile and Beyond 2015 recap
Storified here: https://storify.com/g33klady/agile-and-beyond-2015-recap
Please forgive the giant image at the top – I can’t find a way to change it 😦
It’s a loooooong post, a couple hundred tweets, so be prepared!
KalamazooX 2015 recap
I put together my tweets and thoughts of KalamazooX 2015 on Storify here: https://storify.com/g33klady/kalamazoox-2015-recap
