Тест-кейси: що, як, навіщо
Привіт всім! Мене звати Максим Бодня, я Lead QA у компанії Customertimes, маю 6+ років досвіду у Quality Assurance. Працював з маленькими та великими проєктами / компаніями, а також у стартапах, тож радий поділитися досвідом, який отримав на своєму QA-шляху!
Сьогодні я розповім про тест-кейси і те, як з ними працювати. Щиро вірю, що мої поради комусь допоможуть налагодити процес тестування, а комусь — взагалі почати писати тест-кейси. У статті не буде чогось ультрамодного на кшталт історії про те, як «ШІ допоможе нам і врятує світ». Цей текст більше про рутинну роботу та про те, як покращити та оптимізувати її.
Трохи, як то кажуть, бази
Тест-кейс — це набір вхідних значень, попередніх умов виконання, очікуваних результатів і післяумов, розроблених для конкретної мети або умови тестування. Наприклад, для виконання певного програмного шляху або для перевірки відповідності певній вимозі.
З чого він складається? Усе просто та складно водночас:
- номер (унікальний номер, за яким можна знайти цей тест-кейс або який можна вказати у вимогах);
- попередні умови (дії, які повинні бути реалізовані до початку перших кроків. Наприклад, «налаштування прав редагування документа для користувача»);
- опис (інформація чи роз’яснення, також дуже часто саме тут розписують кроки тест-кейсу);
- кроки (які дії потрібно виконати, щоб отримати очікуваний результат);
- результат (тест пройшов чи ні);
- післяумови (наприклад, видалити документ або повернути налаштування доступів користувача);
- версія (кейсу, програми тощо);
- коментарі;
- середовище.
Для цього пропоную використовувати спеціальні програми: TestomatIO, TestRail, Zephyr, Xray. І, звісно, я розумію, що вони не є безкоштовними. Тож раджу дізнатись, чи є щось схоже у вашої компанії або замовника, з яким ви працюєте. Якщо ні — то Excel, Confluence або якийсь текстовий редактор нас також влаштує, тож не переймайтесь!
Чому потрібно вести тест-кейси та де їх зберігати
Завжди мріяв це написати: тест-кейси — це правильно. Це надзвичайно важливий крок в роботі з тестовою документацією. А ще вони:
- дозволяють зрозуміти покриття вимог вашими тестами;
- допомагають не забути, що саме ви протестували;
- систематизують всю подальшу роботу (якщо у вас виникнуть питання, чи тестували ви щось, то у вас буде підтвердження цього).
За власним досвідом скажу, що рано чи пізно всі приходять до ведення тест-кейсів. Але, на жаль, частіше це відбувається пізно, а не рано — і кумедно, що цей момент зазвичай настає, коли у вас часу на це просто обмаль.
Якщо ж ви людина-perfect-тайм-менеджмент, або, наприклад, у вас небагато роботи, або ж ваші задачі ще не сформовані — це найкращий момент, щоб привести все до ладу та розробити тест-кейси.
У мене є багато прикладів, як мої знайомі на питання «Чи пишете ви тест-кейси?» відповідали: «Та ні, в нас не вимагають». А потім за іронією долі в їхньому житті наставала ситуація «Тест-кейси потрібні asap! Це горить!» — тож, звісно, тест-кейси розроблялись абияк і в гарячці. Тож я пропоную подбати про це завчасно.
Або ж взяти мій особистий кейс: я працював на проєкті разом з командою замовника. І приблизно 70% тест-кейсів до початку нашого співробітництва були описані тільки за допомогою назв.
А тепер уявіть: проєкту приблизно 10 років, його система дуже комплексна, в ній автоматизовано десь 6000 тест-кейсів (регресія: 1500 тест-кейсів) та багато з них описані тільки назвою.
Існує навіть кейс, в якому написано: «Упевнись, що у документа змінюється статус з „У процесі“ на „На перевірці“». Ми всі розуміємо, що це дуже узагальнена назва та через це досить складно встановити, який саме документ потрібно тестувати та в якому з шести модулів його шукати.
А ще не забуваймо, що у різних документів існують різні типи перевірок. Так, наприклад, в одного документа є перевірка авторами, а в іншого її немає. Тож, щоб такої ситуації не виникало, краще одразу розробляти тест-кейси максимально зрозуміло та якісно.
З чого почати створення тест-кейсу
Я раджу почати зі створення шаблону для вашої команди та проєкту. Вам потрібно визначити параметри, яким відповідатиме ваш тест-кейс. Обрати поля, які використовуватимете. Якщо ви обрали спеціальну програму, то там більшість із цих полів уже є та ви можете щось прибрати або додати за необхідності.
Назва
Назва повинна бути зрозумілою (у читача не має виникати питань, що та як робити), точно описувати певну дію і не бути занадто загальною.
Звернемось до кількох прикладів:
Опис «Упевнись, що в документа змінюється статус з „У процесі“ на статус „На перевірці“» краще замінити на такий: «Перевірити, що публікація змінює статус „У процесі“ на статус „На перевірці“, коли користувач починає процес перевірки чернетки».
Зауважте, тут ми вказали, який саме документ ми перевіряємо та яку дію виконуємо.
Статус «Перевірити, що користувач може редагувати документ» краще переписати так: «Перевірити, що автор з правами редагування публікацій може вносити зміни в публікації» — погодьтесь, це довше, але зрозуміліше.
Передумови
На цьому етапі ви маєте вказати, що саме потрібно зробити перед початком перших кроків у цих тест-кейсах. Обов’язкові параметри, налаштування або дії. Тут важливо визначитись, як саме додавати пункти — тобто потрібно розробити правила та чітку послідовність.
- у користувача повинні бути права на створення документа. Ще бажано написати, як саме надати ці права, наприклад: Налаштування → Користувачі → Права на створення документа;
- публікація має бути в статусі (в процесі) або ж має бути вказаний весь перелік того, що потрібно зробити. Наприклад: Створити документ з типом «Публікація» → Заповнити поля → Натиснути кнопку «Почати роботу з документом».
Ще є варіант додати посилання на інший тест-кейс, який відповідає тим крокам, що вам потрібні. Хтось так робить, хтось вважає це поганою практикою. Що я можу виділити з плюсів:
- непотрібно розписувати багато передумов (скорочує час на написання кейсів);
- кейси йдуть послідовно.
- це може перетворитись на незрозумілий ланцюг посилань;
- якщо хтось не вкаже передумови, то кейс не буде пройдений;
- втрачається принцип один тест кейс одна перевірка, та повнота цього кейсу;
- не завжди зручно для автоматизаторів.
Ми не використовуємо посилань на інші кейси в передумовах, тому що багато хто в команді мав негативний досвід який належить до мінусів, що я описав вище.
Кроки (мабуть, найскладніше)
Деякі тестувальники описують все, що роблять, окремими кроками. Виходить дуже довго, тож підтримувати такі кейси — та ще робота. А тепер уявіть, що хтось прописує кожний крок та навіть більше. І навіть випадок переведення миші в інший кут — це окремий крок в тест-кейсі. Будь-який продукт — це складний та комплексний світ, тож просто уявіть цей обсяг кроків та наскільки об’ємним виходить такий тест-кейс.
Але є й інші випадки: коли все описується ну ду-у-уже поверхово.
Приклад з мого особистого досвіду:
Хтось з менеджерів сказав, що ми витрачаємо багато часу на написання тест-кейсів. І він нещодавно прочитав статтю про те, що якась компанія (на жаль, не згадаю назву) робить ось такі поверхові кейси та живе собі щасливо! Так-от, запровадивши це, я усвідомив, що так ми ніколи ще не помилялись!
Задумка була така: оптимізувати затрати часу на написання та проходження тест-кейсу. А також писати все в описі. Виходив дуже довгий опис, але водночас нам не потрібно було відкривати тест-кейс. Звісно, на початку це допомогло писати тест-кейси швидше та проходити їх оперативніше. Але колеги з нашої команди були залучені й на інших проєктах, а регресія відбувалася, звісно, не кожен день, отже частина з тих кейсів просто забувалась!
Звісно, це все було зрозумілим людям, які знайомі з продуктом та постійно проходять ці тест-кейси, але нові люди без досвіду роботи з продуктом або ті, які певний час не працювали на цьому проєкті, не завжди могли зрозуміти, про що йшлося.
Який висновок я можу зробити з цього? Так, справді, спочатку ми оптимізували затрати часу, але потім під час активної розробки довелось переписувати всі тест-кейси, і це затягнуло роботу з дедлайнами на величезний період. Тож раджу не робити швидких висновків, обмірковуйте та розглядайте всі плюси та мінуси нових запропонованих підходів.
Звернемось до більш практичних прикладів:
Як не треба робити: Крок 1 — меню, що випадає. Крок 2 — документи. Крок 3 — публікації. Крок 4 — документ.
Краще описати так: Крок 1 — меню, що випадає → Документи → Публікації → Документ 1.
Якщо у вас не фінальний дизайн і може бути багато змін, то спробуйте мінімізувати прив’язку до назв. Наприклад, замість того, щоб написати «Натиснути кнопку „Старт“», напишіть «Натиснути кнопку для початку роботи».
Очікуваний результат
Потрібно чітко описати, чого ви очікуєте, наприклад, наприкінці цього кроку. Поради: Один крок = один результат. Можете додати картинку, анімацію або відео — це допоможе зрозуміти іншим колегам, чого ж їм очікувати, щоб не було, як в тому мемі «сурпрайз-сурпрайз!».
Якщо вам потрібно перевірити багато майже однакових кейсів, це можна зробити за допомогою таблиці, яку я наводжу нижче.
Тож, як бачимо, якщо є п’ять документів з одного модуля, створення цих документів буде однаковим, окрім вибору типу документів та дії, щоб змінити статус документа. Це можна позначити в таких кроках у тест-кейсі:
Крок 1 — Натиснути кнопку «Створення документа».
Крок 2 — Обрати тип документа 1/2/3/4 чи 5.
Крок 3 — Заповнити поля.
Крок 4 — Створити документ.
Крок 5 — Відкрити меню.
Крок 6 — Виконати дію «1, 2, 3, 4, 5» (Наприклад: «Розпочати перевірку»).
Крок 7 — Впевнитись, що статус документа змінився.
А потім — раджу розробити таблицю, в якій ви відобразите результати тестування цього тест-кейсу.
Або прописати все окремими кейсами. Все залежить від проєкту, правил та домовленості в команді — обирати вам:
Документ 1 статус 1.
Документ 1 статус 2 і так далі.
Документ 2 статус 1 і так далі.
Якщо вже говорити про сам формат, то спочатку в нас був стандартний за формою в TestRail:
Кроки
Крок 1
Крок 2
Крок 3
Очікуваний результат
Результат 1
Результат 2
Результат 3
Потім ми вирішили його змінити на зручніший, тому що після кроку одразу йде результат, і це дозволяє оптимізувати час проходження тест-кейсів як мінімум, якщо у вас багато кроків. Тому не потрібно гортати вниз, щоб побачити результат. І ще один плюс цього підходу для автоматизаторів — їм це теж легше автоматизувати, адже в TestRail є функція «Таблиці», яка має такий вигляд:
Очікуваний результат
У цьому випадку ми домовились використовувати секцію «Очікуваний результат» для додаткової інформації або скріншотів. У Zephyr, наприклад, так одразу все й побудовано.
Трохи порад. Dos and don’ts
Не робіть звалище кейсів
Розбивайте ваші кейси за модулями, функціями, частинами для більш чіткої картини, кращої навігації та зручності. Ви подякуєте собі, коли вам знадобиться перевірити якийсь один модуль. Зробіть розбивку за типами тестування: регресія, смоук, локалізація, простота використання, інтеграція тощо).
Домовтесь про теги:
- Інтерфейс. Ці кейси допоможуть вам працювати та відслідковувати історію змін дизайну інтерфейсу. Бо хто знає, коли захочуть використати старий дизайн.
- Позитивні теги — перевірка функціоналу на предмет тих вимог, яким він має відповідати.
- Негативні теги — перевірка функціоналу на предмет тих вимог, яким він не має відповідати. Інколи ви можете помітити недоліки за допомогою цих кейсів.
Звернемось до кількох прикладів:
У нас була задача на додавання нового типу документа та прав користувачам для роботи із цим типом документів. Користувачу можна було дати такі права: створення, редагування, видалення. У чому ж була проблема? Я написав тест-кейси та додав негативних тегів. Потім я спробував редагувати або видалити документ, не надавши права користувачу.
Усе було добре і користувач без прав не міг це зробити. А от коли я дав користувачу права на редагування, але не надав на видалення — я зміг видалити документ. Вийшло так, що в правах на редагування було додано і видалення документів, хоча під видалення є окремі права. Не забувайте про це.
Team spirit
Дуже важливо залучати якомога більше людей до процесу розробки тест-кейсів. Раджу зробити певні сесії для обговорення, бо, по-перше, у суперечці народжується істина. А по-друге, це буде для вас своєрідним нестандартним тімбілдингом! Жартую, звісно, але щось у цьому є.
Якщо на проєкті є інші команди — їх теж залучайте до цього обговорення. У мене на одному проєкті було п’ять команд, і на лідівському мітингу ми запропонували менеджеру тестувальників розробити шаблон для тест-кейсів. Приблизно за місяць роботи ми його зробили: створили Word-документ, туди внесли параметри, які ми використовуємо у тест-кейсах. Далі ми до кожного параметра додавали правила, яким він повинен відповідати.
Раз на тиждень у нас була сесія, під час якої ми обговорювали та відстоювали ці правила. Коли ми закрили всі нюанси з мануального тестування, то показали цей шаблон команді автоматизаторів. І вони теж зробили декілька сесій та запропонували правки.
Після цього, врахувавши всі правки та побажання, ми представили підсумковий документ. Якщо на вашому проєкті є такі святі люди, як автоматизатори, дуже наполягаю їх теж залучати, адже вам потрібно зробити максимально зручний шаблон та кейси, щоб оптимізувати витрати часу на написання та автоматизацію.
Підтримка кейсів
Тест-кейси потрібно оновлювати та прибирати їх, якщо вони неактуальні, та, звісно, додавати нові. Гарна практика — проводити сесії з перевірки кейсів. Одна сесія проходитиме у форматі написання нових тест-кейсів, в якій команда буде передивлятись створені кейси та додавати ідеї та зауваження. Інша сесія може проходити раз на пів року, і під час неї ви можете передивлятись кейси та формувати список того, що потрібно оновити або взагалі перенести в архів.
Ще попросіть автоматизаторів якщо вони бачать не актуальні тест кейси нехай пишуть вам або додають до вашого файлу, таблиці, тощо. У нас на проєкті автоматизатори періодично знаходили неактуальні кейси, які ми згодом переписували. Зробіть культуру підтримки та оновлення кейсів в команді. (P.S. раджу не видаляти кейси, а зробити архів, адже вони колись можуть стати в пригоді).
Створіть список, таблицю або занесіть задачі в систему, щоб бачити, що саме зроблено, що залишилось та який наразі є прогрес.
Якщо у вас є задача, де ви переробляєте якийсь функціонал, — тримайте в голові, що вам, скоріше за все, потрібно буде оновити та додати нові кейси до вже наявних.
Замість висновку
Якщо ви знайшли баг, то одразу за цими кроками створіть тест-кейс та додайте його у ваші списки.
Не забувайте про тест-кейси від початку до кінця (End2End).
- Вони стануть у пригоді, коли вам потрібно перевірити білд і чи придатний він для початку тестування.
- Вони допомагають на демонстрації функціональності.
- Разом з ними можна автоматизувати продукт та основні функції. А це може скоротити витрати часу на автоматизацію.
- А якщо їх автоматизувати та запускати перед мануальним тестуванням, то це ще й скорочує час мануального тестування для перевірки білда.
Приклад з мого досвіду: у нас був великий проєкт, і мануал тестувальників було набагато більше, ніж автоматизаторів. У якийсь момент автоматизатори не встигали покривати всі написані нами кейси, тож вони накопичувались. Коли щось дуже накопичується, мало кому це подобається, тільки якщо це не гроші (я про роботу або задачі).
На одному з дзвінків я запропонував написати E2E-кейси для автоматизації, вирішили спробувати цю ідею. Я написав кейси на декілька модулів, показав менеджменту та команді автоматизаторів — цей підхід усім сподобався. Потім ми залучили більше тестувальників і всі основні модулі описали E2E-кейсами. Коли їх покрили автотестами, ми додали їх як quality gate для перевірки білда й отримали автоматизовану перевірку та економію часу.
Дякую, що дочитали до кінця! Та, будь ласка, пам’ятайте, що не існує ідеального рішення для всіх проєктів, кожен з них унікальний, зі своїми процесами та критеріями, тож обирайте, що підходить вам, адже лише ви можете впливати на проєкт та покращувати його, а також процеси, документацію.
Як і навіщо писати кейси
Ви, напевно, чули, що кейси — це потужний інструмент у маркетингу, яким компанія демонструє свої послуги й досвід. Але попри іншомовне походження терміна, на англомовних сайтах рідко зустрінеш розділ cases чи порад щодо цього жанру. У цій колонці я як контентниця рекламного агентства поясню цей феномен, а також розберу, що таке кейс, які вони бувають і як їх писати. У статті буду посилатися на власний досвід та матеріали, в написанні яких брала участь. Сподіваюсь, цей текст буде корисним, читайте його, якщо хочете написати кейс про досвід вашої компанії.
Що таке кейс
Кейс — це жанр комерційного контенту, в якому автор описує певний проєкт або робочу ситуацію. Кейс — це не завжди текст, можна знімати відео з оповідачем чи без нього, можна робити інфографіку для Instagram, записувати відоси на TikTok або присвячувати окремий лендинг одному кейсу, щоб він був максимально інтерактивний і красивий. Усі ці твори ми будемо вважати кейсами, якщо в них є певні жанрові особливості, а саме:
Є результат, який здобуває виконавець і який, вочевидь, подобається клієнту, бо той дозволяє про це все розповісти широкому загалу.
Якщо ці пункти сходяться, то ми отримуємо кейс, в якій би ніші не були.
Наприклад, постачальник бензину може розповісти на своєму сайті, як у нього новий бренд заправок замовив 100500 цистерн, і, попри логістичні труднощі, бензин доставили. Це буде кейс. Якщо ту саму історію про доставлення нафтопродуктів буде описувати замовник, то це радше буде відгук. А якщо за опис візьмуться журналісти (з власної ініціативи, а не для “нативної” реклами), то це ймовірно буде жанр розслідування.
Кейси в англомовному інтернеті
Приєднуйся до Speka у телеграм
Якщо ви експортуєте послуги і розгортаєте контент-маркетинг англійською, ви могли помітити, що в іноземних компаній зазвичай відсутній розділ “Кейси” на сайті. Колеги з США, Сполученого Королівства та інших англомовних країн розповідають про клієнтів, описують success story або розбирають певний project, але не використовують «case» у тому значенні, до якого звикли ми. Зважайте на це, коли перекладаєте власні матеріали англійською.
На деяких ресурсах (наприклад, у Галереї партнерів Google Marketing Platform ) можна зустріти поняття Case Study, що походить від однойменного наукового методу, коли науковець досліджує (study) якийсь випадок (case). Формулювання Case Study коректно застосовувати, коли ви даєте максимально детальний розбір процесів, які використовували. Якщо ж ваш кейс лаконічний “ми запустили рекламу і вона привела до N лідів”, краще використовувати поняття “story”, щоб матеріал виглядав більш органічно для носія мови.
Навіщо компанії писати кейси
Це питання зазвичай ставлять технічні спеціалісти, чию роботу ви хочете описати. Мій досвід показує, що часто спеціалісти перебувають у такій собі пастці знання — те, що для них “та тут роботи на пів годинки, немає що описувати”, виявляється застосуванням передової технології, до якої ще не кожному нададуть доступ. Тому я сформувала для себе детальну відповідь, навіщо писати кейс, і поділюсь із вами аргументами, кому та навіщо потрібні кейси.
Компанії для залучення нових клієнтів. Потенційні клієнти побачать, які круті проєкти ми робимо, і собі захочуть такі ж класні результати. Тому треба описувати все, що зробили круто.
Поточним клієнтам для покращення їхніх кампаній. Описавши, як круто ми зробили роботу для одного клієнта, ми можемо йти до всіх інших і пропонувати їм зробити те саме. При цьому нові підходи й технології описуються не на пальцях, а на конкретних скриншотах та діаграмах.
Авторам для особистого бренду. Ми в агентстві вказуємо автором кейса людину, яка його описала: робила доповідь на внутрішній івент або безпосередньо працювала із контентником над текстом. Надалі автор може будь-де у своїй біографії вказувати “автор галузевих статей”, і це буде щирою правдою. Якщо ви не вказуєте авторство статей на сайті компанії або підписуєте їх колективним “ми, компанія”, це може негативно впливати на індексацію.
Загалом для ринку ваших послуг. Коли ваші конкуренти бачать, що у вас є класні результати, вони намагаються повторити їх. Якщо їм це вдається, ринок, на якому ви працюєте зростати, стає більш престижним, і це добре для всіх компаній на ньому. Якщо ж конкуренти не можуть повторити ваш успіх, вони можуть звернутися до вас за консультацією і зрештою таки навчитися, після чого галузь буде далі рости.
Для підрядників. Наскільки б довгим і повним не був цикл виробництва, на певних етапах кожна компанія має субпідрядників або постачальників, яким не зайве буде публічно подякувати за їхню роботу. Навіть якщо йдеться про неспівставні за масштабом компанії, коли маленький стартап хвалить величезний концерн за класне обладнання, це може стати приводом познайомитись та отримати додаткові бонуси у майбутньому.
Також часто кейси пишуть для залучення трафіку, отримання беклінків, покращення DR сайту і подібних суто контентних показників. Я не буду знецінювати їхню важливість, адже для багатьох колег-контентників такі показники є KPI, але, будемо відверті, вони вторинні. Якщо кейс читають клієнти, конкуренти та друзі автора у соцмережах, то він отримає своє місце на графіках у ГА і Search Console.
Отже, створення маркетингових кейсів, це win-win-win-win ситуація з усіх боків. Тому розберемось, як їх робити.
Які бувають кейси
Не здивуюсь, що цьому питанню присвятили кілька курсових робіт на факультетах піару, але я навмисно їх не шукала, щоб не плутатись самій і не заплутати читача. Надалі авторська класифікація того, що роблю сама і бачу на ринку в роботах колег.
Кейс-результат. “Підняли конверсії на 3000%”, “Привели + 100500 замовлень за місяць”. Такі кейси описують стандартну для ринку послугу, яка мала незвично добрий ефект. Наприклад, коли йдеться про таргетовану рекламу в Instagram, кожен малий бізнес та кожен блогер-початківець знають, що це таке і як працює, тому виконавцю достатньо сказати “подивіться, який крутий проєкт я зробив”, а розписування секрету успіху може видати конкурентну перевагу.
Кейс-процес. Зазвичай у будь-якому кейсі описується робочий процес, але в цьому виді він головний герой. Наприклад, коли ми знижуємо CPA у гарячий сезон завдяки спеціалізованим інструментами Google або коли описуємо процес роботи із резервом на Youtube і збираємо для клієнта гарантовані покази за сталою ціною, поки його конкуренти б’ються на аукціоні за показ у «чорну п’ятницю».
Кейс-експеримент. Цей вид кейсів подібний до попереднього, адже тут також фокус зміщується з результату на процес, але йдеться про тестування нових гіпотез і технологій або перевірка сталих переконань. Наприклад, ринок упевнений, що Firebase — нормальна система, як для безплатної згодиться. Ми перевіряємо це твердження і бачимо, що Firebase начисто ігнорує айфони, коли інша система їх трекає. Дослідження у кейсі може бути завданням від клієнта або необхідністю, із якою ми стикнулись під час роботи, тож тут ми описуємо гіпотезу, як її перевіряли і яких висновків дійшли.
Антикейс. Це своєрідна сповідь про те, як виконавець запоров роботу, але проаналізував помилки, зробив висновки і ділиться цим болісним досвідом та висновками. Такого виду кейсів поки немає в нашому арсеналі, тож наведу цей приклад: автор будує припущення, як уникнути помилок майбутньому. Такі історії мають на меті підкупити своєю чесністю, плюс аргументи підважуються кількістю втрачених грошей, але я сподіваюсь, що у кожного, хто це читає, ще не скоро буде нагода писати щось подібне.
Ми у newage зазвичай використовуємо процесні кейси та експерименти, адже працюємо із advanced-інструментами Google, які потребують додаткових описів і пояснень.
Як написати кейс
Структура кейсів може відрізнятися залежно від ніші, особливостей роботи, платформи, на якій буде розміщений матеріал, і безлічі інших чинників. Але, якщо відкинути всі додаткові варіації, є мінімальний набір складових, які мають бути в кейсі. Вважайте список нижче за ялинку, яку на новий рік кожен може прикрасити й розмістити на свій смак, але без самої ялинки це не працюватиме.
Про клієнта. Назва, ніша, в якій працює компанія, за бажання — регалії з офіційного сайту клієнта, які продемонструють рівень компаній, із якими ви працюєте.
Завдання або мета. Опишіть, що хотів ваш клієнт. Новий сайт, налаштування CRM, становлення top of mind у своїй ніші — поясніть, яку саме роботу ви мали зробити та за якими критеріями визначали успішність проєкту.
Робота. Це основна частина кейсу, де виконавець демонструє свій професіоналізм та компетентність. Поясніть, що саме ви робили, якими інструментами та навіщо.
Результати. Обов’язкова частина, в якій ви показуєте, що всі попередньо описані дії до чогось призвели. Результат зазвичай подають у об’єктивно вимірюваних числах, які відповідають завданню клієнта. Наприклад, якщо клієнт хотів сайт якнайшвидше, то результат варто виміряти у днях від замовлення до здавання проєкту; а якщо хотів медійну рекламу для збільшення пізнаваності — наведіть як результат дані із Brand Lift.
Відгук. Публікувати інформацію про клієнта без його згоди — у кращому разі поганий тон, а в гіршому може призвести до позовів за поширення конфіденційної інформації. Тому обов’язково покажіть кейс перед публікацією клієнту і попросіть написати кілька теплих слів про вашу співпрацю.
Може здатись, що це надто уніфікований підхід і що не можуть всі кейси виглядати так однаково, але повторюся — це супербазова структура, до якої кожен може додати будь-що на власний розсуд. Можна окремо зупинитися на інструментах чи детально показати процес підготовки до роботи; можна додати висновки із кожного пункту або описати нюанси роботи вашого бекофісу, якщо вони допомогли здійснити проєкт.
Будь-який кейс — це історія, а історії циклічні й подібні крізь віки. Тисячі років тому боротьба з левом була героїчним епосом, нині вона може стати кейсом на сайті веткліники, але структура і суть історії буде однаковою.
Захисні каски
Захисні каски — найбільш розповсюджені засоби захисту працівників від травмування голови. Дізнайтеся, в яких нормативних документах встановлено вимоги до захисних касок, на що слід звертати увагу під час придбання цих ЗІЗ та як потрібно перевіряти придатність касок до експлуатації.
Коли потрібні захисні каски
Для забезпечення безпеки та захисту здоров’я працівників роботодавець зобов’язаний забезпечити за свій рахунок придбання, комплектування, видачу та утримання засобів індивідуального захисту. Для захисту голови використовуються захисні каски або шоломи.
Працівники повинні використовувати захисні каски для запобігання та мінімізації наслідків дії на голову таких небезпечних і шкідливих виробничих факторів, як електрострум, вода або агресивні речовини, тепловий удар, механічні чинники тощо. Каски мають відповідати вимогам держстандартів та нормативно-технічної документації на конкретний вид касок.
Найбільш поширеними є каски загального і спеціального призначення: для газовиків, будівельників, шахтарів, лісорубів, окремих інших видів робіт, де існує можливість ураження голови.
Орієнтовний перелік робіт, на яких необхідно застосовувати ЗІЗ, визначає вимог безпеки і охорони здоров’я при використанні працівниками засобів індивідуального захисту на робочому місці, затверджений наказом Мінсоцполітики від 29 листопада 2018 року № 1804. Це, зокрема:
- будівельні роботи, роботи з реконструкції або знесення будівель, роботи поблизу риштовання та на підвісних робочих місцях, монтаж і демонтаж опалубки, роботи з переміщення вантажів, складання конструкцій та встановлення устаткування;
- роботи на металоконструкціях мостів, будівель та гідротехнічних споруд; роботи на щоглах, вежах, у доменних печах, на металургійних заводах і прокатних станах, трубопроводах великого діаметру, у котельнях, на електростанціях та у великих ємностях;
- роботи в ямах, траншеях, шурфах, колодязях, шахтах, тунелях;
- земельні та гірничі роботи;
- підземні гірничі роботи, роботи в кар’єрах, відкриті видобувні роботи, збагачення вугілля;
- роботи з гайковертами, іншим механізованим інструментом для скріплення;
- вибухові роботи;
- роботи поблизу ліфтів, підйомних механізмів, кранів і конвеєрів та ін.
Типи та класи захисних касок
Захисні каски складаються з корпусу, внутрішньої оснастки і підборідного ременя. Каски також можуть оснащуватись пристроями для кріплення на них респіратора, протишумових навушників, щитка і окулярів для захисту очей та обличчя. У зимовий період використовується каска захисна з підшоломником.
Для вибору правильного типу або класу захисних касок необхідно оцінити також можливість додаткових небезпек. Наприклад, каска захисна будівельна має забезпечити захист від бічних ударів, а та, що призначена для електромонтажних робіт, — відповідний рівень ізолювання.
Вимоги до захисних касок
Нормативні вимоги щодо експлуатації захисних касок встановлені в таких нормативних документах:
- ДСТУ EN 397:2017 «Каски захисні промислові»
- Правила експлуатації електрозахисних засобів, затверджені наказом Мінпраці та соцполітики України від 5.06.2001 № 253;
- Правила охорони праці під час виконання робіт на висоті, затверджені наказом Держгірпромнагляду від 27.03.2007 № 62, та ін.
При придбанні захисних касок повинна бути супроводжувальна документація:
Також мають бути відповідне маркування та повна комплектація згідно з документами.
Захисні каски повинні мати впресоване або влите маркування на корпусі (внутрішньому оснащенні) та інформаційні дані, що визначені у технічних умовах виробника та державних стандартах:
- назва або ідентифікаційна позначка виробника;
- рік, квартал (місяць) випуску;
- розмір або діапазон розмірів;
- номер стандарту (наприклад, EN 397);
- тип каски (як правило, на касках закордонного виробництва).
Нормативними документами не передбачено нанесення на захисні каски інвентарних номерів.
Як перевірити придатність до експлуатації захисних касок
Захисні каски не піддають періодичним експлуатаційним випробуванням, але їх придатність перевіряють перед кожним застосуванням шляхом візуального огляду.
Візуальний огляд захисних касок проводять з метою виявлення дефектів, а також для контролю їх стану протягом усього строку експлуатації відповідно до вимог документів з експлуатації, встановлених виробником.
Придатна до використання каска має суцільний корпус з козирком або полями і внутрішнє оснащення (амортизатор і несучу стрічку). Внутрішнє оснащення і підборідний пасок — з’ємні, мають пристрій для кріплення до корпусу каски. Підборідний пасок регулюється по довжині, а спосіб його кріплення забезпечує можливість його швидкого роз’єднання. Конструкція каски дозволяє максимальне регулювання внутрішнього оснащення всередині корпусу каски та не перешкоджає носінню інших 313, наприклад, захисних окулярів.
Засоби індивідуального захисту мають бути сумісними між собою. Можливість поєднання ЗІЗ має бути підтверджена їх випробуваннями під час збирання або дозволом на використання комбінації. На практиці можна поєднувати ЗІЗ одного виробника — у такому разі їхні захисні властивості при спільному використанні не погіршаться.
Не допускається застосовувати пошкоджені каски захисні, що мають тріщини і вм’ятини на корпусі, порушення цілісності внутрішнього оснащення. Каски з пошкодженнями заміняють на нові, оскільки вони не підлягають ремонту.
За необхідності протягом експлуатації захисних касок можна проводити їхнє санітарне оброблення, зануривши у 3-5%-вий розчин хлораміну або 3%-вий розчин хлорного вапна на 30-60 хвилин, а потім промити у холодній воді та висушити природним способом.