Данная статья - это обобщение шестилетнего опыт наблюдения за инженерами, работающими или работавшими в тестировании, с позиции разработчика, руководителя группы, руководителя отдела тестирования и руководителя производства.
Целью статьи является рассмотрение карьерного роста тестировщика, а также проблем, связанных с этим ростом, и путей их решения.
Статья была взята в основу доклада на конференции SQA Days 8.
Как становятся тестером
Существует несколько способов становления тестером, каждый из которых подтверждается многочисленными примерами. Если в предложенном списке Вы не нашли свой, пишите мне, я с радастью прочитаю Вашу историю :)
Студент
Многие студенты, мечтающие работать IT разработчиками, но не имеющие достаточного опыта, могут попасть только в тестирование, т.е. туда, где входной порог существенно ниже. Большинство студентов, начинающих свою карьеру в тестировании, рассматривают тестирование как стартовую точку.
Случайность
Также среди тестеров встречаются люди, которые изначально не собирались ими быть. Вполне возможно, они не собирались работать в ИТ. Здесь они оказались случайно: в компании были открытые вакансии и для того, чтобы устроиться на работу достаточно было иметь голову на плечах и не много понимать программировании и администрировании операционных систем.
Было интересно
Нередко встречаю кандидатов, которым тестирование интересно или они так думают, что тестирование интересно для них. Некоторым интересно ломать, некоторым автоматизировать, но и тем и другим нравится тестировать. Именно поэтому они здесь.
Вас «попросили»
Иногда разработчики становится тестерами, лишь потому, что это важно компании. Кто-то отваливается, а кто-то продолжает героически сражаться за качество продукта и решает геометрально другие задачи, нежели в продуктовой разработке.
С чего начинается работа
Предположим, вы нанимаете на работу инженера (возможно, студента), который не имеет достаточного опыта в тестировании или вообще имеет опыта работы в компании. Тем не менее вам необходимо организовать процесс так, чтобы новый сотрудник достаточно быстро вошел в курсе дела и начал приносить пользу.
Конечно, вы можете завалить его документацией по продукту и процессам, используемым в компании, определить срок на изучение материала и по истечении данного срока провести небольшой (или большой) экзамен по знанию продуктов и процессов. Это сработает? Наверное, да, если сотруднику хватит терпения на выполенения столь скучной работы в одиночестве и без практики. Но вполне возможно, что данный сотрудник будет демотивирован еще до того, как приступит к выполенению своих служебных обязанностей.
Другой более эффективный, но в тоже время и более дорогой способ вовлечения новых сотрудников в проекты, - это проведение для них специализированных тренингов, на которых присутствует постоянный контакт между сотрудниками и тренерами. В рамках тренингов новые сотрудники знакомятся с продуктами, методиками и процессами. При таком подходе обучение сфокусировано на важных аспектах работы, а сам процесс обучения выглядит динамичным и интересным.
Однако, наличие подобных тренингов должно быть экономически оправданным, а эффективность тренингов возможна только в том случае, если в компании есть грамотные тренеры и отработанные тренинговые программы.
Как часто и в каком количестве вы нанимаете новых сотрудников? Какое соотношение новичков и профессионалов в списке вновь нанятых сотрудников? Очевидно, что нет необходимости создавать тренинговые центры для того, чтобы обучить пару сотрудников, нанятых в течение шести месяцев. Тогда, как же обеспечить плавный ввод сотрудника в проект?
Верификация багов – это одна из первых задач, которую можно поручить начинающему. Данная задача не только позволит изучить продукт, но и даст сотруднику почувствовать, что он или она является частью команды и от его или ее результатов работы также зависит успех проекта. Не стоит давать новому сотруднику верификацию багов, где проектные риски высоки. Однако, вы можете усложнять задачу в зависимости от полученных результатов и назначать на сотрудника баги, верификация которых требует большей внимательности и экспертизы
Эволюция тестера или почему тестеры не хотят быть тестерами
Надоело верифицировать баги
Верификация багов вполне годится как инструмент для обучения, но не годится в качестве основной задачи. Никакой тестер не будет заниматься этим и только этим больше одного месяца. Если к вам не пришли и не сказали, что эта задача просто наскучила, то вам следует самим поинтересоваться - а все ли в порядке, и если вы получите положительный ответ, вам следует усомниться в способностях данного тестера и проанализировать его или ее мотивацию.
Конечно все тестеры верифицируют баги, но лишь потому, что это входит в их круг должностных обязанностей. Но делать это никто не любит.
Надоело исполнять тест кейсы
Когда верификация багов не может быть больше постоянной задачей, а процесс обучения инженера еще не закончен, разумно назначить инженера на исполнение тест кейсов. Однако, добавление данной задачи вовсе не означает отмену предыдущей. Тем не менее, инженер продолжает изучать продукт и предметную область посредством исполнения тест кейсов, и знакомиться с техникой их написания.
Очень важно на данном этапе организовать серию тренингов для инженера, в рамках которых инженер изучит фундаментальные техники функционального тестирования: тестирование граничных значений, классы эквивалентности и т.д. Это позволит инженеру понимать причины того или иного подхода, используемого в тест кейсе.
Если же в вашей компании есть автотесты, то также разумно назначить инженера на разбор упавших тестов. Это позволит инженеру познакомиться с тем, каким образом в компании обеспечена автоматизация тестирования: логи, инфраструктура и т.д.
Исполение тестов новичками позволяет вам оценить качество имеющихся тест кейсов с точки зрения понятности, логичности и завершенности. Если тест кейсы написаны таким языком, что для их прохождения нужно работать в команде два или три года, то вы узнаете об этом очень быстро. Если логирование в автотесте реализовано так, что понять его может только разработчик теста или его коллега, который также принимал участие в написании данного теста, то вы тоже узнаете об этом очень быстро.
Поскольку исполение тестов как и верифицирование багов - это задача, исключающая творческую составляющую, она очень быстро надоест инженеру и вам нужно быть готовым к тому, чтобы дать этому инженеру другую задачу.
Надоело писать тест кейсы
Написание тест кейсов – это задача, которая позволит тестеру задействовать весь свой потенциал и знания, полученные на предыдущих этапах, для тестирования функциональности в продукте. Необходимость написания тест кейсов по определенным правилам сделает этот процесс контролируемым. Таким образом, вы будете понимать что тестируется и как тестируется. Сложность задачи будет зависеть от того, над какой функциональностью работает тестер.
Но как и в двух ранее описанных случаях, не многие способны «клепать» тест кейсы, не теряя при этом энтузиазма. Поэтому, чтобы обеспечить эффективность ручного тестирования и поддержание интереса инженеров к такой работе, вам придется внедрить такие практики, как пострение карт тестирования и exploratory тестирование, а написание тест кейсов свести к минимуму, закрывая лишь высоко приоритетные сценарии и аспекты тестируемых систем, что в дальнейшем будет определять регрессионное тесты.
Не придумываю фичи
Большинство тестеров, с которыми мне довелось общаться, поднимали вопрос о необходимости их участия в разработке фичи. Комментарии, которые появляются в процессе тестирования иногда, а порой и довольно часто, являются поздними изменениями в продукте и они не могут быть реализованы когда план работ уже согласован. Однако, большинство тестеров уверены, что если бы они участвовали в разработке фичей «с самого начала», то продукт бы был лучше.
Нужно отметить, что это достаточно валидное утверждение, а тестеры, которые имеют опыт работы с продуктом, хорошо понимают предметную область и способны не только верифицировать продукт, но и обеспечить его валидацию, действительно полезны в разработке фичей «с самого начала».
Поэтому если ваш инженерный процесс позволяет вовлекать тестировщиков в разработку фичей до того как их начнут реализовывать, то это решает проблему «Я не придумываю фичи».
Тестеры, которые никогда не мечтали быть разработчками оседают имменно на этом этапе.
Хочу писать код
Однако, те инженеры, которые изначально рассматривали тестирование как промежуточный шаг на пути к разработке, непременно объявят вам о своем намерении писать код.
Разработка автотестов – это мощный мотиватор в решении данной проблемы. Как правило, это приводит к появлению конструкций вида:
public class TestClass1{
public static void main (String[] args){
//some code
}
}
Если автоматизация тестирования не выглядит как хаотичный процесс, где каждый тестер делает что хочет и как хочет, а наоборот, имеет четкую стратегию с применением лучших практик, таких как ревью кода, использование сторонних фреймфорков (например, для PHP это может быть Zend framework) и нестандарных решений в тестировании продукта, то автоматизация является серьезным аргументом в решении вопросов «хочу писать код».
Инженеры, занимающиеся автоматизацией тестирования, зачастую решают задачи не меенее сложные чем те, кто разрабатывают новые фичи в продукте. Поэтому большинство тестеров, которые изначально хотели быть разработчиками, вполне удовлетворены задачами этого этапа. При этом все также разрабатывают тестовые спецификации, исполняют тесты, открывают и верифицируют баги и автоматизируют тестирование.
Хочу писать другой код
Но даже при наличии автоматизации вы не можете гарантировать, что к вам не придут и не скажут «Хочу писать другой код». В этом случае тестер, который занимался автоматизацией, по каким-то причинам не понял или не увидел должного развития в рамках предложенных ему задач и считает, что программирование там, где разрабатываются фичи.
Как с этим бороться?
Менеджер vs. эволюция
Никак!! Поскольку верификация багов, исполнение тестов, дизайн тестов, участие в разработке новых фичей, разработка автотестов – это эволюция тестера. С эволюцией нет смысла бороться, ее нужно учитывать в планировании проектов, в формировании команды, в формализации карьерного роста и т.д.
Используйте данные знания, чтобы мотивировать сотрудника к работе. Определите цели и задачи для инженера. Обеспечьте прозрачность процесса контроля достижений посредством обратной связи. Дайте возможность изучать и применять новые технологии и практики.
Если же тестер заявил о том, что ему не интересно тестирование вообще и он хочет заниматься разработкой фичей, то ваша цель теперь – сохранить сотрудника в компании. Посчитайте, сколько должно пройти времени с момента найма сотрудника и до того, как сотрудник начнет приносить серьезный вклад в проект. Вполне возможно что инженер, прошедший школу тестирования и научившийся рограммировать, будет не менее эффективен и полезен в разработке.
В тех случаях, когда инженер способен и готов руководить, сделайте его наставником, руководителем группы или менеджером. Такое назначение замотивирует инженера работать в вашем отделе. Если же такой вариант невозможен, то приложите все усилия, чтобы перевести инженера в отдел разработки.
Как искать «правильных» тестеров
Для того, чтобы обеспечить плавный рост инженера и при этом сохранить эффективность его работы на каждом из указанных этапов, важно подбирать «правильных» тестеров. Критерий правильности может варьироваться в зависимости от рассматриваемой должности. Очевидно, что требования к инженеру, занимающемуся ручным тестированием и к инженеру, в задачи которого входят автоматизация, будут различны.
Как правило, при принятии решения о приеме на работу кандидата учитывается соответствие его техническим требованиям к должности: способность решать аналитические задачи, знание предметной области и т.д. Насколько кандидат подходит психологически на данную вакансию определяется по принципу нравится или не нравится, или игнорируется совсем.
Важно отметить, что не каждый тестер может быть разработчиком, также как не каждый разработчик может быть тестером. Ключ к решению данного вопроса кроется в психологическом портрете тестера и разработчика.
Основная цель тестирования – это поиск багов в продукте. Следовательно, каждый тестер должен фокусироваться на поиске различий и несоотвествий. В то время как разработчик должен ориентироваться на обобщение фактов при создании новых фичей. Таким образом, контролирующим вопросом при собеседовании кандидата будет: «Сравните, пожалуйста, объект А с объектом Б». А дальше внимательно слушайте ответы: чего в них больше - обобщений или различий.
Конечно, вопрос сравнения объектов является далеко не единственным в определении психологического портрета кандидата, а лишь иллюстрирует данный метод.
Если построить интервью таким образом, что сначала определяется насколько кандидат психологически подходит на данную вакансию, а только потом выяснять его профессиональные способности, то это позволит избежать проблем в будущем: когда инженер отлично знает предметную область и тем не менее не может или не хочет выполнять предложенные задачи.
Заключение
Итак, какие полезные выводы можно сделать на основании вышеизложенного материала:
1. Нужно искать «правильных» тестеров - для того, чтобы обеспечить плавность в карьерном росте и эффектиность работы на разных этапах.
2. Учитывать эволюцию в проектных планах, в формировании команды и т.д., и ни в коем случае не бороться и не препятствовать ей.
3. Делать процесс роста интересным. Как правило, это достигается с помощью своевренной смены задач, сохраняя тем самым мотивацию сотрудника.
4. Всегда сохранять сотрудника в отделе или компании.
Целью статьи является рассмотрение карьерного роста тестировщика, а также проблем, связанных с этим ростом, и путей их решения.
Статья была взята в основу доклада на конференции SQA Days 8.
Как становятся тестером
Существует несколько способов становления тестером, каждый из которых подтверждается многочисленными примерами. Если в предложенном списке Вы не нашли свой, пишите мне, я с радастью прочитаю Вашу историю :)
Студент
Многие студенты, мечтающие работать IT разработчиками, но не имеющие достаточного опыта, могут попасть только в тестирование, т.е. туда, где входной порог существенно ниже. Большинство студентов, начинающих свою карьеру в тестировании, рассматривают тестирование как стартовую точку.
Случайность
Также среди тестеров встречаются люди, которые изначально не собирались ими быть. Вполне возможно, они не собирались работать в ИТ. Здесь они оказались случайно: в компании были открытые вакансии и для того, чтобы устроиться на работу достаточно было иметь голову на плечах и не много понимать программировании и администрировании операционных систем.
Было интересно
Нередко встречаю кандидатов, которым тестирование интересно или они так думают, что тестирование интересно для них. Некоторым интересно ломать, некоторым автоматизировать, но и тем и другим нравится тестировать. Именно поэтому они здесь.
Вас «попросили»
Иногда разработчики становится тестерами, лишь потому, что это важно компании. Кто-то отваливается, а кто-то продолжает героически сражаться за качество продукта и решает геометрально другие задачи, нежели в продуктовой разработке.
С чего начинается работа
Предположим, вы нанимаете на работу инженера (возможно, студента), который не имеет достаточного опыта в тестировании или вообще имеет опыта работы в компании. Тем не менее вам необходимо организовать процесс так, чтобы новый сотрудник достаточно быстро вошел в курсе дела и начал приносить пользу.
Конечно, вы можете завалить его документацией по продукту и процессам, используемым в компании, определить срок на изучение материала и по истечении данного срока провести небольшой (или большой) экзамен по знанию продуктов и процессов. Это сработает? Наверное, да, если сотруднику хватит терпения на выполенения столь скучной работы в одиночестве и без практики. Но вполне возможно, что данный сотрудник будет демотивирован еще до того, как приступит к выполенению своих служебных обязанностей.
Другой более эффективный, но в тоже время и более дорогой способ вовлечения новых сотрудников в проекты, - это проведение для них специализированных тренингов, на которых присутствует постоянный контакт между сотрудниками и тренерами. В рамках тренингов новые сотрудники знакомятся с продуктами, методиками и процессами. При таком подходе обучение сфокусировано на важных аспектах работы, а сам процесс обучения выглядит динамичным и интересным.
Однако, наличие подобных тренингов должно быть экономически оправданным, а эффективность тренингов возможна только в том случае, если в компании есть грамотные тренеры и отработанные тренинговые программы.
Как часто и в каком количестве вы нанимаете новых сотрудников? Какое соотношение новичков и профессионалов в списке вновь нанятых сотрудников? Очевидно, что нет необходимости создавать тренинговые центры для того, чтобы обучить пару сотрудников, нанятых в течение шести месяцев. Тогда, как же обеспечить плавный ввод сотрудника в проект?
Верификация багов – это одна из первых задач, которую можно поручить начинающему. Данная задача не только позволит изучить продукт, но и даст сотруднику почувствовать, что он или она является частью команды и от его или ее результатов работы также зависит успех проекта. Не стоит давать новому сотруднику верификацию багов, где проектные риски высоки. Однако, вы можете усложнять задачу в зависимости от полученных результатов и назначать на сотрудника баги, верификация которых требует большей внимательности и экспертизы
Эволюция тестера или почему тестеры не хотят быть тестерами
Надоело верифицировать баги
Верификация багов вполне годится как инструмент для обучения, но не годится в качестве основной задачи. Никакой тестер не будет заниматься этим и только этим больше одного месяца. Если к вам не пришли и не сказали, что эта задача просто наскучила, то вам следует самим поинтересоваться - а все ли в порядке, и если вы получите положительный ответ, вам следует усомниться в способностях данного тестера и проанализировать его или ее мотивацию.
Конечно все тестеры верифицируют баги, но лишь потому, что это входит в их круг должностных обязанностей. Но делать это никто не любит.
Надоело исполнять тест кейсы
Когда верификация багов не может быть больше постоянной задачей, а процесс обучения инженера еще не закончен, разумно назначить инженера на исполнение тест кейсов. Однако, добавление данной задачи вовсе не означает отмену предыдущей. Тем не менее, инженер продолжает изучать продукт и предметную область посредством исполнения тест кейсов, и знакомиться с техникой их написания.
Очень важно на данном этапе организовать серию тренингов для инженера, в рамках которых инженер изучит фундаментальные техники функционального тестирования: тестирование граничных значений, классы эквивалентности и т.д. Это позволит инженеру понимать причины того или иного подхода, используемого в тест кейсе.
Если же в вашей компании есть автотесты, то также разумно назначить инженера на разбор упавших тестов. Это позволит инженеру познакомиться с тем, каким образом в компании обеспечена автоматизация тестирования: логи, инфраструктура и т.д.
Исполение тестов новичками позволяет вам оценить качество имеющихся тест кейсов с точки зрения понятности, логичности и завершенности. Если тест кейсы написаны таким языком, что для их прохождения нужно работать в команде два или три года, то вы узнаете об этом очень быстро. Если логирование в автотесте реализовано так, что понять его может только разработчик теста или его коллега, который также принимал участие в написании данного теста, то вы тоже узнаете об этом очень быстро.
Поскольку исполение тестов как и верифицирование багов - это задача, исключающая творческую составляющую, она очень быстро надоест инженеру и вам нужно быть готовым к тому, чтобы дать этому инженеру другую задачу.
Надоело писать тест кейсы
Написание тест кейсов – это задача, которая позволит тестеру задействовать весь свой потенциал и знания, полученные на предыдущих этапах, для тестирования функциональности в продукте. Необходимость написания тест кейсов по определенным правилам сделает этот процесс контролируемым. Таким образом, вы будете понимать что тестируется и как тестируется. Сложность задачи будет зависеть от того, над какой функциональностью работает тестер.
Но как и в двух ранее описанных случаях, не многие способны «клепать» тест кейсы, не теряя при этом энтузиазма. Поэтому, чтобы обеспечить эффективность ручного тестирования и поддержание интереса инженеров к такой работе, вам придется внедрить такие практики, как пострение карт тестирования и exploratory тестирование, а написание тест кейсов свести к минимуму, закрывая лишь высоко приоритетные сценарии и аспекты тестируемых систем, что в дальнейшем будет определять регрессионное тесты.
Не придумываю фичи
Большинство тестеров, с которыми мне довелось общаться, поднимали вопрос о необходимости их участия в разработке фичи. Комментарии, которые появляются в процессе тестирования иногда, а порой и довольно часто, являются поздними изменениями в продукте и они не могут быть реализованы когда план работ уже согласован. Однако, большинство тестеров уверены, что если бы они участвовали в разработке фичей «с самого начала», то продукт бы был лучше.
Нужно отметить, что это достаточно валидное утверждение, а тестеры, которые имеют опыт работы с продуктом, хорошо понимают предметную область и способны не только верифицировать продукт, но и обеспечить его валидацию, действительно полезны в разработке фичей «с самого начала».
Поэтому если ваш инженерный процесс позволяет вовлекать тестировщиков в разработку фичей до того как их начнут реализовывать, то это решает проблему «Я не придумываю фичи».
Тестеры, которые никогда не мечтали быть разработчками оседают имменно на этом этапе.
Хочу писать код
Однако, те инженеры, которые изначально рассматривали тестирование как промежуточный шаг на пути к разработке, непременно объявят вам о своем намерении писать код.
Разработка автотестов – это мощный мотиватор в решении данной проблемы. Как правило, это приводит к появлению конструкций вида:
public class TestClass1{
public static void main (String[] args){
//some code
}
}
Если автоматизация тестирования не выглядит как хаотичный процесс, где каждый тестер делает что хочет и как хочет, а наоборот, имеет четкую стратегию с применением лучших практик, таких как ревью кода, использование сторонних фреймфорков (например, для PHP это может быть Zend framework) и нестандарных решений в тестировании продукта, то автоматизация является серьезным аргументом в решении вопросов «хочу писать код».
Инженеры, занимающиеся автоматизацией тестирования, зачастую решают задачи не меенее сложные чем те, кто разрабатывают новые фичи в продукте. Поэтому большинство тестеров, которые изначально хотели быть разработчиками, вполне удовлетворены задачами этого этапа. При этом все также разрабатывают тестовые спецификации, исполняют тесты, открывают и верифицируют баги и автоматизируют тестирование.
Хочу писать другой код
Но даже при наличии автоматизации вы не можете гарантировать, что к вам не придут и не скажут «Хочу писать другой код». В этом случае тестер, который занимался автоматизацией, по каким-то причинам не понял или не увидел должного развития в рамках предложенных ему задач и считает, что программирование там, где разрабатываются фичи.
Как с этим бороться?
Менеджер vs. эволюция
Никак!! Поскольку верификация багов, исполнение тестов, дизайн тестов, участие в разработке новых фичей, разработка автотестов – это эволюция тестера. С эволюцией нет смысла бороться, ее нужно учитывать в планировании проектов, в формировании команды, в формализации карьерного роста и т.д.
Используйте данные знания, чтобы мотивировать сотрудника к работе. Определите цели и задачи для инженера. Обеспечьте прозрачность процесса контроля достижений посредством обратной связи. Дайте возможность изучать и применять новые технологии и практики.
Если же тестер заявил о том, что ему не интересно тестирование вообще и он хочет заниматься разработкой фичей, то ваша цель теперь – сохранить сотрудника в компании. Посчитайте, сколько должно пройти времени с момента найма сотрудника и до того, как сотрудник начнет приносить серьезный вклад в проект. Вполне возможно что инженер, прошедший школу тестирования и научившийся рограммировать, будет не менее эффективен и полезен в разработке.
В тех случаях, когда инженер способен и готов руководить, сделайте его наставником, руководителем группы или менеджером. Такое назначение замотивирует инженера работать в вашем отделе. Если же такой вариант невозможен, то приложите все усилия, чтобы перевести инженера в отдел разработки.
Как искать «правильных» тестеров
Для того, чтобы обеспечить плавный рост инженера и при этом сохранить эффективность его работы на каждом из указанных этапов, важно подбирать «правильных» тестеров. Критерий правильности может варьироваться в зависимости от рассматриваемой должности. Очевидно, что требования к инженеру, занимающемуся ручным тестированием и к инженеру, в задачи которого входят автоматизация, будут различны.
Как правило, при принятии решения о приеме на работу кандидата учитывается соответствие его техническим требованиям к должности: способность решать аналитические задачи, знание предметной области и т.д. Насколько кандидат подходит психологически на данную вакансию определяется по принципу нравится или не нравится, или игнорируется совсем.
Важно отметить, что не каждый тестер может быть разработчиком, также как не каждый разработчик может быть тестером. Ключ к решению данного вопроса кроется в психологическом портрете тестера и разработчика.
Основная цель тестирования – это поиск багов в продукте. Следовательно, каждый тестер должен фокусироваться на поиске различий и несоотвествий. В то время как разработчик должен ориентироваться на обобщение фактов при создании новых фичей. Таким образом, контролирующим вопросом при собеседовании кандидата будет: «Сравните, пожалуйста, объект А с объектом Б». А дальше внимательно слушайте ответы: чего в них больше - обобщений или различий.
Конечно, вопрос сравнения объектов является далеко не единственным в определении психологического портрета кандидата, а лишь иллюстрирует данный метод.
Если построить интервью таким образом, что сначала определяется насколько кандидат психологически подходит на данную вакансию, а только потом выяснять его профессиональные способности, то это позволит избежать проблем в будущем: когда инженер отлично знает предметную область и тем не менее не может или не хочет выполнять предложенные задачи.
Заключение
Итак, какие полезные выводы можно сделать на основании вышеизложенного материала:
1. Нужно искать «правильных» тестеров - для того, чтобы обеспечить плавность в карьерном росте и эффектиность работы на разных этапах.
2. Учитывать эволюцию в проектных планах, в формировании команды и т.д., и ни в коем случае не бороться и не препятствовать ей.
3. Делать процесс роста интересным. Как правило, это достигается с помощью своевренной смены задач, сохраняя тем самым мотивацию сотрудника.
4. Всегда сохранять сотрудника в отделе или компании.
Комментариев нет:
Отправить комментарий