Overview

I have recently completed a secondment to the Business Operations (Bus Ops) department within Scott Logic. Before I joined the team, I did not have any understanding of what the team did. However, that understanding soon changed within a month of joining and continued to uncover new paths for the duration of my secondment.

When I joined the team, I was astounded as to how much reporting is required within the Bus Ops team. I quickly decided to buy a course on data analysis with the intention of understanding how data analysts properly analyse data. There was an added determination that I would like to take this to the next stage and start studying data science, which I believe is the next big thing as it slides directly into Artificial Intelligence (AI) and Machine Learning (ML). I really believe we should now start to focus our efforts on AI and ML, as they are the next big players within the industry.

Discussion: Business Operations

I found out that the Bus Ops department is classed as “silent running”. This means that they always help to protect the business, make sure reports are sent out on time, legalities are taken care of, staff have work to do and that they are contactable and approachable at any point in time. The team needs to be silent running because the business (our own company) is their client, and they need to ensure the business runs smoothly. Bus Ops want their consultants and clients to have a good experience at all times. Therefore, when Bus Ops activities run smoothly in the background it helps the business to run smoothly in the foreground. This shows they play a vital role in the organisation and perhaps go unnoticed.

On my chosen course I learned definitions such as “Big Data”, “Data Cleansing”, “Data Marts”, “Data Lakes”, and “Data Pipelines”, as well as learning what it is like to be a data analyst. It really helped me to understand what I could expect in the department. These are all terms I had heard before, but I never had to dive deeper until now.

After having initial chats with the team, and upskilling via online learning, I felt prepared to embrace my new role. It felt like it was going to be something a bit different from testing. But was it different…? Not entirely!

I took on the responsibility of Business as Usual (BAU) activities as my core task. This included analysing daily reports, weekly reports, monthly reports and quarterly reports. The reports were slowly handed over, so I could get used to the data I needed to analyse. This gave me an opportunity to get used to what the data meant, what needed to be reported on and most importantly I needed to understand why the data had to be distributed to stakeholders. I had to make sense of a new world - a world full of data! I had to organise myself differently, learn to read larger volumes of data, learn to read distributed data, learn when reports needed to be submitted to be meaningful to stakeholders, and finally work out how to collaborate slightly differently to ensure stakeholders acted on outstanding activities. Most importantly, I realised this needs to be documented with simple “How to Guides” to ensure anyone could re-create the steps required.

When I completed the scheduled reports on time, there was a sense of achievement that I met expectations. There may have been an inner thought of “how many tickets can I clear off my board per day”, silently being played in the background. I also learned to be okay that some tickets hung around a little bit longer, which was hard, as I always wanted a clear board by the end of the working day and/or working week. Some tickets were a bit more complicated and had a longer story behind them. Those tickets may have been a request from someone in the business and further investigations were required. Alternatively, perhaps it was a new report that would become a regular job, such as a daily/weekly/monthly report, which I didn’t quite understand how to analyse yet.

When I didn’t complete certain activities on time, I could see the impact on the business. Stakeholders did not get their messages on time, so financial reporting and tracking periods were impacted. There was a sense of responsibility that the data meant something to others, even if I did not fully understand it at the time. However, it soon created a story of “Why does this task need to be done?”, which helped promote efficiency in delivery.

I continued my expansion into the team and learned about ISO 27001. ISO 27001 is an international standard to manage information security. I became responsible for auditing tickets relating to Change Management, Risk Management and ISO Standards. There was a precedence set that every month and every quarter these meetings would take place, and suddenly I was drifted back into the world of auditing, to what I had done in former years with the Capability Maturity Model Integration (CMMI) and Test Maturity Model Integration (TMMI) in previous testing roles. The emphasis was on maintaining standards that had been implemented and reporting any deviations to the team and external auditor.

Quick Reflection

So, let’s just pause here and analyse what we’ve just talked about:

We’ve talked about upskilling, clients, data, reporting, stakeholders, documentation, problem solving, collaboration, delivery, acceptance, making mistakes and auditing.

As a tester do these points look familiar to you? It does to me!

Let’s be curious and take a closer look together.

Discussion: Testing

In this section we will examine the topics listed in the ‘Quick Reflection’ section and align them to the world of testing. We will look at each item and understand how they intersect with and impact the testing process. Through this exploration, the aim is to deepen our understanding of the shared facets and identify why they are prevalent in Software Testing.

Upskilling

When working on any testing project, there is always the need to upskill. In consultancy work, clients ask for different technologies, programming languages, products, and other skills. It can be difficult to keep up, but we must inculcate a sense of responsibility within ourselves. We have chosen the IT industry as our career, an ever-changing industry, and we must “keep up”. We must see the “here and now”, but we also need to be strategic and predict which direction we need to move to next.

Clients

A client is someone who uses the services of another. In our case, consulting, this is mainly organisations, meaning we need to produce work to align with their end clients’ needs and subsequently collaborate within in-house software teams to deliver the product that is required for their customer base. They have asked us for our expertise, and we must deliver products to meet their needs, so that they can continue running their own businesses.

When working with clients, it is incredibly important to build a good relationship with them as that makes interaction more successful and promotes trust. Building trust with a client is crucial in building long-term relationships, as well as having honest conversations, creating client satisfaction and resolving any issues.

Data

We spend a lot of time in testing working with data, whether that is creating data, analysing data or outputting data into readable formats. Data provides information that can be used in a variety of ways including assessing some quality criteria. It is possible to test without data and problems will be uncovered. Data is the heart of scientific evaluation, which is one method of testing. Test data helps to identify any defects within the code before releasing the product to the client.

It is imperative that during testing, we check that the data is stored accurately and securely within the remit of the project and must follow General Data Protection Regulation (GDPR) standards. This is important as we need to comply with the government regulations to prevent fraud, loss of data, malicious use of data. Any incorrect use of data could lead to legal issues and could give other businesses a competitive advantage.

Data can show us how the business is performing, but it can also be confidential, and clients want to know that their data is safe. There are many stories of data attacks in the news these days, and the further we work in digital technologies, the more we must pay attention to our clients.

Reporting

Reports are often produced in Software Testing as a form of communication with colleagues, teams and to the business. The most common written reports include:

Progress Reports, Execution Reports, Regression Reports, Defect Reports, Summary Reports and Closure Reports. However, more recently, verbal reporting seems to be more common, e.g. in standups and retrospectives. I will write a separate blog about the importance of test reporting.

Test reports provide information that can be used to assess quality along with other information provided by testing as well, which can help the client and development team work out when to release the software and whether the product meets business requirements.

Stakeholders

Stakeholders can include (but are not limited to) the development team, delivery management, product management and the actual customer. Stakeholders significantly influence software testing as it provides different perspectives, involvement, expectations and decisions.

It is extremely important to understand who the stakeholders are so that all needs can be addressed. From a consultancy point of view, the consultants advise the client on the best way of doing things. A definition of consulting by Jerry Weinberg is: “Consulting is the art of influencing others at their request”. The clients may have their own ideas, but the clients can be guided by the consultants, which helps to solve problems that they are struggling with and enables the consultants to promote best practices.

The Product Managers sign off the work to ensure it meets the requirements. If regulatory bodies are involved, then standards need to be adhered to due to legal requirements. Delivery Management ensures that time and budget is accommodated so the project remains on track at all times.

Documentation

Documentation is crucial in software testing as it allows planning, designing, execution, tracking and closure to take place. It can include errors, so it is important to keep any documents up to date, where possible. Documentation can be used more loosely to provide guidance, such as coding standards, process diagrams and ways of working.

In the planning phase, Test Strategies and Test Plans will be created to outline the overall approach for the project. Test Design can include Testware documentation, but it can also be about thinking critically, challenging assumptions and being creative to uncover information. Execution can occur with test ideas, but they don’t have to be documented. If Testware exists, then tests need to be recorded as passed/failed and have associated defect reports. During the closure phase, a Test Summary report documents a summary of the testing activities and an outcome of the overall testing process.

Problem Solving

Problem Solving is a critical part of software testing, it helps testers to address challenges and ensure good quality software is being produced. It helps testers work out whether something is a defect, handle ambiguous requirements by learning to ask the “right” questions, find the root cause as to why something occurred, create better Testware, deal with environment issues, write automated scripts, manage test data and collaborate with others to explain the testing stance.

Problem Solving occurs during the professional day and contributes to the decisions we make. Therefore, reflecting during and after tasks as well as collaborating as a team helps us to improve problem solving skills.

Collaboration

Collaboration tends to enhance the overall quality of the software being produced when requirements are understood. It helps to streamline processes, network with others and ensures the final product meets the expectations of the client. Collaboration amongst team members creates a supportive environment whereby it promotes good communication, knowledge sharing and working towards the same goal.

Working as a team enables the team to have a better understanding of the required tasks. It allows for early involvement and for the team to share their understanding, which means that everyone is responsible for quality rather than just the testers. It enhances skillset by being exposed to different areas of the project and subsequently aids in defect resolution.

When collaborating on complex scenarios, it can help to work out the best approach. Collaborative brainstorming helps to allow team members to be creative as every idea is always welcomed. Also, it enhances the skillset of individuals within the team to be innovative and explorative, which helps to fine tune testing skills.

When a team works well together, there may be pertinent interaction with the client to keep them up to date with what is being produced.

Delivery

In an ideal world, delivery of the software occurs after as much testing as possible has been done, but this is not always the case due to time/budget/criticality of fixes, to name a few. The software has gone through rigorous testing and then is deployed to production environments. Delivery processes can contribute to ensuring software meets quality standards.

The delivery process includes verification and validation of the software, release reports, delivery of test results, sign-off from Product Owners/the client, deployment to the production environments, delivery of documentation. Once it has been deployed to the clients’ systems, the client may have feedback or amendments that need to be adhered to.

Acceptance

There are multiple layers to the process of acceptance within testing, which ranges from validation of software functionality to interpersonal dynamics. Acceptance testing means that the software is ready for release and meets the necessary requirements and is often performed by users. Acceptance can mean understanding why certain decisions have been made even if individuals do not agree with them.

Acceptance Criteria is used to test against requirements to measure the validity of the software. Testers use the requirements to design test cases and check the implementation as per the clients’ needs. Acceptance of test results is important and may involve the client if discrepancies arise, which means testers may need to reframe how they perceive the implementation.

User Acceptance Testing (UAT) is conducted by the end users to ensure that the software meets requirements. Often it occurs in a pre-production environment, to resolve any issues before releasing to production. However, it can sometimes occur in previous environments, or later environments, such as production. Correcting issues in production is more costly and disruptive to correct.

Acceptance of ideas and concepts can be more challenging as it leads to a subjective nature. Teams often face different viewpoints typically based on role or their worldview. Ultimately, this means that understanding the situation is vital to ensure that the best decisions are being made based on the knowledge they have at the time of the decision. Of course, decisions can be made, points can be proved, and changes can occur later on. Sometimes compromises must be made, alternatively majority decisions need to be taken forward, which can be cognitively or emotionally difficult if someone fundamentally disagrees or can see how the decision will impact the project further down the line. In addition, trade-offs may occur due to a range of issues, e.g. time and budget being the most common, and testers can acknowledge that business decisions, priorities or constraints take precedence, and testers can adopt their strategies when needed.

Making mistakes

Making mistakes is critical to our growth and development as professionals. We cannot just learn from other peoples’ experiences; we must learn from our own experiences as well.

I want to be the first to tell you: “it is okay to make a mistake”. Let the mistake happen, reflect on it and work out how you will do it differently next time. If you make the same mistake again in the future, that is also okay, as maybe you needed a little bit more time to understand. Be compassionate with yourself during this time.

Auditing

Auditing can take place in varying forms, e.g. via process models or documentation, especially in regulated industries. When documentation is heavily audited, e.g. when following ISO standards, the auditor ensures that protocols are followed. This ensures that all documents are reliable, accurate and up-to-date and comply with standards such as quality, accuracy and validity. Auditors make the decision whether standards have been adhered to and will subsequently be awarded/maintain/lose certification.

Testing processes may fall into other Delivery auditing procedures, e.g. risk management. The tester needs to be aware of both the auditing requirements for the testing project as well as for the delivery of the wider project.

Internal audits can be done by other testers, typically Test Managers, whilst testers contribute to the material being assessed. When internal audits have taken place, external auditors will assess the same material and make any recommendations as well as listing the work as compliant or non-compliant.

Conclusion

Bus Ops contains a significant amount of data that needs to be analysed on a daily basis. It is a silent running department meaning that the business runs smoothly. The data submitted by the consultants must be timely and accurate, e.g. timesheets. This allows the data to be transposed into meaningful data for billing clients. Furthermore, it ensures that revenue can be predicted, and financial tracking periods can close on time. It has a big responsibility to create the highest level of efficiency possible within the organisation to help support staff and maximise revenue. It is the department that focuses on “running the business”; without a Bus Ops team it would be a challenging effort to make sure that everything is delivered on time and to the highest standard.

Testing intersects heavily with the skillsets that are needed within Bus Ops. Using core concepts especially relating to test design, data analysis, problem solving and collaboration means that testers can contribute to more than just testing software products. When testers are taken out of their testing role, their detailed nature and innovative approach means they can streamline operations and provide a unique view to other departments to help them work more efficiently and effectively. Ultimately, this means they can adopt new ways of working by recommending changes in process management, solution generation and workflow management. For the individual, it helps to broaden their horizon and understand how different departments are run and it is useful to see products being used in action rather than following testing methodologies in a rhythmic-like pattern.

By recognizing and harnessing the synergies between these worlds, we can elevate the standards of our testing practices but also enhance the efficiency of our overall business operations. By understanding both worlds, it is clear how they overlap and how software testers can support the business when working on client projects.