Read Along- ‘Agile Testing’ Chapter-7

“Technology-Facing Tests that Support the Team”

A look at tests in Quadrant-1 – Technology Facing tests

Agile Testing Quadrants
  • Unit tests and component tests ensure quality by helping the programmers understand exactly what the code needs to do and providing guidance in the right design
  • The term ‘Test-Driven Development’ misleads practitioners who do not understand that its more about design than testing. Code developed test-first is naturally designed for Testability.
  • When teams practice TDD, they minimize the number of bugs that must be caught later.

The more bugs that leak out of our coding process, the slower our delivery will be, and in the end, it is the quality that will suffer. That’s why programmer tests in Quadrant-1 are so critical. A team without these core agile practices is unlikely to benefit much from agile values and principles.

  • Source Code Control, Configuration Management and Continuous Integration are essential to getting value from programmer tests that guide development.
  • CI saves time and motivates each programmer to run the tests before checking in the new code.
  • An advantage of driving development with tests is that code is written with the express intention of making tests pass.
  • A common approach in designing a testable architecture is to separate the different layers that perform different functions in the application.

Teams should take time to consider how they can take time to create an architecture that will make automated tests easier to create, inexpensive to maintain and long-lived. Don’t be afraid to revisit the architecture is automated tests don’t return value for the investment in them.

“The biggest value of unit tests is in the speed of their feedback.”

  • Each unit test is different and tests one dimension at a time
  • Learning to write Quadrant-1 tests is hard.
  • Because TDD is really more of a design activity, it is essential that the person writing the code also writes the tests, before writing the code.
  • To Managers—
    • If a delivery date is in jeopardy, push to reduce the scope, not the quality.
    • Give the team time to learn and provide expert, hands-on training.
  • Technology-facing tests cannot be done without the right tools and infrastructure

How Technology Has Changed Project Management

The use of advanced technology in business environments can sometimes be jarring. Adjustments can be difficult, and on top of that many employees across a range of industries worry that technology can make them obsolete. These can be legitimate concerns in some cases. But, more often than not, technology serves instead to simplify processes and, ultimately, make life easier on people as they go about performing their jobs. This is certainly proving to be the case where project management is concerned.

Project management demands and processes vary across different businesses and industries, which means that not all teams in this category can implement modern technology in exactly the same ways. Here we’ll examine a few key ways in which tech can and has changed project management for the better.

Communication & File Sharing

Maybe the biggest change that technology has brought about for project management teams is a simplification of communication among groups in a work setting. In 2019, our post on ‘Overcoming Barriers to Effective Communications in Agile Teams’ touched on the idea that various barriers to regular communication can negatively impact productivity. And the same is absolutely true for project management teams of all kinds.

Now, however, there are several different communications platforms that are being used in professional environments to streamline collaboration. Often enough, they’re used to simplify digital communications in office environments in general, providing a space where everyone from a manager to a part-time freelancer can log in, see shared information, engage in relevant chats, and generally stay up to speed. These platforms can also be invaluable for project management teams.

For instance, think about a fairly common project such as developing a website or an app for a business. These are projects that involve contributions from people with different skills in conjunction with one another. A page design can’t be completed without understanding of the content layout; content layout can’t be finalized without a thoroughly developed visual aesthetic, and so on. On these modern communication platforms, these matters can easily be discussed between relevant parties such that the greater project can move forward. Updates and examples can be shared, and people can easily work with relevant collaborators whenever they need to.

Collaborative Design

In the past, one issue that plagued some project management teams is how to get everyone on the same page in more multi-faceted projects. There haven’t always been structured ways for different aspects of one overarching project to be addressed in a cohesive manner. This is changing, however, thanks in large part to both abstract and specific software.

Read More »

5 Mistakes to Avoid When Adopting a New Tool

We are all forever on the lookout for better and faster ways to achieve our quality goals, and adding new tools to our suite often seems like a good way to do that. However, introducing a new tool to an already working environment may be tricky and could require some special considerations.

In my latest article for @Gurock website, I take a look at five common mistakes teams make when adopting a new tool, so we can be sure to avoid them. My write-up has been published at TestRail blog here -> https://blog.gurock.com/5-mistakes-tool-adoption/

The main mistakes in tool adoption and their prevention steps that I have discussed in this article are:

  • Jumping in without a POC
  • Not testing the tool in a Pilot Project
  • Performing the wrong Profit analysis
  • Rolling Out adoption all at once
  • Neglecting Continuous Learning

Read the full article and let me know your thoughts!