Engineer next generation software solutions for your business.





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.

Build 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.


  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

Testing & 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.

Contact Us

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

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.

Why Computools?


Access to niche expertise and solutions that focus on quality, efficiency, and saving time.


Trusted innovation management and performance valued by world experts at the IMP³rove Academy.

ISO 9001:2015

Certified processes according to international standards and backed by experience.


Access to a multi-technology environment that enhances product development.


Security in knowing that you never have to question where you're at or what's happening in the development process.


Gain stability with a partner who believes in long-term relationships and views it as a fundamental value.


Work with teams that have your business goals in mind. Each step is a step towards improving your overall business processes.


Low staff turnover due to geographical location and leadership in the region.


A number of International association memberships allow us to understand your needs no matter where you're located in the world.


Collaboration with IT professional associations and the knowledge exchange that come with it keep us as an industry leader in IT development.


Confidence in the fact that we are respected as global IT-experts with awards and recognitions to prove it.


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

in house teams

Meet project deadlines through the instant scaling of an in-house digital team or adding professionals as needed.

Instant access to expertise and solutions

Gain instant access to expertise and niche solutions that provide fast and measurable results.

Professional engineers with niche skills

Utilize experienced engineers with the skills to deliver quality results on time and on budget.

Full control over
team management

Get a dedicated team fully integrated into your company's processes, involved in your project, and under your management.


Computools will guide your company through technological transformation.