-1

We have an IT department that deploys code and applications for the finance department such as automatically updating inventory in a website from our erp system.

We usually find that the code deployed has some errors, is it the job of other departments to verify that everything is working properly or is it the job the IT department to do the quality check and check their own work?

Usually the department has to hunt the IT department with emails to explain that that there might be an issue? If it is the IT department what is thisprocess called is this standard in the IT departments?

5
  • 1
    There are no hard and fast rules in business. It may be difficult for the IT department to test every feature properly. Bugs in software are not unusual at all. It's almost impossible to prove that non-trivial software is bug free. – Gregory Currie May 29 at 3:17
  • IT departments are usually not optimized for writing software. In a proper technology company, there is QA (at Microsoft, there 2 testers for every single developer), there is a person designated to represent the customer, there is an IT department to support the developers, there are analysts and designers, there is a separate database person, etc. In the IT department of a non-technology company, the IT department has a long queue of things to do, including DevOps, tooling, supporting other people's software, security, building software, upgrading/migrating other people's software, etc. – Stephan Branczyk May 29 at 4:00
  • @StephanBranczyk given microsoft software still comes out with bugs then two testers per developer is obviously not sufficient. – Solar Mike May 29 at 4:21
  • Can you clarify the "deploys code and applications" part? Did they write that? Then it's not IT, it should be called development or something. An "IT" department normally is in charge of deploying third party software. They cannot possibly find accounting errors in a third party software, they lack any accounting skills to know whether it works right. They can only check whether it opens, you can connect and work with it. – nvoigt May 29 at 6:16
  • Really I would suggest asking this on software engineering, or moreover, one of the SE sites that deals with testing, QA etc. – Fattie May 29 at 13:39
2

There are lots of different ways to handle this, but the answer is usually that the responsibility to ensure that the software is correct belongs to both the IT department and the customer (in this case, the finance department). The outputs of software development processes are usually of higher quality if the stakeholder groups collaborate during the development effort.

The finance department knows what they need from the applications and data. Ideally, it should be a collaborative effort between the finance department, as the customer, and the IT department to define what the expected behavior and attributes of the system are. As the system is being built, the IT department is responsible for ensuring that what they build conforms to their understanding of the requirements, along with identifying any ambiguities or concerns and clarifying their understanding of the requirements. After development, performing validation or user acceptance testing will allow the finance department to check the functionality and performance of the system against their interpretation of the requirements and report issues, which would be triaged.

The ability of the IT department to build what was asked for depends on their capability to perform requirements engineering, design, implementation, and testing activities. If the user acceptance testing regularly finds significant issues, including those that prevent the changes from going to production, one would have to look deeper at the development processes used by the IT department to find the causes of the defects and correct them.

1

There is no standard. Figure out what works for your org

In my last organozation, there were dedicated QA testers to check things. In my current company, it is mostly unit tests and a little bit of developer testing. At a company a friend was at, bugs were not really given much thought and just fixed as found/complained about. Another friend is currently are a contracting firm and they love bugs because they can bill more so they do nothing to prevent them.

I recommend the dedicated QA, but as that's the most expensive, you will likely need to settle for something else.

You should also have a bug reporting system as others have mentioned.

2
  • 1
    The contracting firm one is not surprising. This is why I vew contractant as the last option for anything.. – Al rl May 29 at 17:28
  • This. Also be wary of those that prescribe the "proper" way to do things. The proper way is the way that works well for the business, even if it causes pain for some segments of the business. – Gregory Currie May 30 at 1:32
0

We usually find that the code deployed has some errors, is it the job of other departments to verify that everything is working properly or is it the job the IT department to do the quality check and check their own work?

It depends on the company. Managers and bosses should have documentation saying what the departments of the company are, and what each one is responsible for.

An IT department should be responsible for doing their own quality checks before releasing software (Quality Assurance) however, there's a limit on what can be tested. Human error can't be completely eliminated, and only the recipient can confirm it meets their interpretation of the specification.

There are methods such as test driven development (TDD) and unit testing that can be automated with continuous integration, deployment and delivery pipelines (CI/CD). Implementing these methods can help reduce issues, but will never eliminate them completely.

Bugs are an accepted part of developing software and there should be very clear processes (ticket system / help desk) to deal with them.

In companies I've worked for, software is tested by the quality assurance department before release, and we always get the recipient (either internal department or a client) to sign off and confirm they've fully tested the software themselves and that it meets the spec before we release to production. This way if an issue is discovered, they can't just blame it all on us. They are also made aware of how to raise any support tickets if they find a problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .