Wow, this week flew by! I’ve had this post on the back-burner since late last week but just haven’t been able to get it out the door. I attended a webinar hosted by the Software Testing Club recently called How I Interview Testers that was given by Dan Ashby. It was excellent and you can view the webinar at the Dojo or view some of the questions Dan answered after the webinar (including one that I asked about interviewing testers completely new to the profession – yay!). (As a sidenote, the Ministry of Testing is pretty awesome and I love the different things they have going on – someday I hope to attend a TestBash, probably Philadelphia because it is on “this side of the pond”, but one in Manchester or Brighton would be even more cool).
Back to Dan’s webinar. He posted a mind map (see the image at the top of this article – credit is all his – check out the links above for more info on the webinar) that showed how his interviews tended to flow and the types of topics that he would ask a candidate about,as well as how he grouped them together. It looks like a great guide for interviewing testers, but I think it could also help guide a tester in identifying different topics to learn about and incorporate into their own testing efforts.
The map just resonated with me as a great place to start talking about testing. As a result I decided to use it for a series of blog posts to kick things off here at Technophile Tester and it give me an opportunity to share my thinking about those topics (and have my thoughts challenged and refined so I can improve them 🙂 ). Some of Dan’s sections obviously allow for some deeper exploration and more blog posts than others, but I’m looking forward to diving into discussing testing. So please consider this post as the table of contents to my first blog series (ever) – What Do You Know About Software Testing? (WDYKAST). Please see the category link to the right to get a current list of the posts in the series.
The company I work for (Health Catalyst)*, and the group I work in particularly, is moving towards continuous delivery/deployment (which for us right now means deployable after every sprint, which hasn’t been the case over the past year or so in our development efforts). We use Visual Studio Team Services (VSTS) for much of our tooling, including their new build system. As a part of the build we want to label our artifacts and, though it seems silly, naming/labeling our artifact proves to be a little cumbersome because we like to include the sprint number we are on in the build name. That means this has to change for each build definition that we have (we have quite a few products at this point) and it just seemed silly that we have to either hard code that and change that for each sprint or add a variable called Current Sprint to each build definition and change that every 3 weeks for each build definition.
Changing a build number is trivial (but tedious for the number of build definitions we have) and, since it is a manual process, it is ripe for error, like we experienced recently when we were stamping builds with the number of the previous sprint. The challenge with this, is that this number is determined when the build is queued, so it isn’t something that we can change in a step of the build process while the build is running. VSTS has a great api that provides access to what the current sprint number is and an API to update a build definition (including presumably the variables that are set/specified in the build definition).
Enter Azure Functions which, like AWS Lambdas, allows code to be executed in the cloud. In the case of Azure Functions, C# and Node.Js code can be executed based on a schedule or some type of triggering-events and you only pay for the code execution and accompanying required CPU time. So the idea is, that we write the code to get the current sprint and update our build definitions and then specify the schedule so that is aligns with our 3-week sprint cycle. I’m sure there are other solutions (and I should ask the VSTS folks what suggestions they have for this particular issue – we can’t be the only ones right?) but this just seems like a fun opportunity to automate a tedious manual process we do repeatedly and to try out a new cool technology (Azure Functions code execution on demand).
Pretty simple continuation to my blogging habit, but I’m determined to make this a regular habit and challenge my thinking and growth by sharing and learning from others, even if it means I come off as a little foolish or simple at times. I am excited for tomorrow’s post though. I’m going to introduce some great material I became aware of any in a webinar I recently attended by Dan Ashby (and put on by the Software Testing Club) that will serve as something of a series over the next little while. I’m looking forward to it!
*Note that any posts on this blog are my responsibility alone and do not necessarily reflect the views or opinions of my employer.
I needed to get blogging again, wanted to try Azure, and so I thought I’d give Project Nami along with my Visual Studio Dev Essentials credit to host the blog, so here goes. The main topics for my posts will be my experiences as a software tester (with a DevOps focus) as well as some commentary on technology today and my experiences with a variety of those technologies (in particular Microsoft technologies but technology in general – hence the name of the blog Technophile Tester). I should add that I’m writing this on Microsoft Edge on Windows 10 Mobile (Lumia 950) using the Microsoft Continuum dock setup (lots more on those things later).
I’m sure I will get around to getting this blog dressed up a bit with a better theme and all, but it’s really designed to be less about configuration and more about having an outlet for my thoughts and opinions again. I hope you’ll add me to your RSS reader (you do use one of those don’t you 🙂 ) – otherwise I suppose you can subscribe via email to receive updates when I publish a new post (which I do hope you’ll do if you don’t use an RSS reader).