30 Days of Agile Testing – Testing Toolkit

30 Days of Agile Testing – Testing Toolkit

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

What is in my toolkit?  What kind of tools do I and my team rely on and use to help us at testing?  I recently got a new laptop and so maybe I’ll just go through some of the tools and programs I installed on it in the last couple of weeks as examples of the kinds of tools I find useful.

Git

Version control systems are a part of most software development team’s tool kits. Knowing and understanding how they work and how to effectively use them can make them a powerful testing tool.  I have been spending some time in the last few weeks learning more about how to read and parse the git log and I’m working on some scripting around it so that we will be able to glean data and insights about changes to our tests and the health of our automation system.  Don’t just treat your version control system as a way to safely make changes, treat is as a way to get information.

Process Explorer

Seriously, if you are a tester and if you haven’t yet tried it, you need to try out process explorer.  As a tester you need to be able to understand what is happening with the various processes on your machine, and process explorer opens this world up for you in a way that Windows task manager can’t.

Everything

This little file search utility is another extremely useful program for a tester to have. How many times have you tried to figure out where your software saved something or if new files have been created somewhere?  This powerful, lightweight search utility has pretty much instantaneous search results and has helped me out so many times.  Another tool I would recommend every tester add to their toolkit

Notepad++

My text editor of choice is Notepad++.  I have tried a few others and I have heard a lot of good things about Sublime text or Visual Studio Code, but so far I haven’t found them compelling enough to switch.  Custom syntax highlighting.  File comparison addons. Find and replace across many files.  Regular expression search capability (if you are a regular expression kind of person).  Some automatic formatting and auto-completion options. There are a lot of powerful and useful features in this text editor and yet is pretty snappy and lightweight.  For the kinds of things I usually do, I find it to work quite well.

Python

Is this a testing tool?  Heck yes!  It’s the most powerful tool in my toolbox.  Now admittedly it’s a tool that takes some time and skill to learn, but once you’ve grasped the basics of it (and this applies to other scripting languages like Ruby), it let’s you leverage yourself in ways you never could have otherwise.  There are so many one off simple tasks a tester wants to do and that you can’t find a specific tool for, but which you can accomplish with a few lines of scripting.  For example we recently had a list of (hundreds of) files that contained specific commands in them and we wanted to run the corresponding tests for those.  There is no tool that could do the conversion, but after 15 minutes with python we had a script that could help us out with this.  Add a scripting language to your testing toolbox!

Sqlite Browser

Sqlite is the database format used in the built in database modules that come with python, and over the years I have written a few webpages that use these kinds of databases.  When trying to debug problems or understand what is happening as we add new features to the webpages, I find sqlite browser to be a very handy and powerful tool.

Phrase Express

I have been using texter for years and I’ve come to depend on auto-completion of certain strings.  With my new (Windows10) laptop, I finally got to the point where the lack of ongoing support for texter caught up with me and so I had to find a new utility.  I’ve been trying out Phrase Express and so far it has been pretty good. It isn’t as lightweight as texter and to be honest, has a lot of functionality I don’t need or use. I would have preferred to have something with less features, but now that I’ve figured it out and gotten it setup the way I need it, it does a decent job.  There are still some little quirks that I don’t like, but the value of being able to define certain keyboard shortcuts that automate some of my typing for me makes this program well worth it.

There are many more tools I use and rely on as a testers (for example I haven’t included any online tools in this list).  A tester should have  well stocked toolbox. What tools do you have in yours?

Advertisements

30 Days of Agile Testing – Helping the Team

30 Days of Agile Testing – Helping the Team

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

Yesterday’s challenge asked how I could make my job easier and today’s asks how I can make my team’s job easier.  I’m going to cheat and use yesterday’s answer today – Automate.

Well, only a partial cheat, because there are actually two teams I want to talk about.  For the first team – my testing team – I think the ‘automate’ answer sums it up well.  There are things I can do (and am currently looking into) that I hope will help the team get better at understanding our tests.  The fact is that many of the things I automate for my own purposes can be shared with other testers and help them out as well, and so when it comes to the testing team, I can probably help them out with my scripting skills.

When I think of my other team – the development team I’m embedded with – my primary skill set isn’t to automate things.  Everyone else on the team writes code far more often than I do and they are well able to automate the things they need to.  The ways that I help this team have little to do with creating scripts, and more to do with reducing friction in our processes.  I want to reduce the number of steps and the amount of time it takes to get code into the main branch.  I want to reduce the friction around running tests.  I want to be able to give more rapid and timely feedback. Along with building a stronger team spirit across development and testing, smoothing out our processes is one of the primary ways I can make life easier for this team.

 

 

30 Days of Agile Testing – Make Testing Easier

30 Days of Agile Testing – Make Testing Easier

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

How can I make testing jobs easier? Automate them.

I might be getting into a controversial area here, but really – automate them.  I’m not saying we should (or could) automate away the role of a tester.  What I’m saying is that there are many ways that we can use automation to make life easier. Automate the boring stuff so we have more time to focus on ways to add value.

I have done this for many things in the past, but there is always more to do.  Right now, my ‘make testing easier’ work revolves around trying to automate some ways to get better information about our tests.  We have a lot of automated regression tests and trying to understand how to best manage and maintain them is daunting task.  We have been working through many of them manually to clean them up but this is obviously a time consuming process. I’m currently look at ways I can pull some data from git log and from our reporting systems to help us better understand which tests to cleanup and/or remove and also to allow us to better monitor the overall health of our tests going forward.

How do you make testing easier?  Figure out ways to use tools or scripting to leverage your skills.  Figure out ways to effectively solve problems.  It takes some work, but it can be done!

30 Days of Agile Testing – Lean Testing

30 Days of Agile Testing – Lean Testing

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

How can you make your testing more lean?  The more of these challenges I do, the more I realize why they are called challenges.  It certainly is a challenge to figure this out. How can I make my testing process more lean?

A Theoretical Objection

I guess another way of saying this is, what waste can I cut from my testing process? My first instinct was, ‘I’m always trying to cut waste – is there more to cut?’ But then in thinking about it more, I realized that keeping a lean process is kind of like keeping a lean body – you need to work at it. If you ignore it, it will start to accumulate fat and waste. Over time, the exact same process will change from being lean to having a lot of waste. The software world is always changing and so our processes need to change as well.

What to do?

So with the theoretical objection out of the way, what fat can I cut from my testing processes as it sits right now? Hmm, I think I want to re-frame this again:  what problems have I recently faced that might be improved by changes to my testing process?

Well, the last iteration I’ve felt like I don’t have much to do. You might be jealous, but I think this represents a problem.  We’ve cycled from a high stress ‘must release now!’ work environment to one where there isn’t much too much to do while we wait for new projects to ramp up.  This is a general process problem that goes much wider than my testing process or my team’s process, but given that this is the reality I’m in, what can I change to address this issue? Much of my testing process revolves around getting builds, testing them, and giving feedback on them. That doesn’t work in the current context. For much of the work I’m involved with right now there aren’t any builds to get and test. If I want to smooth out the workload I need to figure out a process that helps me get ahead on work while there aren’t yet code artifacts.  I think this leads to two tweaks I could make.

Code Reviews

Code is still going in and getting reviewed.  By shifting a bit more of my time than usual to reading through code reviews, I will not only get a better grasp of what is going on in the project right now, but I might also be able to give some feedback at this earlier stage. I need to shift my process toward more engagement with other code artifacts like code reviews.

Builds and Infrastructure

Another way I could shift my process is to leverage the skills I have around getting builds setup and running and on getting testing infrastructure in place.  I could shift my testing process towards spending more time on those activities, both in getting better at them and in helping the team to set these things up so that I can get code to test sooner.

So how can I make my testing process more lean?  By changing the emphasis.  By moving a bit away from ‘just testing’ to thinking about other areas of the project that are hurting right now, and by shifting some of my activities into those areas.

30 Days of Agile Testing – Delivering Customer Value

30 Days of Agile Testing – Delivering Customer Value

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

How  do I as a tester deliver customer value? And what can I do to increase that?  Today’s challenge is no small topic to tackle.  Sometimes it can feel like the work that we do day to day is disconnected from our customers.  Sure, we are always trying to think of them when testing and tie our work and issues found back to them, but at the end of the day (in our company at least) we don’t have direct access to them.  So how do we go about delivering customer value?

Well, what do our customers want?  They want software that helps them solve the problems that are trying to solve and that creates value for them.  To over simplify it, what our customers want is working software.  As a tester there are many things that I can do to add value into that process.  I can explore the software to find out things that might threaten it’s value proposition to our customers.  I can also consider how to help get the software out the door more quickly – after all our customers aren’t interested in potential features, they want working software.  I can also work on establishing better team dynamics and practices that help us get more efficient at producing valuable features.  I can learn about what our customers actually do with out software.  I can do many, many different things that can all add value for our customers.

Let’s take this out of the theoretical realm though.  How can I specifically in the particular context I am in right now increase my value add?

One of the projects I am involved in is a longer term ‘replacement’ project and when looking at something that has probably a year or more of development work before getting released there are a lot of challenges.  One of the ways I can really add value to the project is in helping the team to more quickly produce working software.  What I mean by working here isn’t something we would ship to customers, but something we can share with other testers and managers.  Something that will let us better establish where we are at as a team and where we need to go.

I am convinced that by having this we will be able to (a) figure out what the minimum shippable feature set is more quickly, (b) improve our ability to understand how close we are to that (c) keep the code health better due to improved feedback along the way and (d) ultimately complete the project to an adequate level more quickly. To take this down to the brass tacks level, working with my team on getting a build pipeline in place is actually one of the best ways for me to add customer value in my current context.  The line from my actions to the customer is long and wiggly, but when you’re a tester you need to think of the big picture.  These kinds of things matter for our customers.

 

30 Days of Agile Testing – Developer Tools

30 Days of Agile Testing – Developer Tools

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

I’ve been poking at today’s challenge for a little while already.  I’m interested in tools that developers use and I have tried to use some of them.  In particular (as the challenge mentions), I’ve tried using IDE’s.  I recently downloaded Visual Studio and set it up to use when writing some of my scripts.  I wanted to get a feeling for what it could do and in particular to see if I could get ReSharper working since I’m interested in learning a bit more about static analysis.

I used it to write a few scripts that I’m working on for analyzing our automated tests and my honest opinion is that I didn’t find it to be compelling.  In the first place, I couldn’t get intellisense to work for python scripts, so that really hurt productivity around autocomplete.  I’ve also been a pretty high end user or Notepad++ for some time now and so I’ve learned a lot of keyboard shortcuts that enable me to do things really quickly in there.  I kept hitting those and causing weird things to happen in Visual Studio. That is just part of the learning curve of a new tool I suppose – I found the same thing really difficult when I moved to using google docs instead of Word for example – but it still didn’t endear the tool to me.

Visual Studio has some things that look like they would be really helpful, like git integration for example, but in general I don’t like tools that do too many things.  I would rather have a tool do one thing really well and let you find other tools that do other things really well.  Tools that do everything tend to be too hard to learn and Visual Studio was certainly no exception there.  I have a lot of automation built up around my git workflows and so I didn’t like using that integration in Visual Studio.

I don’t think Visual Studio is a tool that will use in my regular day to day work, as it is too ‘heavy’ for my way of working, but I will continue to explore it.  I found some of our development team’s documentation on how to setup our development environment and so the next task I’ll be looking at is trying to set it up and use it for a developer workflow. In addition to the learning experience, I hope this will also give me more insight into how the developers on the team work and what I can do to better support our team in achieving shippable quality more quickly.  Maybe eventually I’ll even be able to try out ReSharper and figure me out some static analysis.

30 Days of Agile Testing – Test Documentation

30 Days of Agile Testing – Test Documentation

Note that this post is part of a series where I am ‘live blogging’ my way through the ministry of testing’s 30 days of Agile Testing challenge.

Want to start an argument in the testing community?  There are plenty of ways to do it, but one it to start talking about test cases.  What are they? Should we use them? How should we use them?  The arguments can go on and on.  The reality is there is a lot to think about when it comes to effective test documentation and the discussions around test cases really plays into this a lot. Often the purposes of test cases are seen as showing what work was done and enabling us to go back and check that the code has not regressed.  When thinking about test documentation we need to think about what we are trying to achieve with it, and both of those purposes are important.

Re-running Tests

The question is how do we most effectively achieve them?  Do we need to go back and be able to repeat every test we’ve done?  Heck no.  Think about it.  Let’s say you spend 20 hours one week testing the product, and let’s say those tests are recorded in a way that let’s you go back and re-run them.  What happens next week?  You do 20 more hours of new testing and you run the previous 20 hours of testing – your week is full.  OK so what about the next week?  now you have 40 hours of old testing to get through.  Clearly you will not do it all, and the more new testing you add, the less you will be able to do. Taking the thought process to it extreme conclusion shows us that you cannot reasonably expect to be able to repeat every test you do.  If this is the case, does it make sense to do the overhead of detailing out tests in a way that makes them repeatable?  Nope.  So when it comes down to it, we try to record in a detailed manner only those tests that we know we will want to repeat multiple times, and for us that is done in automated regression tests. Yes, I would consider automation scripts to be test documentation.  They record (document) that testing done, how could they not be?

Demonstrating Coverage

So what about the other part of the equation?  What do I do to show and record what work was done?  I think I’ve mentioned it before, but I primarily use light weight documentation of the work I did.  A few bullet points that show what I hit on and why it was interesting to do that. Some checklists of ideas that were considered.  Notes from discussions with teammates on what the feature does.  The documentation doesn’t need to include a lot.  It needs to include enough for me to have an intelligent conversation about it in the future if  I’m asked and enough to convince myself and others that I have sufficiently tested the product.

Improvements

Nobody is perfect and my test documentation is no exception.  What changes could I do to make it better? I like the way I’m currently doing thing and it seems to fit in well with the context I’m working in so I wouldn’t make any major changes at this point. I think if I were to make any tweaks it would be towards  rolling things up.  How do I better roll up and summarize what I have done so that it is more accessible to others?  Sometimes my notes are written in a way that I understand but are cryptic to others, so I will continue to experiment with small changes to improve on what I’m doing.

How about you?  How do you document your testing?