What can you do about improving the coding when you are a test manager?

@KingaTest

The idea for this post came up recently on the quite fruitful meeting, on which it was discovered that the code quality in the project is quite good, according to tools the team is using – is impressive and looks ‘green’ 🙂

On the other hand, when we’ve analyzed the other code metrics – it turned out that the cyclomatic complexity is not so great.

If you are not familiar with the term, cyclomatic complexity is used to measure the complexity at the class or the method level. It is a quantitative measure of the number of linearly independent paths through a program’s source code. It helps to keep the code in as testable and maintainable way as possible, by indicating unnecessary complexity.

Example taken from https://craftofcoding.files.wordpress.com/2014/11/cyclo_complexity.jpg

In the project, I am thinking of, the complexity goes up, completely unnoticed. It may mean that there is no one in the project, who pays attention to the overall coding progress and its’ quality. Developers to their job, use Sonar Cube to check their recent changes and when no bugs are discovered, they are happy with the result.

https://thewarrencentre.org.au/wp-content/uploads/2017/02/must-cat-yarn-960×447.jpg

The question is – what can you do about the code quality when you are not a developer? There will be always a person, who claims that he knows better and in fact, you know nothing about the coding.

Our simple answer during the meeting was – you can check the metrics and then talk to people who can do something about the coding quality.

Is it always possible? Only in the projects where all of your code is covered by good metrics, which measure something and when your team write unit tests that test the code – not to pretend that they do 🙂

Each project is different and each is a challenge for both – developers and the testers – but every time you wish to improve the quality – it is possible.

Testing management is still quite a big unknown for me, but I still try to act like a tester but behave more like a manager.

I spend some time every day thinking of how to test differently, explore, how to x-ray the code to get more information about vulnerabilities and flaws. What helps me out? A set of tools that I use on a regular basis – they may not be always associated with testing, but I found them very useful – from a management perspective.

The first one is Jira plugin X-Ray and the second is SonarQube. I am sponsored by none of them, I just find them ok and worth to use.

X-Ray turned out to be a nitty-gritty tool when you use Jira daily. It just adds value to your work. It gives the opportunity of managing all test cases, not only the automation but the manual ones as well – all in one place, with pretty visual reports. I like it, my bosses like it, you should try it.

I’ve also discovered, that SonarQube may not necessarily be just a tool for developers, but also useful toy for the quality manager. I check Metrics and Activities tabs and look for points for improvements.

I don’t mean spotting the obvious errors or bugs – I mean rather mean hunting for vicious code in the project and implying the constant need for improvement.

If you have anything to to with the test management or quality assurance as well- I recommend this short exercise for you every day: start your working day from a short trip around different metrics – nightly builds, code coverage, cyclomatic complexity and so on. I guarantee that every day there can be a discovery that you can later address to improve the quality and stability of your product. If you tend to forget the obvious, as I do, make yourself a reminder in your calendar. It will help you structure your work and do better every day.

Managing, checking, metrics blah blah blah – “Do you fix it on your own, girl?” hahaha.

Here comes this harder part of the job – when you approach people and kindly ask for help or advice. I think that testing, managing or whatever is always about talking to people and working for the same goal – good quality. So the reports themselves or improved cyclomatic complexity won’t make your project better or worse – the point is what would you do about them and what you can achieve as a team. But this is a completely different story 🙂

If you would like to know more about tools that I use or if you have a better tool to recommend – just let me know in the comments section below or on Twitter.

Advertisements

It is (sometimes) a good idea to automate your regression testing

 

Desejando-lhe uma

Let’s start from Wikipedia’s definition of Regression Testing:

Regression testing is a type of software testing which verifies that software, which was previously developed and tested, still performs correctly after it was changed or interfaced with other software. Changes may include software enhancements, patches, configuration changes, etc.

Now, when we are aware of what is all about, let’s get to the point.

How often do you proceed regression testing? Once per sprint? Once per month? Daily?

Here we are. If our regression testing is supposed to make any sense – it has to be performed as often as possible – at least on sprint basis. Ideally – daily. Why? Because  stable test suites would catch any unexpected system behaviors and react to a major change.

Minions-at-work

There is yet another question – how big your system is.

Small systems usually have rather checklists than test suites. Large ones – even the monsters:)
Deciding what should by automated  is always tough, because having automated test scrips may be just something you could show off with or present in front of the customer. I would rather ask: WHY do you want to automate anything?

The problem is that sometimes automated suites don’t test anything (or anything meaningful) and the effort to keep them alive is big.

If you wonder if it’s worth to automate repetitive stuff? I’d answer – sure mate!

Automation is good. But it is just another tool – NOT THE PURPOSE.

AUTOMATION

I think that automated regression tests might be brilliant and helpful, but you have to remember that you’ll have to take care of them and update them often. You’ll also spend way more time to prepare test suites than to proceed simple tests manually, so if the testing is not repetitive – it’s good to calculate what is more beneficial for your project.

When automating things – you improve your skills and gain time for other activities – so it’s basically a matter of time – the time you’ll save on running automated regression testing and time you’ll waste (it’s not wasted, I know) on preparing them.

I’m just the beginner , so I might be wrong. Don’t agree? Comment below or stalk me on Twitter.