An engineering process for building products on budget, time and scope.

Computools approach

Computools team will assist you at any phase of software engineering to build a quality product and speed up the achievement of your goals.

01Build the team
  1. Making the initial scope based on the specification and estimate.
  2. Сalculating the optimal number of specialists for each role based on expectations for the completion date, taking into account the non-linear productivity increase with a linear hour number increase.
  3. The team’s core consists of professionals who started working on the project from its early stages, i.e. Business Analytic, Architect, Team Lead, Project Manager, UX designer.Ordinary executors are pre-assembled on the project manager's team.
  4. Executors are added according to the following criteria:
    • level of technical skills
    • knowledge in the domain
  5. Depending on the project specifics and the number of executors, necessary key roles are involved.
  6. If the required number of executors is higher than the allowable level within the same team, additional teams are included in the project.
  7. An intro meeting.
02 Development
  1. Carrying out the iterative development phase based on the chosen management framework. It includes iterations based on these next steps:
    1. Specifying the story, including acceptance criteria by the Business Analyst.
    2. Decomposing the story by the Team Lead and Business Analyst. Consult with an Architect if necessary.
    3. Distribution of tasks by the Project Manager and Team Lead.
    4. Preparing the UX\UI design, and if necessary, using these editors:
      • Figma
      • Sketch
      • Photoshop
    5. Consult with the Business Analyst if tasks aren’t detailed enough.
    6. Estimation tasks and approvement by Team Lead.
    7. Task development in accordance with git flow. By default it is feature/branch that includes test development. Possible methodologies are:
      1. Domain driven development (DDD) - used for architecture of logic and code. It is possible to use alternatives in a number of cases.
      2. Test Driven Development (TDD) - used for implementation of the main logic in code.
    8. Creating pull requests with static code analysis using next tools (depending on technology):
      1. JetBrain Products - common
      2. Linter - Javascript, Typescript, Dart that built using AirBNB rules
      3. SonarQube - Java
      4. Codesniffer, Mess Detector - PHP
      5. ReSharper - C#
      6. K&R - C++
      7. Golint - go lang
    9. Code review and fixes
      1. goals
        • identifying logical errors in business rules
        • identifying potential bugs and unwanted side effects
        • removing duplicates
        • elimination of complicated implementations
        • keeping unified system structure
        • keeping unified system style
        • detecting errors missed by code analyzers
      2. types
        • cross team review – by all participants of the module development including the Team lead. Provides higher performance but takes significantly more time
        • Team lead review
        • Security review
      3. tools
        • GitHub
        • GitLab
        • Bitbucket internal tools
    10. Feature\branch deployment.
    11. Writing a test case into QA documentation according to task description and design mock-up.
    12. Aspect test and fixes.
    13. Fixing if necessary.
  2. Accept next additions based on selected management framework.
    • In case of Scrum
      1. Elaborating, decomposing and estimating tasks during the sprint planning. This process allows Product Owner to make changes for each sprint.
      2. Particular attention is paid to grouping tasks in such a way that the Product Owner gets a working project with new functionality at the end of each sprint. Sprints with active development in the new functional and stabilization phases are admissible.
      3. It is acceptable to go with active development and stabilization sprints.
      4. It is possible for the Product Owner to increase the team size. even if it wasn’t planned at the beginning.
    • In case of Kanban
      1. Elaborating, decomposing and estimating tasks performed right before working on them.
      2. The process' main goal is maximum delivery speed.
      3. The Product Owner sets the task's priority.
      4. It is possible for the Product Owner to increase the team size, even if it wasn’t planned at the beginning.
    • In case of Waterfall
      1. Elaborating, decomposing and estimating tasks performed during initial phase. Detailed task decomposition and elaboration are highly important from both the Business Analyst and Team Lead sides. If there is no similar experience, this phase may take significantly more time than in Scrum/Kanban based processes. And at the same time it is not completely accurate
      2. It is impossible to make significant changes until the project is finished. And they will require repeating the initial phase.
      3. In order to save time, tasks are grouped according to the development team’s priorities. Thus, feedback during the development is not so important, because it's impossible to make changes.
      4. It is difficult for the Product Owner to increase the team size if it wasn’t planned at the beginning because the work schedule and estimates are already done.
  3. By using basic principles and development approaches such as;
    • KISS (Keep it short and simple) principles [avoiding over-engineering],
    • DRY (Don’t repeat yourself) principles,
    • Clean Code approaches and ideas,
    • Industry standards, for example, AirBNB/PSR,
    • OOD principles and methodologies, including SOLID,
    • Working with next tools to achieve high productivity,
      1. IDE
        1. JetBrains IDEs
        2. Visual Code
        3. VisualStudio
      2. debugger
      3. profilers
      4. emulators
      5. static code analyzer
      6. bug/task tracers - atlassian software firstly
      7. domain specific tools
    • solved problem is more important than any approach or pattern
03Testing & stabilization
  1. Working with specifications and documentation - the sooner a bug is detected, the lower the cost of fixing it:
    • specification testing
    • prototype testing
  2. Development of a testing plan
  3. Development of initial test cases
  4. Working within stories/tasks - identifying bugs in an isolated feature/branch context, allows the development team to quickly determine the cause
    • task description analysis
      1. analysis of the completeness and clarity of the task
      2. acceptance criteria analysis
      3. discussion of the problem with the Business Analyst and correcting
    • preparation of test cases and checklists
    • deployment of the task on dev environment
    • testing in accordance with a test case
    • design testing by QA
    • layout testing by UI designer
    • if a bug is detected, the task is returned to the developer with a detailed description
      1. playback steps
      2. expected result
      3. actual result
      4. information about the environment
      5. additional information
    • in case of success, the task is moved to done
    • implementation of end to end tests and additional automatic tests in accordance with the requirements based on documentation
      1. UI tests via selenium - main page object design pattern.
      2. API test as part of the development stack.
      3. Load test - is not included in the group of tests launched automatically during the build.
  5. Automatic tests run automatically on build servers and developer local environments. The code can be merged only after passing all tests:
    • code analysis
    • unit test
    • integration test
    • auto test
      1. end to end
      2. API
  6. Regression testing is carried out within the completion of the sprint, or a specific area of ​​work. The main goal is to make sure that there are no hidden bugs, bugs at the junction of the tasks or bugs arising due to side effects of implemented tasks. Facts about regression testing:
    • performed on QA environment
    • there is a full manual testing of the build in accordance with documentation
    • if a bug is detected, it creates an in task tracking system. The task contains the following description:
      1. Name - to describe the essence of the problem concisely.
      2. Code - a unique identifier of the task in the task tracker.
      3. Type: blocker, critical, major, minor, trivial.
      4. Priority.
      5. General description.
      6. Reproducing steps - often are supplemented with screenshots or videos.
      7. Environmental information:
        1. link to the environment
        2. hardware
        3. software
        4. etc.
      8. Additional information:
        1. log
        2. database dump
        3. etc.
      9. Expected result
      10. Actual result
    • bugs estimation
    • bugs prioritizing:
      1. current scope - cannot be postponed
      2. to backlog - a build can be released with them. This method is not desirable and is applied only in the case of tight deadlines.
    • bugs distribution
    • bugs fixing
    • bugs acceptance tests matching expected result and actual result
    • additionally implementation of automatic tests that track this scenario
    • repeated regression testing cycle
  7. The choice of working strategy with a release candidate takes place at the stage of writing test plans and depends on the requirements for system reliability and time to market.
    • Release candidate validation strategy:
      1. Release candidate's testing is an analogue of regression testing, taking into account the definition of done. The result is the admission of the release candidate's uploading to staging.
      2. Staging/demo testing - testing the release candidate which received approval and was uploaded to staging/demo on a specified set of cases that allow to not block efficiency.
      3. Production testing is analogous to staging/demo in a production environment.
    • strategy of planned Continuous Delivery (CD)
      1. The CD system is an alternative to working with release candidates. In this case, the uploading of operable functional takes place in a semi-automatic mode on schedule. The functional is considered to be operable only if it is passed by regression manual testing. Inoperable functionality is usually excluded from the build and it's not waited to get stabilized at this time.
      2. planned production/staging testing.
  8. Penetration testing - is used to find system security issues
  9. Optional types of testing
    • Smoke testing is used to check if the build is ready to be tested. This type of testing is rare because the standard development process implies that the build is always ready for testing.
    • Research tests - can include penetration testing elements, peak load tests, domain specific elements. It is carried out with the help of specialized software in order to identify hidden risks and peak capabilities of the system.
  10. Improvement - all team members can create improvement tasks during their work on the project. After tasks are created, the Business Analyst work with them additionally. This type of task does not block the build but can be done within the scope.
  11. Code stabilization/refactoring - the development team can create tasks. The implementation of which does not provide new functionality, but can increase system stability, reduce the probability of bug emergence and speed up development.

Why Computools?


Access to expertise and Computools own key niche solutions provides saving time.


Computools LLC innovation management performance was valued by world experts in IMP³rove Academy.

ISO 9001:2015

Computools processes is certified according to international standards and has been refined by years of experience.

A Wide Range of Technology Stack

Computools’ multi technology experience allows select optimal technology for product development.


Computools values openness and transparency in all business processes thus you will always know what stage the development is.


Computools builds long-term relationships. This value forms the foundation of the company.


Main priority of the project team is your business goals, unique differentiators and challenges.


Low staff turnover by to geography and leadership in the region.

Partnering with countries

Computools' international associations' membership allows to better understand the needs and particular features of customers around the world.

IT clusters – collaboration

Computools supports collaboration with IT Professional Associations for experience and knowledge exchange, innovative solutions' development.

Award wins

The high level of Computools’ IT-expertise awarded and appreciated by awards and recognitions.

Continuing Skills Enhancement

Regular internal seminars, training, and workshops contribute to the continuous improvement of the company's engineers skills.

Contact Us

Let's talk about your project.
Use the form to drop a line or write us an e-mail:

Thank you for your message! Your request will be carefully researched by our experts. We will get in touch with you within one business day.