Test Design Techniques
Specification-based or Black-box Techniques:
- Equivalence Partitioning
- Boundary Value Analysis
- Decision Table Testing
- State Transition Testing
- Use Case Testing
Structure-based or White-box Techniques:
- Statement Testing and Coverage
- Decision Testing and Coverage
- Condition coverage and multiple condition coverage
Experience-based techniques:
- Error guessing
- Exploratory testing
*ISTQB Foundation Level Syllabus
середу, 20 жовтня 2010 р.
Методи Тестування
Test Techniques
1. Based on the software engineer’s intuition and experience
1.1. Ad-hoc testing
1.2. Exploratory testing
2. Specification-based techniques
2.1. Equivalence partitioning
2.2. Boundary-value analysis
2.3. Decision table
2.4. Finite-state machine-based
2.5. Testing from formal specifications
2.6. Random testing
3. Code-based techniques
3.1. Control-flow-based criteria
3.2. Data flow-based criteria
3.3. Reference models for code-based testing
4. Fault-based techniques
4.1. Error guessing
4.2. Mutation testing
5. Usage-based techniques
5.1. Operational profile
5.2. Software Reliability Engineered Testing
6. Techniques based on the nature of the application
6.1. Object-oriented testing
6.2. Component-based testing
6.3. Web-based testing
6.4. GUI testing
6.5. Testing of concurrent programs
6.6. Protocol conformance testing
6.7. Testing of real-time systems
6.8. Testing of safety-critical systems
7. Selecting and combining techniques
7.1. Functional and structural
7.2. Deterministic vs. random
*Guide to the Software Engineering Body of Knowledge (IEEE -Computer Society)
1. Based on the software engineer’s intuition and experience
1.1. Ad-hoc testing
1.2. Exploratory testing
2. Specification-based techniques
2.1. Equivalence partitioning
2.2. Boundary-value analysis
2.3. Decision table
2.4. Finite-state machine-based
2.5. Testing from formal specifications
2.6. Random testing
3. Code-based techniques
3.1. Control-flow-based criteria
3.2. Data flow-based criteria
3.3. Reference models for code-based testing
4. Fault-based techniques
4.1. Error guessing
4.2. Mutation testing
5. Usage-based techniques
5.1. Operational profile
5.2. Software Reliability Engineered Testing
6. Techniques based on the nature of the application
6.1. Object-oriented testing
6.2. Component-based testing
6.3. Web-based testing
6.4. GUI testing
6.5. Testing of concurrent programs
6.6. Protocol conformance testing
6.7. Testing of real-time systems
6.8. Testing of safety-critical systems
7. Selecting and combining techniques
7.1. Functional and structural
7.2. Deterministic vs. random
*Guide to the Software Engineering Body of Knowledge (IEEE -Computer Society)
середу, 13 жовтня 2010 р.
Сертифікати по Тестуванню
Testing Certifications
CAST - Certified Associate in Software Testing
ISTQB - International Software Testing Qualifications Board
CSTP - Certified Software Test Professional
CTM - Certified Test Manager
CAST - Certified Associate in Software Testing
ISTQB - International Software Testing Qualifications Board
CSTP - Certified Software Test Professional
CTM - Certified Test Manager
вівторок, 12 жовтня 2010 р.
7 Принципів Тестування
Принцип 1. Тестування виявляє присутність дефектів.
Тестування виявляє, що дефекти присутні, але не може запевнити, що дефекти відсутні. Тестування зменшує ймовірну кількість незнайдених дефектів, та якщо дефектів не знайдено, це не гарантує їхньої відсутності.
Принцип 2. Вичерпне тестування неможливе.
Тестування всього (усіх комбінацій введень і передумов) є неможливе за виключенням тривіальних випадків. Замість намагань, протестувати все, використовується аналіз ризиків та пріоритетів, що допомагає провести цілеспрямоване тестування.
Принцип 3. Раннє тестування.
Тестування розпочинається так швидко як це можливо і фокусується на визначенні цілей.
Принцип 4. Групування дефектів.
Зусилля тестування фокусуються пропорційно до очікуваної і отриманої густини дефектів по модулях. Декілька модулів зазвичай містять більшість дефектів, знайдених під час дорелізного тестування, або повязаних в основному з недосконалостями операційних систем.
Принцип 5. Парадокс пестицидів.
Якщо тестування повторюється, то один набір тест кейсів не буде знаходити нові дефекти. Уникнути "парадокс пестицидів" можна регулярною перевіркою, оновленням, та дописуванням нових тестів.
Принцип 6. Тестування залежить від контексту.
Тестування відрізняється в залежності від контексту продукту. Для прикладу, програмне забезпечення з критичним захистом тестується інакше ніж комерційний сайт.
Принцип 7. Відсутність дефектів оманлива.
Знаходження та виправлення дефектів не допомагає, якщо система непридатна і не задовільняє потреб та очікувань користувача.
*ISTQB Foundation Level Syllabus
Тестування виявляє, що дефекти присутні, але не може запевнити, що дефекти відсутні. Тестування зменшує ймовірну кількість незнайдених дефектів, та якщо дефектів не знайдено, це не гарантує їхньої відсутності.
Принцип 2. Вичерпне тестування неможливе.
Тестування всього (усіх комбінацій введень і передумов) є неможливе за виключенням тривіальних випадків. Замість намагань, протестувати все, використовується аналіз ризиків та пріоритетів, що допомагає провести цілеспрямоване тестування.
Принцип 3. Раннє тестування.
Тестування розпочинається так швидко як це можливо і фокусується на визначенні цілей.
Принцип 4. Групування дефектів.
Зусилля тестування фокусуються пропорційно до очікуваної і отриманої густини дефектів по модулях. Декілька модулів зазвичай містять більшість дефектів, знайдених під час дорелізного тестування, або повязаних в основному з недосконалостями операційних систем.
Принцип 5. Парадокс пестицидів.
Якщо тестування повторюється, то один набір тест кейсів не буде знаходити нові дефекти. Уникнути "парадокс пестицидів" можна регулярною перевіркою, оновленням, та дописуванням нових тестів.
Принцип 6. Тестування залежить від контексту.
Тестування відрізняється в залежності від контексту продукту. Для прикладу, програмне забезпечення з критичним захистом тестується інакше ніж комерційний сайт.
Принцип 7. Відсутність дефектів оманлива.
Знаходження та виправлення дефектів не допомагає, якщо система непридатна і не задовільняє потреб та очікувань користувача.
*ISTQB Foundation Level Syllabus
середу, 29 вересня 2010 р.
вівторок, 17 серпня 2010 р.
Open source Test Management tools
1. Bugzilla Testopia
2. Data Generator
3. Fitnesse
4. qaManager
5. QATraq
6. RTH
7. RTH-Turbo
8. Speed Test
9. TestLink
10. TestMaster
11. Vienna 2
12. XStudio
2. Data Generator
3. Fitnesse
4. qaManager
5. QATraq
6. RTH
7. RTH-Turbo
8. Speed Test
9. TestLink
10. TestMaster
11. Vienna 2
12. XStudio
середу, 4 серпня 2010 р.
понеділок, 2 серпня 2010 р.
QA Management tool - QMetry
QMetry
1. Requirements -
* manage your test requirements,
* provides complete traceability from requriements - testcases - defects
* can import your requirement from xls/.csv to QMetry
2. Test Plan -
* Manage your testplan according to the IEEE standandard
* Customize it to match you requirement
3. Test cases/Suites/Status
* Define test cases
* Link them to requirements / defects
* Create test suite and bundle test cases to them
* Create environments/platforms to record your test case run results again
* Attach test logs and write comments for collaborative mode
* Record your run results for later comparison
4. Bugs:
QMetry is integrated with tools across testing lifecycle due to its strong web based API:
* Test Automation tools like - QTP, Selenium, Silk test
* Bug tracking tool - JIRA, Bugzilla, Mantis
* Other tools - Elementool, Targetprocess
5. Test Reports:
* We have exhaustive reports for traceability, testcases, defects at project level, across releases, across builds
* We also have standard queries & we publish our Read only database schema using which you can write your own custom queries and pull out almost anything from QMetry
6. Test Metrics:
* QMetry dashboard has 30+ metrics with pie charts/line graphs/bar charts
* Graphs have complete drill down
* Metrics can be downloaded in pdf and mailed across to team members
* view data in graphical format or tabular/data grid view
* Add the graphs important to you to your favorite for ease of navigation
7. Others:
* Version control - change management across QMetry, smallest of the change recorded by which field changed, who made the change, when was the change made etc.
* Sort, search, filter option
* Email notification for geographically distribute team to function in tandem
*Role based security - create your own roles and define access rights
* Can add User defined fields and modify the custom lists
* Import to and export from xls/.csv requirements, test cases, test suite run results
* Extensive release & build management
* copy testcases/requirements/testsuite from one build/release/project to another.
1. Requirements -
* manage your test requirements,
* provides complete traceability from requriements - testcases - defects
* can import your requirement from xls/.csv to QMetry
2. Test Plan -
* Manage your testplan according to the IEEE standandard
* Customize it to match you requirement
3. Test cases/Suites/Status
* Define test cases
* Link them to requirements / defects
* Create test suite and bundle test cases to them
* Create environments/platforms to record your test case run results again
* Attach test logs and write comments for collaborative mode
* Record your run results for later comparison
4. Bugs:
QMetry is integrated with tools across testing lifecycle due to its strong web based API:
* Test Automation tools like - QTP, Selenium, Silk test
* Bug tracking tool - JIRA, Bugzilla, Mantis
* Other tools - Elementool, Targetprocess
5. Test Reports:
* We have exhaustive reports for traceability, testcases, defects at project level, across releases, across builds
* We also have standard queries & we publish our Read only database schema using which you can write your own custom queries and pull out almost anything from QMetry
6. Test Metrics:
* QMetry dashboard has 30+ metrics with pie charts/line graphs/bar charts
* Graphs have complete drill down
* Metrics can be downloaded in pdf and mailed across to team members
* view data in graphical format or tabular/data grid view
* Add the graphs important to you to your favorite for ease of navigation
7. Others:
* Version control - change management across QMetry, smallest of the change recorded by which field changed, who made the change, when was the change made etc.
* Sort, search, filter option
* Email notification for geographically distribute team to function in tandem
*Role based security - create your own roles and define access rights
* Can add User defined fields and modify the custom lists
* Import to and export from xls/.csv requirements, test cases, test suite run results
* Extensive release & build management
* copy testcases/requirements/testsuite from one build/release/project to another.
пʼятницю, 30 липня 2010 р.
QA Management tools
1. HP Quality Center
Demo
Free to try
2. QPack Application Lifecycle Management
3. XStudio
4. Microsoft Visual Studio Test Professional 2010
5.QMetry
6. SmarteQM
7. Rational Quality Manager
Demo
8. Vienna - Test Management™
9. Quality
10. Software Planner
11. JIRA Sample File - Test Case Management
12. Jite - Test Management
13. Rally
Demo
Free to try
2. QPack Application Lifecycle Management
3. XStudio
4. Microsoft Visual Studio Test Professional 2010
5.QMetry
6. SmarteQM
7. Rational Quality Manager
Demo
8. Vienna - Test Management™
9. Quality
10. Software Planner
11. JIRA Sample File - Test Case Management
12. Jite - Test Management
13. Rally
четвер, 15 липня 2010 р.
Selenium
Web Application Testing System
Selenium IDE is a Firefox add-on that records clicks, typing, and other actions to make a test, which you can play back in the browser.
Selenium Remote Control (RC) runs your tests in multiple browsers and platforms. Tweak your tests in your preferred language.
Selenium Grid extends Selenium RC to distribute your tests across multiple servers, saving you time by running tests in parallel.
Podcast: Using Selenium for application testing
Tutorial: Introducing Selenium IDE, an open source automation testing tool
Tutorial: Installing and running Selenium-RC in Perl
Selenium IDE is a Firefox add-on that records clicks, typing, and other actions to make a test, which you can play back in the browser.
Selenium Remote Control (RC) runs your tests in multiple browsers and platforms. Tweak your tests in your preferred language.
Selenium Grid extends Selenium RC to distribute your tests across multiple servers, saving you time by running tests in parallel.
Podcast: Using Selenium for application testing
Tutorial: Introducing Selenium IDE, an open source automation testing tool
Tutorial: Installing and running Selenium-RC in Perl
понеділок, 12 липня 2010 р.
Рекомендації
Як писати Рекомендації:
1. Рекомендації завжди пишуться тільки позитивні!
2. Завжди використовуйте ім'я Рекомендованого.
3. Опишіть як довго Ви знаєте Рекомендованого, як довго Ви з ним/нею працюєте, перелічіть обовязки на займаній посаді.
4. Зазначте найкращі риси, якими Рекомендований/на відзначився/лася у роботі, базовані на реальних подіях (аналітичні здібності, виконавчіть, акуратність, швидкість, самостійне вирішення проблем, хороша комунікація, здатність швидко навчатися, культура спілкування, якісна співпраця у колективі, визнання помилок, робота над покращенням результатів, і так далі).
5. Упускайте слабкі сторони. Якщо незнаєте, що позитивного написати, то краще відмовтесь від написання Рекомендацій.
6. Дотримуйтесь тематичних меж у написанні Рекомендацій. Це не твір на тему Рекомендованого. Не більше однієї, двох сторінок.
7. Незважаючи на те що вік, сімейний статус, приналежність до певних груп, релігія і тд і тп є дуже важливими, не коментуйте цього.
8. Залишіть свої контакти, якщо Ви не заперечуєте відповідати на запитання, які можуть виникнути у роботодавця.
9. Уважно перечитуйте. Рекомендації репрезентують не тільки Рекомендованого а й Вас також. :)
1. Рекомендації завжди пишуться тільки позитивні!
2. Завжди використовуйте ім'я Рекомендованого.
3. Опишіть як довго Ви знаєте Рекомендованого, як довго Ви з ним/нею працюєте, перелічіть обовязки на займаній посаді.
4. Зазначте найкращі риси, якими Рекомендований/на відзначився/лася у роботі, базовані на реальних подіях (аналітичні здібності, виконавчіть, акуратність, швидкість, самостійне вирішення проблем, хороша комунікація, здатність швидко навчатися, культура спілкування, якісна співпраця у колективі, визнання помилок, робота над покращенням результатів, і так далі).
5. Упускайте слабкі сторони. Якщо незнаєте, що позитивного написати, то краще відмовтесь від написання Рекомендацій.
6. Дотримуйтесь тематичних меж у написанні Рекомендацій. Це не твір на тему Рекомендованого. Не більше однієї, двох сторінок.
7. Незважаючи на те що вік, сімейний статус, приналежність до певних груп, релігія і тд і тп є дуже важливими, не коментуйте цього.
8. Залишіть свої контакти, якщо Ви не заперечуєте відповідати на запитання, які можуть виникнути у роботодавця.
9. Уважно перечитуйте. Рекомендації репрезентують не тільки Рекомендованого а й Вас також. :)
четвер, 8 липня 2010 р.
Денний/Тижневий Тест Звіт
Formulating test status reports based on daily status criteria.
Your management or the customer are asking for some very standard test status reports, so the good news is that this is relatively straightforward.
Test execution: The most important metrics in this are total test cases, test cases executed, test cases remaining, test execution rate, and "glidepath execution rate." Total test cases are, obviously, the total number of cases you must execute during this project. Test cases executed is the sum total of cases which have been executed (pass or fail, but NOT including "blocked" cases). Test cases remaining should be the sum of cases not executed plus cases blocked, for this metric represents all the work remaining. Test execution rate should be the average number of cases your team is executing per day. Finally, the glidepath is the rate of execution your team needs to maintain in order to complete the project.
To calculate the execution rate, take the total number of cases executed (passed, failed, but not "blocked") and divide by the number of working days. Note that you also have to communicate the number of cases failed and the time it will take to retest these. Some teams want you to report this as a separate metric, some teams want the "failed" cases to not count as executed, and be counted as remaining test cases.
To calculate the glidepath rate, take the total number of remaining cases divided by the number of days remaining in the project. If you have 100 test cases remaining, and 10 days left, you need to execute 10 test cases per day.
The critical thing to keep in mind here is what your manager or customer care about. They want to know two things, above all else: 1) Are you on track to be done on time, and 2) Is the product in good shape? The way they answer the on track question is simple -- is your average test case execution rate (the average number of cases executed per working day) higher than your glidepath rate? If yes, your project is probably green. If not, your project is yellow or red.
The next metric here is the test case failure rate. This is a strong indicator of product quality, as well as your test execution rate. If you have a 50% failure rate, that means 1 out of 2 test cases are failing. That indicates terrible requirements definition or engineering quality. If your failure rate is significantly less (10%, 5%) it probably means the requirements were well defined and the code quality is high. It could also mean that your test team is overlooking defects -- as project lead, you need to have your pulse on your team's performance, and be able (and willing) to tell management if you think your team is overlooking defects in the project. Failure rate is also helpful in calculating execution rate and glidepaths. Like I said, some teams want all tests executed counted in the execution rate, some only want passes (personally, as a manager I want to see the PASS rate as well as the executed rate). Calculating the failure rate is also simple -- how many test cases in 100 are failing?
Finally, bug rates. The most important bug metric right now is probably how many defects are generated per test case. So if you have executed 100 test cases, how many defects have resulted from those? Coupled with the count of remaining test, it's a good way to get a decent idea of how many defects are still 'lurking' in the product.
Metrics are a funny thing. They can be used for good or warped for bad. It's very important to focus on the metrics themselves, and separate the discussion of what the metrics might mean. Above all, if the metrics indicate a schedule or product risk, don't try to paint an artificially pretty picture. Be forthcoming in the information and help management through the repercussions.
Скопійована відповідь з http://searchsoftwarequality.techtarget.com/
Відповідь експерта John Overbaugh, Director of Quality Assurance, Medicity, Inc.
Your management or the customer are asking for some very standard test status reports, so the good news is that this is relatively straightforward.
Test execution: The most important metrics in this are total test cases, test cases executed, test cases remaining, test execution rate, and "glidepath execution rate." Total test cases are, obviously, the total number of cases you must execute during this project. Test cases executed is the sum total of cases which have been executed (pass or fail, but NOT including "blocked" cases). Test cases remaining should be the sum of cases not executed plus cases blocked, for this metric represents all the work remaining. Test execution rate should be the average number of cases your team is executing per day. Finally, the glidepath is the rate of execution your team needs to maintain in order to complete the project.
To calculate the execution rate, take the total number of cases executed (passed, failed, but not "blocked") and divide by the number of working days. Note that you also have to communicate the number of cases failed and the time it will take to retest these. Some teams want you to report this as a separate metric, some teams want the "failed" cases to not count as executed, and be counted as remaining test cases.
To calculate the glidepath rate, take the total number of remaining cases divided by the number of days remaining in the project. If you have 100 test cases remaining, and 10 days left, you need to execute 10 test cases per day.
The critical thing to keep in mind here is what your manager or customer care about. They want to know two things, above all else: 1) Are you on track to be done on time, and 2) Is the product in good shape? The way they answer the on track question is simple -- is your average test case execution rate (the average number of cases executed per working day) higher than your glidepath rate? If yes, your project is probably green. If not, your project is yellow or red.
The next metric here is the test case failure rate. This is a strong indicator of product quality, as well as your test execution rate. If you have a 50% failure rate, that means 1 out of 2 test cases are failing. That indicates terrible requirements definition or engineering quality. If your failure rate is significantly less (10%, 5%) it probably means the requirements were well defined and the code quality is high. It could also mean that your test team is overlooking defects -- as project lead, you need to have your pulse on your team's performance, and be able (and willing) to tell management if you think your team is overlooking defects in the project. Failure rate is also helpful in calculating execution rate and glidepaths. Like I said, some teams want all tests executed counted in the execution rate, some only want passes (personally, as a manager I want to see the PASS rate as well as the executed rate). Calculating the failure rate is also simple -- how many test cases in 100 are failing?
Finally, bug rates. The most important bug metric right now is probably how many defects are generated per test case. So if you have executed 100 test cases, how many defects have resulted from those? Coupled with the count of remaining test, it's a good way to get a decent idea of how many defects are still 'lurking' in the product.
Metrics are a funny thing. They can be used for good or warped for bad. It's very important to focus on the metrics themselves, and separate the discussion of what the metrics might mean. Above all, if the metrics indicate a schedule or product risk, don't try to paint an artificially pretty picture. Be forthcoming in the information and help management through the repercussions.
Скопійована відповідь з http://searchsoftwarequality.techtarget.com/
Відповідь експерта John Overbaugh, Director of Quality Assurance, Medicity, Inc.
четвер, 8 квітня 2010 р.
Трейс Матриця (Traceability Matrix)
Трейс Матриця дозволяє прослідковувати:
- покриття розробки проекту необхідною документацією;
- покриття розробки проекту кодом, тестовими випадками, тестуванням;
- поточний стан кожної важливої фази проекту;
- контроль внесення змін на всіх етапах розробки.
Трейс Матриці будують в залежності від потреб. Якщо йде мова про прослідковування усіх фаз розробки програмного забезпечення, то таблиця містить розділи, розбиті на колонки (найважливіші точки демонстрації результатів).
Наприклад: Вимоги/Пріоритети/Покриття Функціональними Специфікаціями/Покриття Кодом/Покриття Юніт Тестами/Статус Юніт Тестів/Покриття Тестовою Документацією/Статус Розробки Тестової Документації/Статус Тестування/Часові Витрати/Інше
Найчастіше використовують табличний редактор, який дозволяє змінювати таблиці, використовувати сортування, підтримує збирання статистики (використовування формул, будування графіків, і так далі).
Також є спеціальні програмні забезпечення. Див. Керування Вимогами (Requirements Management).
- покриття розробки проекту необхідною документацією;
- покриття розробки проекту кодом, тестовими випадками, тестуванням;
- поточний стан кожної важливої фази проекту;
- контроль внесення змін на всіх етапах розробки.
Трейс Матриці будують в залежності від потреб. Якщо йде мова про прослідковування усіх фаз розробки програмного забезпечення, то таблиця містить розділи, розбиті на колонки (найважливіші точки демонстрації результатів).
Наприклад: Вимоги/Пріоритети/Покриття Функціональними Специфікаціями/Покриття Кодом/Покриття Юніт Тестами/Статус Юніт Тестів/Покриття Тестовою Документацією/Статус Розробки Тестової Документації/Статус Тестування/Часові Витрати/Інше
Найчастіше використовують табличний редактор, який дозволяє змінювати таблиці, використовувати сортування, підтримує збирання статистики (використовування формул, будування графіків, і так далі).
Також є спеціальні програмні забезпечення. Див. Керування Вимогами (Requirements Management).
вівторок, 30 березня 2010 р.
Пошук Роботи
Резюме - візитна картка.
1. Написати Резюме - перша і необхідна умова, яку варто виконати для того, щоб знайти роботу.
Зразки Резюме
2. Відправити Резюме - друга і не менш необхідна умова, яку варто виконати для того, щоб знайти роботу.
Рекрутери Львова
3. Пройти Співбесіду - третя і найбільш важлива умова, яку варто виконати для того, щоб знайти роботу.
Співбесіди (Запитання та Відповіді)
1. Написати Резюме - перша і необхідна умова, яку варто виконати для того, щоб знайти роботу.
Зразки Резюме
2. Відправити Резюме - друга і не менш необхідна умова, яку варто виконати для того, щоб знайти роботу.
Рекрутери Львова
3. Пройти Співбесіду - третя і найбільш важлива умова, яку варто виконати для того, щоб знайти роботу.
Співбесіди (Запитання та Відповіді)
Співбесіда (Запитання та Відповіді)
Співбесіда - це серйозний екзамен, відрізняється від традиційного екзамену тим, що оцінкою є сума заробітної плати, яку роботодавець готовий заплатити за працівника.
Список сайтів де обговорюють питання, які задаються на співбесідах:
1. All Interview
2. FREQUENTLY ASKED QUESTIONS IN THE INTERVIEW
3. 100 Potential Interview Questions
4. JobEmploymentGuide
5. Как пройти собеседование
Список сайтів де обговорюють питання, які задаються на співбесідах:
1. All Interview
2. FREQUENTLY ASKED QUESTIONS IN THE INTERVIEW
3. 100 Potential Interview Questions
4. JobEmploymentGuide
5. Как пройти собеседование
середу, 24 березня 2010 р.
вівторок, 23 березня 2010 р.
Робота у команді
"Командна робота" та "Проінформованість" у парі значно підвищують коефіцієнт Якості Виробництва.
Комунікація відіграє важливу роль не тільки у повсякденному житті, а й у ІТ галузі, як не дивно.
Вміння передавати та отримувати інформацію значно підвищує коефіцієнт якісної співпраці між членами команди. Важлива для усіх інформація повинна постійно обговорюватись на зустрічах, за чаєм чи кавою, це можна назвати "проектним ефіром" який підтримує командний дух. На великих організаціях/проектах "проектний ефір" варто штучно підтримувати (розсилка, чати, засідання, зустрічі, на рівні так популярної плітки і т.п.).
Свідоме чи несвідоме утримування інформації сприяє зниженню коефіцієнту Якості Виробництва. Непоборною проблемою групи також може стати невміння керівника середнього рівня вірно передати інформацію. У такому випадку найкраще цього уникати пересилаючи копії листів, документів, чатів...
Нижче коротенька стаття про те, як на рівень компанії впливає вміння її працівників комунікувати.
Я знаю: вы умны. Но хорошо ли вы играете в команде?
Комунікація відіграє важливу роль не тільки у повсякденному житті, а й у ІТ галузі, як не дивно.
Вміння передавати та отримувати інформацію значно підвищує коефіцієнт якісної співпраці між членами команди. Важлива для усіх інформація повинна постійно обговорюватись на зустрічах, за чаєм чи кавою, це можна назвати "проектним ефіром" який підтримує командний дух. На великих організаціях/проектах "проектний ефір" варто штучно підтримувати (розсилка, чати, засідання, зустрічі, на рівні так популярної плітки і т.п.).
Свідоме чи несвідоме утримування інформації сприяє зниженню коефіцієнту Якості Виробництва. Непоборною проблемою групи також може стати невміння керівника середнього рівня вірно передати інформацію. У такому випадку найкраще цього уникати пересилаючи копії листів, документів, чатів...
Нижче коротенька стаття про те, як на рівень компанії впливає вміння її працівників комунікувати.
Я знаю: вы умны. Но хорошо ли вы играете в команде?
Підписатися на:
Дописи (Atom)
Публікації
