38

I think you can use: https://github.com/erikbern/git-of-theseus It can visualize the amount of code still in use since its conception. This is a graph of the Git codebase itself:


13

Tl;DR: Yes, it should if you practise technical excellence. Sadly often it doesn't. The current most popular Agile framework Scrum mainly focuses on process quality and project communication. If you get yourself a project manager transitioning to Scrum Master you will be in trouble, because they have no clue about internal or structural quality and why this ...


11

On browsing through the of @Niels van Reijmersdal answer, I found this written in the README Markovtsev Vadim implemented a very similar analysis that claims to be 20%-6x faster than Git of Theseus. It's named Hercules and there's a great blog post about all the complexity going into the analysis of Git history. So well lookup Hercules and go through ...


10

Well, SonarQube has a metric actually called Maturity, so, yeah. :)


7

It's an okay idea with some guidelines. QA code is software. And software engineering principles should still apply. Since none of the developers know protractor, they should be trained. They may be able to add tests to their application on their own eventually. As for who to code review, the frontend developers are probably a good choice. They might ...


6

First of all, whether a team member works part-time is irrelevant. Your team has a sprint backlog based on its velocity, which is variable for each sprint (dependent on team capacity for that sprint). If someone works only four hours a day, the workload for that person should be planned accordingly. Within the time allotted, everyone must do a proper job. ...


5

The goal is to find bugs while leaving time and money to do other things too. So a high-quality test is a test that finds bugs but doesn't require a disproportionate expense to write, maintain, or operate. Sometimes you can tell whether a test is low-quality just by looking at it. For example, if the test is buggy or written in a brittle way so that ...


5

I believe that the strongest instrument for filtering such a-low-quality tests is a code review. You can power-up your code review with mutational testing techniques which will help you to detect the tests which probably do not introduce any value to the overall project scope. Here is the example of mutational testing framework where you can pick some ...


4

You can't Not directly, because each feature is different, each application is different, and each developer is different. That said, there are some indirect measures you can use to approximate the information you are looking for: Cyclomatic complexity - in its simplest form, a measure of how many different ways through a given function there are. As a ...


4

There really is no link between 'agile' and code quality. At the end of the day, you have the same programmers writing the same code. Scrum or (Lean or Kanban) is to do with how they spilt it up, what order they do it in and reporting progress. I think what you should write about is the challenge of adding processes which add to code quality. (unit tests,...


4

Low quality tests When I think of low quality tests, I think of teams mis-applying or over-applying a single test techniques in a way that doesn't yield adequate information. I've provided an example below along with high quality tests. High quality tests I don't know of any summarized guidelines, although I could see a lot of value in this. I am ...


4

we DO want our customers to be aware of various traps when implementing Agile as well as false expectations. Rather than pitching Agile (noun) as a product, sell best practices and continuous improvement that will result in the customer being more agile (adjective), use business objectives or being more responsive to customers/users needs and issues. ...


4

Some thoughts: As you've noted, code smell by itself is not a bug, but can potentially cause bugs. Code smells can be a valuable testing tool for white-box testing. Detecting code smells and reviewing the code changes when white-box testing a feature or a fix can be quite beneficial. Code smells though generally are caught and fixed during the Code Review ...


3

I'd highly recommend you take a look at the Airbnb Style Guide. Although, it's a little long and has some subjective rules, you can easily pick out your favorites and apply them to your code reviews. Also, it's nearly impossible to remember all the JS rules and best practices so while you're coding I'd really recommend you use a linter like eslint. You can ...


3

It depends on the kinds of tests. High quality unit tests have the following characteristics They mock and stub out external dependencies such as the database They run fast They test a single piece of functionality High quality UI feature tests have the following characteristics They reflect real user usage, actions and workflows They do not fail ...


3

I have had a few interesting stories to tell: For a company I was working for, the team leader (also the scrum master) would ask for an extremely detailed report during a morning standup. Our stand-up normally took 1 hour to complete. When it was my turn, I would normally give a very brief description of what I have done, what I am planning to do. The whole ...


3

Why do you view it as 'Developer' reviewing 'tester's code? A team member is reviewing another team member's code is perfectly fine as long as vice-versa is also true and accepted equally. Having said that, All code is code, where the standard best practices can be applied and reviewed irrespective of any specific framework (Protractor) knowledge. I ...


3

Code style: Code style checking should automated with a linter (e.g. ESLint and good style-guide like airbnb). No-one should be allowed to push code unless they ran the linter and fixed the coding linting errors. This should save you a lot of time. Merge conflicts: Merge conflicts should be solved by the coder. I would expect before the push the latest ...


3

No, part time or full time should not affect the quality of the work. A well defined document with coding standards should solve this, it is never too late. Any kind of work in any way is done, small or large sprints should have the same standards, not having a quality standard can result in poor work that can lead to more work when later you need to ...


3

I think you got it mostly right, the best way to convince someone is by having data, proof and explanations. Look at it as a long and never ending journey and not a revolution, try to enjoy the way even if you don't yet see your end target. A few comments though- Before you implement a test for a bug you've found stop for a minute to think and evaluate. ...


2

It is a false positive since as you say we trust that it is closed internally by the JdbcTemplate. SonarQube has the assumption that the block of code that constructs a PreparedStament is responsible for closing it. You can use the SonarQube UI to flag this particular issue as a false positive. If you always rely on JdbcTemplate closing your PreparedStament ...


2

Although I think SAFe is not Agile at all, it just brings new words for the same roles, processes and probably no change, like you're describing. But SAFe does mandates Build-in Quality as one of its core values. So I am troubled you need to make a case for its practises in an SAFE environment. Sounds like it is time to talk the SAFe Lean Agile Leaders, ...


2

Some things which seem to have worked for the teams I've worked in: Get permission, record what you do of the below, then present the final result to your colleagues to get them interested in developing better tests. Make sure you don't end up insulting anyone's talent - we all have to start somewhere! It might be tempting for illustration purposes, but don'...


2

OOP concepts like encapsulation could make your life easier. Probably they help when multiple programmers work on the same code-base. If you are alone you might work in a single file, but as complexity and contributors grow it might make sense to apply good OOP principles. The term encapsulation is often used interchangeably with information hiding. ...


2

Recognize that there is a large organizational problem. Management have to change and give true leadership Talk to management about: quality developer morale developer training & education The risk of not having quality tests senior developers leading by example the affect on revenue (bugs and rework) the effect on customers (bug and rework) the affect ...


1

It's a hectic task to write the import statement repeatedly for each class file. Is it really hectic? This would make most developers maniacs if this was true. Learn how to use your IDE to help you speed up the adding of the correct imports. Bulk add imports for Java: https://crunchify.com/java-simple-way-to-import-all-missing-packages-at-once/


1

You can inject a factory for the behaviors you need from the packages you are importing* public interface WebFactory { public Element findElement(Locator loc); .... } The imports would be interfaces as well... public interface Element { public String getText(); ... } And then you can implement these interfaces by biding to Selenium however ...


1

How to improve Testing Culture: Mob sessions to help the devs start to go through worked examples and see what good tests look like vs. Bad so they can learn through examples. Code reviews, to go through change sets ans see what code has been commited and feedback to thr dev about the test added. Start hosting regular "lunch and learn" or "tech develops ...


1

A test at it's best is just a Boolean question to the SUT. In a similar situation, I would try to map each found defect( from defect database) back to these test cases. And will try to find out (as a team) did we ask the right questions and particularly what questions are missed out and why? If most of the tests are meaningless, then many defects will not ...


1

My experience is that it is easier to sell a team on changing a process after they see that their old process doesn't yield the desired results. They may recognize that something is wrong but not recognize that the process is the problem. You might help them by collecting metrics relevant to the change you want to make. Quantifying code quality is hard, ...


Only top voted, non community-wiki answers of a minimum length are eligible