In 2015, London was shaken to its foundation by Bloomberg’s software failure that affected over 300,000 traders worldwide. The same year, the Royal Bank of Scotland paid a £56 million fine because of a software glitch that had blocked their clients’ access to the bank’s services. In 2017, British Airways had to cancel over 1,000 flights due to a major IT breakdown. And perhaps coffee lovers from the US and Canada can recall the day when Starbucks ended up giving out coffee for free because its system refused to process payments. The above examples show that one can’t underestimate the importance of software testing. Properly conducted tests reduce your stress levels and save you money, regardless of whether we are talking about e-commerce, finance, transportation, or even a coffee shop business. Testing is an entire philosophy. Each app is unique, with its own business goals, complexity, and risks. That is why the idea behind testing should vary from project to project. This idea changes according to how much attention each type of test - static, unit, integration, and end-to-end - takes within a project. The amount of time and effort spent on each level can be graphically presented in various shapes. In this article, we are going to have a closer look at one of the most debated shapes - the testing trophy. This figure was considered in depth by Kent C. Dodds in 2018 in an Assert(js) Conference. He developed the thought from the famous tweet of Guillermo Rauch, the CEO of Versel and co-founder of successful JavaScript projects in the US. The saying is: Write tests. Not too many. Mostly integration. And there is a great deal of sense in this concise claim. The traditional testing methodology is often presented as a pyramid. This concept was first described in Mike Cohn’s publication Succeeding with Agile. There, unit tests form the foundation, and they make up the largest part of the triangle. Then come integration tests in the middle, and end-to-end tests are on top. Despite its short life-span in the software testing world, the pyramid evolved significantly and took the shape of an ice-cream cone, an hourglass, and even a honeycomb. Finally, two years ago, the trophy saw the light of day. In such a form, most of the attention is focused on the central part, that is, integration tests. The middle layer can be broadened or shrunk according to the testing needs. This, in turn, also broadens the scope of the end-to-end tests. So for what reasons is such a model of testing proposed as a worthy alternative to the good old triangle? #1 It provides the best combination of speed, cost, and reliability No one would argue that the higher up the traditional or the newly proposed figure you get, the longer it takes to perform testing. The static layer is the simplest one. It resides in catching type, stylistic, and formatting errors using linters, error formatters, and type checkers. Unit tests are relatively quick to write and easy to run. On this level, the work of separately taken units is verified. The end-to-end tests check the app from a user’s perspective. They are the slowest to write and run. The integration tests that verify the harmonious functioning of several modules together are in the middle. Thus, they are run at the best speed possible. The next issue is cost. Each project has a limited budget allocated to testing, and you don’t want to go over it, do you? So the best option would be to focus on tests that are not too expensive and, at the same time, consider the design and provide the appropriate level of assurance. All this you find in the integration tests. End-to-ends require too much in terms of money, and unit tests are cheap. So why not just stick with the latter? The answer is, of course, reliability. Each type of testing offers benefits. Simple unit tests deal with simple problems. In other words, they can check the proper operation of separately taken parts but can’t guarantee the same about the combination of units. The units are like parts of a motor. They might function all right individually, but when you put them together, the car won’t start. So unit tests can’t guarantee that the product as a whole is going to work as intended. The integration tests will. Thus, integration tests provide the best possible combination of pace, cost, and reliability. #2 It is highly profitable The bigger the problem is, the more it will cost you in the future. If you fail to test a corner-case bug on the unit level, which one out of a million of your customers will run across, it’s not critical. But if the checkout button in the app doesn’t work, that is an issue that will cost you thousands of dollars. On the other hand, the more complex the tests are, the more returns you will have on them. And that is for several reasons. As mentioned above, integration and end-to-end tests check critical cases that would hinder customers when using your product. Therefore, they give a higher level of confidence that the app is functioning just as the developers meant it to. Additionally, integration tests cover several components at once. So you can skip some unit tests but include them in the integration tests. Therefore, integration tests are easier to write than end-to-end tests, and they are more stable than unit tests. Given all the pros and cons, integration tests have the highest ROI. #3 It takes into account the architecture of the software Another advantage of integration tests is that they are flexible enough to handle code changes. In contrast, unit tests show themselves have shown themselves to be rather architecture-unfriendly. What does this mean? For example, if you decide to introduce new components to the code on the unit level, you’ll have to rewrite the whole unit test suite. So integration testing puts stress on the design, which makes changing the code easier. In his article Test Shapes, Jeff Nyman concludes that the above leads to treating the code at the appropriate level of abstraction. Conclusion Testing is like painting a landscape. You use a fine brush for small details like branches or leaves. And you paint the background with a wider brush. The more layers your picture has, the more tools and techniques you apply. The same is true for testing. And although it is reasonable to spend most of the time at the integration level due to its optimal cost and high efficiency, you need other tests as well. So be flexible, and combine different types of tests to deploy a high-quality product. And while implementing all these mechanisms, always keep the goals of your business in mind.
A successful IT project is the result of the planned, well-coordinated, and high-quality work of a team of specialists. What do planned processes involve? a vision of a future solution is worked out; there is an understanding of the basic functionality and improvements; a roadmap for project implementation is created; the composition of the team is determined: the number of specialists, roles, and dates of involvement; the team is provided with tasks for the upcoming sprints, and subsequent ones are gradually being worked out. Well-coordinated work is when each participant contributes to the common goal, without creating downtime or delays. High-quality development means that the team participates in the analysis of requirements and is involved in the discussion of upcoming tasks - for example, at grooming, where risks and potential problems are highlighted. As a result, the team chooses the best solution. When reaching out to an outsourcing company, a customer is mainly interested in developers. Still, they should consider other equally important participants in the software development life cycle (SDLC). Now let’s imagine a team of ten “programmers only” who have the task to create, for example, a fitness app. Who of these geniuses will communicate with the customer and find out the requirements? Who will determine which features to implement first and which ones to implement later? Who will be responsible for achieving business goals? Who will be able to determine the real needs of users or correctly understand the business idea of the customer? If developers are the only specialists engaged, there is a high probability that the product won’t satisfy all the user needs, as none of them would spend time on analyzing the target audience. Who will communicate with the business? Developers approach the clarification of requirements too narrowly and technically. As a result, the customer receives a product that is completely different from what they really needed. Finally, any development should be planned, and sprints should be fully packed with elaborated tasks. This is necessary in order to release urgent valuable functionality during each iteration. If developers grasp for tasks without any order, they will eventually accumulate technical debt. If trying to clarify the customer's requirements during a sprint, they won’t be able to meet the deadlines, which can cause a significant delay in product release. Consequently, the plans will collapse. Users are not satisfied, so the business is not making profits. Well-coordinated work is out of the question because everyone is in their own bubble. High quality is out of the question too - shortcomings in requirements and implementation of flawed or unnecessary functions will have consequences. And the cost of fixing such flaws, as Microsoft calculated, increases from five to two hundred times as we move towards the end of the SDLC. Thorough planning and comprehensive analysis will help a business avoid serious losses. According to McKinsey, 17% of IT projects are so unsuccessful that they lead companies to bankruptcy. Did you know that almost half of all developments exceed their allocated budgets, and 7% of projects exceed their allotted time? Conducting a discovery phase can improve the situation - as a result, development costs are halved and the likelihood of meeting deadlines increases by 75%. Fortunately, chaos can be easily avoided by including a kind of superhero - a Business Analyst - in the team. Let's figure out what helps this specialist keep order and what benefits they bring to the business. Who a Business Analyst is and when this specialist is needed A Business Analyst is a kind of intermediary between the business and the development team. How does this specialist fulfill this role? 1. Communicates with stakeholders and gathers requirements. The Business Analyst acts as a liaison by communicating with stakeholders to extract product requirements. In this case, this specialist simultaneously solves several problems. First, the Business Analyst documents the requirements so that the development team can build a relevant product based on them. Next, they help stakeholders analyze their vision and make the best product decision. In addition, the Business Analyst saves developers time so that they can be engaged in implementing a project instead of spending hours communicating with the business. The Business Analyst can both participate in building an app from scratch and propose an extension for existing software. 2. Combines the skills of Sherlock Holmes and a marketer for business analysis. Business Analysts are also involved when market research services are demanded. The specialist helps the customer correctly determine the target audience of the product and the true needs of users. The Business Analyst delivers competitor analysis services to see which competing products are poorly implemented and which products can be considered a successful example (SWOT ANALYSIS). Often, to refine the current application, it is necessary to study what is available at the moment in order to understand how the software should be transformed (AsIsToBe analysis and/or gap analysis). 3. The Business Analyst is a bit of a writer and an artist. Not in the direct sense of these words, of course. Having gathered and analyzed the requirements, the Business Analyst documents and always submits them to the responsible stakeholder for review and approval. Sometimes, the Business Analyst illustrates their activities with diagrams: they draw a general flow or specific diagrams with data about users and the functions available to them, create mockups of the future user interface, and so on. 4. Knows how a customer can make more money with fewer expenses. Perhaps the most valuable superpower for the business. Based on the results of market research and the customer’s resources, the Business Analyst can outline new opportunities that the customer would never have thought about. Our superhero doesn’t blindly obey the requests of the business owner but offers the most useful solution with the lowest cost and maximum profit in the future. After all, business goals can only be achieved if user needs are satisfied. A good product ultimately yields profits for the customer. Summarizing the above, the key capabilities of the Business Analyst before product development starts are as follows: extracting requirements from documents or presentations by communicating with stakeholders; analyzing and processing requirements with the use of various methods (User Stories, Users Cases, SRS, etc.); documenting requirements with diagrams, prototypes, and other artifacts; reviewing and approving requirements together with stakeholders, developers, QA engineers, and other competent specialists. The Business Analyst in the SDLC: the global source of product knowledge One would think that the Business Analyst’s work is done and it's time for other employees to join the game. But the superhero’s activities are not limited to the above. The Business Analyst is one of the backbones of the SDLC. This professional is responsible for the result and should be as concerned as the owner of the product. Let's see what the Business Analyst does at each stage of the SDLC. Stage 1. Pre-sale — establishing contact with the customer. Pre-sale is an important stage in getting along with the customer. The Business Analyst explores what their IT company can offer to the customer: makes a list of the functionality of a future application, prepares a team estimation, and takes into account other important aspects. At this stage, the Business Analyst is needed to create the correct vision of the product, cover it in as much detail as possible, and perform functional decomposition, based on which developers will conduct estimation. Stage 2. Requirements’ analysis. The details of this stage are described above. The Business Analyst conducts a discovery phase, where a deep analysis of the requirements of the future functionality and accurate estimation are required. Stage 3. Implementation. At this stage, the Business Analyst provides programmers with elaborated, analyzed, and approved requirements during each sprint. This ensures that there will be no chaos during the project and the least number of bugs will penetrate into the product. Stage 4. Testing. Since QA specialists are guided by the product requirements, the Business Analyst’s participation in the testing stage is mandatory. If a QA engineer has any concerns, the Business Analyst will investigate the bug and determine whether it is a defect that needs to be “cured.” The Business Analyst will take control of the error and think of how to prevent it from emerging again. Stage 5. Release. The Business Analyst monitors how consumers use the product. This expert gathers information and reviews, communicates with the support service, and analyzes what can be improved in the application. These desires are taken into account in the next sprint. Thus, the team creates a better version of the program that is more useful and valuable to consumers. Stage 6. Maintenance. Developers and other specialists will have many questions. The Business Analyst, participating in all stages of the project, is the global source of product knowledge. That’s why everyone can seek valuable advice from them. The Business Analyst? Why include one more specialist in the team? We’ve already got a Project Manager... It may mistakenly seem that the role of the Business Analyst can be filled by the Project Manager, as they work with customers too and know all the nuances. However, comparing these professionals is the same as confusing, for example, a designer and foreman on a construction site. The designer decides which wall the entrance door will be in, how many windows the house will have, and so on. Thus, all stages of construction will be safe, and the building will meet certain standards. The Project Manager can be portrayed as a foreman who supervises the actions of construction workers so that they build houses according to the project plan. The Business Analyst is responsible for the quality of requirements and their implementation. The Project Manager doesn’t work on documentation: they can just receive the requirements from the Business Analyst and decide which ones will be included in the sprint. The Project Manager makes sure that all developers are equally assigned with tasks, no one has nothing to do or, vice versa, is overloaded. In a nutshell, the Project Manager is responsible for resources and meeting the deadlines of product development and delivery to the customer. The Business Analyst is primarily a provider of elaborated User Stories and a consultant on the project. How do I know that the Business Analyst has completed the job successfully? As we said above, the job of the Business Analyst is to ensure that the customer will receive the maximum profit with fewer product costs in the future. Then how can the performance of the Business Analyst be measured? Practitioners measure the success of their work by the following indicators: The Business Analyst has worked out a sufficient number of User Stories and joined grooming; User Stories are not returned for refinement and go to development; The testing process reveals almost no bugs; The product is released on time and with the scope agreed; Everything on the project is carefully planned and organized, and there is no team downtime; The user is satisfied; The customer gains profits. To make it clearer, let's imagine a situation where a project starts without a Business Analyst. The process is not orchestrated, and the release deadlines are missed. The quality of the documentation is poor. Everybody works as they want, hurried by the customer, and the product includes many errors. And then, into this dreadful chaos comes the Business Analyst - and debriefing begins. It turns out that the documentation should’ve been revised and improved. That’s why bugs are coming out of the woodwork: they simply were not fixed before due to inaccurate requirements. Clear planning of sprints with prioritizing requirements and functionality appears, costs are lowered, the time needed to complete tasks is reduced, and developers begin to “be friends” with other team members. And the customer is gloriously happy that the work is finally going well. Life becomes easier and for both the team and the customer. Conclusion As we have shown above, a Business Analyst is a must-have on a project, whose competencies the success of development largely depends on. The Business Analyst is able to prevent problems that would exceed the cost of keeping this specialist in the team a hundredfold. Taking into account that the activity of the Business Analyst is aimed at maximizing the profit from the product, their work will pay off with interest in the future. Andersen's team takes on tough challenges and creates unique products. Our Business Analysts provide IT consulting services, work out solutions and conduct the discovery phases for projects, while developers help to successfully implement them.