About

Careers

Team

<h3>We are TESVAN</h3> Your 3 words best describing the Tesvan team.Lusine: “Casual, Supportive, Flexible” How we
work As we are a QA outsourcing company we have multiple projects we are
working on. Generally, there is a person or a pair in charge of each project
and due to our good collaboration skills, we always succeed in working in pairs.
Based on project specifications we work on multiple QA frameworks using
different tools. Tesvanners are familiar with most of those tools but there is
always one tool each of us is the best on: like saying API testing we imagine
Ara, Lusine is our Git guru, Selenium masters are Arman and Norayr, Vazgen is
unstoppable in mobile testing and so on…
One of the strengths of Tesvan is that we all are good both in individual and
group working which makes our team flexible and effective.
And to keep a good work ethic there are some key points which must be strictly
followed: time management, responsibility, and excellent communication skills.
 How would you describe Tesvan in 3 words? 
Ara: “ Yellow, Happy, Smart” How we learn and grow Working in the
IT-sphere means growing continuously. We realize that for being competent and
valuable specialists in this field we need to improve our skills and knowledge.
We give much importance to self-development and self-improvement which are
especially enjoyable when accompanied by teamwork. And how do we do that?
For every month we suggest several topics related to QA/IT and each of us
chooses a topic closer to him/her and explores that deeply in order to prepare
a presentation for other teammates. So, at the end of the month, we do a line
of presentations. We gather together to listen to each other, share our
thoughts regarding the topic, ask questions and find the answers together. It
is a good approach to learn new things and grow which has become a habit for
us!
 What can’t you imagine Tesvan without? 
Levon: “Laptops and warm smiles of my colleagues :)”
 What we play It’s not only work that unites us, but also our hobbies!
Where to go without Tesvan games and teambuildings? Nowhere!
The first on the list is Football, as we all are big fans of football, even the
newcomers who didn’t express any interest in it in past, become involved with
that just in a very short period of time.
We like watching matches and then discuss our favorite moments, rewatch epic
goals and share our emotions at the office. Sometimes Tesvan boys organize
football matches and play with other teams.
Also, we never miss the chance to watch football matches from the stadium, it
is another pleasure for us. And a good occasion to make good memories all
together. What do you like the
most in Tesvan? 
Mane: People! 
 After
football, the second place is for chess.
Once or twice a month, we organize Friday “Mafia Night”, after work. We like
playing any new and interesting intellectual games, doing debates taking global
topics.
Almost every month we organize one teambuilding, or a camping activity to fully
relax and be recharged with energy. 
What is missing in Tesvan?
 Merine: “My favorite coffee “Jacobs”, instead of “Nescafe”,
more fruits especially mandarins for winter :) “ So, Tesvan is not just an office, where we
work and spend 8 hours of our day.
It is a big family, where we live and grow, support and motivate each other to
overcome any difficulty and to become better versions of ourselves day by day.
Now, you can get the answer to the question “What is behind the doors of
Tesvan?”
 It is only love, respect, and sympathy! 
 P.S. “Success is a Team Sport!!!” : the phrase always rolling in our
mind!

Everyday Life of Tesvanners

<h3>Essential metrics to measure the effectiveness of QA process</h3> As an indispensable part of the IT world, quality assurance
(QA) has become an important area in the lives of developers and testers. As
websites and apps have become more sophisticated in recent years, the quality
assurance process has also become equally active. More extensive websites and
applications usually require more extensive and thorough testing before
release.
&nbsp; 
The quality assurance process must be carefully planned and
observed to be sufficiently successful. The most effective way to monitor the
effectiveness of the quality assurance process is to use appropriate metrics.
&nbsp; 
When discussing the applicability of quality assurance
performance standards, it is also important to note that quality assurance standards
do not refer to the company as a single unit. Instead, they refer to the
different levels that exist, each level having its own set of standards. For
example, you may have metrics in the design phase, and some metrics are related
to the number of defects in a given period. Such metrics are best suited for
their specific products, although you can also evaluate them at the overall
department level.
&nbsp;
 Before determining quality assurance standards, it is
necessary to understand what questions are intended to be answered by the
application of these standards.
 &nbsp;
So
the questions to ask beforehand are: 1.How long will the test take?
2.How much money is allocated for the testing process?
3.What kind of bugs do we have? (bug status)
4.What proportion of total software testing do existing
tests provide (what percentage?)
5.Are the estimated dates sufficient to carry out the
testing?
&nbsp; 
Basic standards of
quality assurance Now let's move on to the metrics used to measure the
effectiveness of the testing process.
 There are absolute values that are always represented by
numbers:
&nbsp; 
1.Number of test cases
2.The number of passed test cases
3.Number of failed test cases
4.Number of blocked test cases
5.Number of bugs found
6.Number of accepted bugs
7.The number of rejected bugs
8.Number of delayed bugs
9.Number of critical bugs
10.Number of bugs found since release But ultimately, all the above indicators are not enough to
measure the success and efficiency of the testing process. To see and evaluate
the overall picture, we need more specific and calculated data.
 &nbsp;Measurement of
testing effort:
 Metrics include number of tests performed, bugs per hour of
testing, average time to fix bugs, etc.
&nbsp; 
1.Number of tests in a given period = Number of tests/Total
time
2.Test design efficiency = Number of tests designed / Total
time
3.Test Review Efficiency = Number of Tests Reviewed/Total
Time
4.Number of bugs per test = Total number of bugs/Total
number of tests
 Test coverage
measurement:
 Helps to understand which parts of the application should be
tested. Assuming the tests are of good quality, this metric can reveal which
parts of the software have the most defects.
&nbsp;
&nbsp;
&nbsp; 
1.Test coverage percentage = (number of tests
performed/number of tests to be performed) X 100
2.Claims Coverage = (Number of Claims Coverage/Total Number
of Claims) X 100 Measuring Team
Performance:
 This evaluates the distribution of work among team members
and the results obtained by the respective team member. Experts recommend never
using these criteria to pit individual testers against each other, but rather
to promote progress within the team and achieve success through collaborative
efforts.
&nbsp; 
1.Number of bugs returned by each team member
2.Number of bugs opened by each team member
3.Number of test cases assigned to each team member
4.Number of test cases performed by each team member
&nbsp;
&nbsp; 
Bug distribution
measurement: 
It helps to understand which part of the software is most
susceptible to defects and therefore where to focus testing efforts.
 
1.Distribution of bugs by cause
2.Breakdown of bugs by feature/functional area
3.Distribution of bugs by severity
4.Allocating bugs by priority
5.Distribution of bugs by type
6.Breakdown of bugs by tester – Dev, QA, UAT or End-user
 Measuring Test
Performance:
 In this way, we can evaluate how successful the testing is.
(bugs found in 1 test / total number of bugs found in tests
+ after release) X 100 Our experience 
As a quality assurance company, we cannot avoid measuring
the effectiveness of our work using the above criteria.
Typically, the metrics used by our team depend on the
current project the team/couple is working on.
If it is a small project involving two of our specialists
(as we mentioned in one of our previous blogs, we mostly work on projects in
small teams or pairs), there is no need to measure, for example, "Team
Effectiveness".
But in general, there are metrics that should always be
considered and measured well, no matter what type of project we're dealing
with, such as "Defect Distribution" metrics, as well as "Test
Coverage" metrics, which are of primary importance.

The most common way to evaluate the effectiveness of testing is to use appropriate benchmarks.

Key QA Process Metrics

When working on this project, what were the testing services we provided?

Clustercontrol

Customertimes

Rocky Mountains

<h3>Functional Testing</h3> The purpose of Functional Testing is to verify each function of the software application, ensuring the appropriate input, verifying the output depending on the functional requirements. It checks whether each component is working as expected or not. Therefore, it is also called "Component testing". This type of testing is mandatory regardless of the type of application. During Functional Testing, the Black Box Testing technique is used, in which the internal logic of the system under test is not known. Tests User Interface, APIs, Database, Security, Client/Server communication and other application functions. It can be done both manually and automatically. Functions are tested by passing them input data and examining the output. Functional Testing ensures that the application properly meets the requirements. This type of testing is not related to how the implementation happens, but only related to the results. What does Functional Testing test? 1. The main functions of the application, the described functionality. In other words, the behavior of the application is tested according to the test specification. 2. Error conditions - presence of messages in case of error conditions. Steps of Functional Testing 1. Understand the functions that the application should implement. 2. Generate input data based on function specifications. 3.Determine the expected output results for the selected input values. 4. Implement test cases. 5. Comparison of actual and expected results. Types of Functional Testing 1. Unit testing 2. Integration testing 33.Interface testing 4. System testing 5. Regression testing 6. Smoke testing 7. Sanity testing 8. Acceptance testing Unit testing 1.In this type of functional testing, the smallest functional and testable unit of code is tested during unit testing. 2. Mainly performed by developers as it is a White-Box testing technique. 3. Performed at the earliest stages of development, hence helps to identify defects at early stages of development. This helps save the higher cost of fixing defects in later stages of STLC. Integration testing 1. Two or more unit-tested components of software are integrated together and tested to confirm that they interact as expected. 2. The communication of commands, data, DB calls, API calls, microservices processing takes place between departments and no unexpected behavior is observed during this integration. Interface testing 1. Part of integration testing; The accuracy of data exchange, data transfer, messages, calls and commands between two integrated components is verified. 2. The communication between the database, web services, APIs or any external component and the application is tested during Interface testing. 3. There should not be any error or format mismatch in the communication of this data or command. If such a problem occurs, it should be fixed. 4. Interface testing is the testing of connectivity between different interfaces, while Integration testing is the testing of an integrated group of modules as a single unit. System testing 1. All system components are combined and the system is tested for conformance and accuracy to requirements specifications (functional or system). 2. It is a Black-Box testing technique that validates the integrated system. 3. It is performed before Acceptance testing (UAT) in STLC (Software testing life cycle). 4. System testing is performed in a near-real environment and according to real-life usage. Regression testing 1. After some improvements or code fixes by the developers, it becomes very important to run the Regression testing package. Regression testing is performed to ensure that these code changes have not hindered existing working functionality or introduced any new defects in the code. 2. Regression testing cases are a subset of existing functional tests that cover the main functions of the system. 3. Regression cases should be updated, added and deleted according to changes in the application. 4. Regression testing cases are the best candidates for automation testing because they are run frequently and take time to execute. Smoke testing 1. After Developement, when a new build is released, Smoke Testing is performed on the application to ensure that all key features work to perfection. 2. Smoke Testing is usually performed early in application development for builds that are not yet stable. 3. During testing, if any key functionality does not work as expected, that particular build is rejected. Developers should fix bugs and create a new build for further testing. 4. After successful smoke testing, the application is ready for the next level of testing. Sanity testing 1. Sanity testing is selected from the Regression testing suite, covering the core functionality of the application. 2.Sanity Testing is performed on a new build created by developers for a relatively stable application. 3. Once the application successfully passes Sanity testing, it is ready for the next level of testing. 4. It is easy to confuse Smoke testing and Sanity testing. After a new build, Smoke Testing is done to test the initial application. After multiple releases, once it has achieved stability, Sanity Testing is performed on the same application. Acceptance testing 1. Acceptance of the application by the end user is checked during acceptance testing. The purpose of this testing is to ensure that the developed system fulfills all the requirements that were agreed during the creation of the business requirements. 2. It is performed immediately after System testing and before the final release of the application. 3. Acceptance testing becomes a criterion for the user to either accept or reject the system. 4. It is a Black-Box testing technique because we are only interested in knowing the functionality of the application for the market and real users. Useful links: <a href="https://www.guru99.com/functional-testing.htm" target="_blank">Functional testing article/eng</a><a href="https://www.applause.com/blog/functional-testing-types-examples" target="_blank">Functional testing types article/eng</a><a href="https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/funktsionalnoe-testirovanie-2" target="_blank">Functional testing article/rus</a><a href="https://www.youtube.com/watch?v=IGnZHgjU42Y" target="_blank">Functional testing video tutorial/eng</a><a href="https://www.youtube.com/watch?v=B1-1BqAr1f4" target="_blank">Functional testing video tutorial/rus</a>

Functional Testing

<h3>Git</h3> Installing, configuring, creating a repository For example, you need to transfer the information you created (from your home or work computer) to a server (for example, the GitHub repository). So that every member of your team, or, for example, an instructor, can access your files. In this case, you need to decide which folder or file you want to synchronize with the server, i.e. create a local storage (repository). We will consider it using the example of working with IDEA and managing from the console. This example is not specifically tied to the software used, so you can repeat this example for your specific situation. Step by step: <ol><li style="text-align: justify;">Create your own GIT HUB repository. This will be our server storage, which any participant can work with and access to it.</li><li style="text-align: justify;">Create your own free repository on GITHUB Install GIT itself, to do this, follow the link and download the current version for today: DOWNLOAD GIT Free</li><li style="text-align: justify;">In the appeared GIT console window on your computer (or cmd console), enter the following commands from the keyboard (each command ends by pressing the Enter key) :</li></ol> <ul><li style="text-align: justify;">git - this command displays a list of available commands, but for us now it simply serves as a confirmation that step 2 was done correctly and GIT is working</li><li style="text-align: justify;">git config --global user.name "Ivan Ivanov" - specify your name.</li><li style="text-align: justify;">git config --global user.email IvanIvanov@example.com - specify your email address</li><li style="text-align: justify;">cd: C: / Users / Ivanov / IdeaProjects / Project1 - with this command you go to the folder you need, which in the next step you will make as a local storage (i.e. this is your working directory where all project changes will be stored)</li><li style="text-align: justify;">git init - Create a repository in the current directory</li><li style="text-align: justify;">git add. - this command indexes (checks and remembers) all files (dot at the end of the command), which later will be subject to commit (essentially saved).</li><li style="text-align: justify;">git commit -m "Commit Text" - saving changes to a local folder.</li></ul> That's it, the local repository has been created, now we need to link the local and remote (GITHUB created in point 1) repositories. To do this, we need to enter the following commands: <ul><li style="text-align: justify;">git remote add origin https://github.com/GithubUser/RepositiryName.git - where, https://github.com/GithubUser/RepositiryName.git the address of the repository you created on GitHub can be copied directly from the browser with the addition of .git</li><li style="text-align: justify;">git push -u origin master</li></ul> Congratulations, you have linked the remote and local repositories. To upload files to the remote repository, run the command: git push - after pressing Enter, the first time you are asked to enter your GitHub username and password. You can now see the changes made on the GitHub site. Please note that after you have made changes with the files, in our example, this saved the project in IDEA, you need to run the following commands: <ul><li style="text-align: justify;">git add. - this command indexes (checks and remembers) all files (dot at the end of the command), which later will be subject to commit (essentially saved).</li><li style="text-align: justify;">git commit -m "Commit Text" - saving changes to a local folder.</li></ul> To transfer to the remote repository, run this command as well: git push In order, on the contrary, to get information from the remote repository to the local repository, run the command: git pull <blockquote style="text-align: justify;">Useful Links: <a href="https://www.atlassian.com/git/tutorials/what-is-git" target="_blank">Git article/eng</a> <a href="https://www.atlassian.com/git" target="_blank">Git article/eng</a> <a href="https://www.youtube.com/watch?v=SWYqp7iY_Tc" target="_blank">GitHub video tutorial/eng</a> <a href="https://www.youtube.com/watch?v=CRlGDDprdOQ" target="_blank">Git video tutorial/eng</a></blockquote>

Nothing makes the product more attractive but quality. We are here to provide high-quality of your software.