Ola a todos! Chámome Yulia e son probadora. O ano pasado faleille bagodelnya - un evento celebrado na nosa empresa para limpar o atraso de erros. Trátase dunha opción totalmente viable para reducilo significativamente (do 10 ao 50% en diferentes equipos) nun só día.

Hoxe quero falarvos do noso formato de primavera Bagodelny - BUgHunting (BUH). Esta vez non corriximos erros antigos, senón que buscamos outros novos e propuxemos ideas para funcións. Debaixo do corte hai moitos detalles sobre a organización deste tipo de eventos, os nosos resultados e os comentarios dos participantes.

Unha vez pensado e anotado a normativa, enviamos unha invitación a todas as canles de Slack corporativo, que non contiña ningunha restrición:

Como resultado, rexistráronse preto de 30 persoas, tanto desenvolvedores como especialistas non técnicos. Dedicamos toda unha xornada de traballo ao evento, reservamos unha gran sala de reunións e organizamos xantares no comedor da oficina.

Por que?

Parece que cada equipo proba a súa funcionalidade. Os usuarios nos informan de erros. Por que se fai un evento así?

Tiñamos varios goles.

Presenta aos rapaces máis preto de proxectos/produtos relacionados.
Agora na nosa empresa todos traballan en equipos separados - unidades. Estes son equipos de proxectos que están a traballar pola súa propia parte da funcionalidade e non sempre son plenamente conscientes do que está a suceder noutros proxectos.
Só tes que presentar aos teus compañeiros.
Temos case 800 empregados na nosa oficina de Moscova; non todos os compañeiros se coñecen de vista.
Mellora a capacidade dos desenvolvedores para atopar erros nos seus produtos.
Agora estamos promovendo Agile Testing e adestrando rapaces nesta dirección.
Implica algo máis que especialistas técnicos nas probas.
Ademais do departamento técnico, temos moitos compañeiros doutras especialidades que querían falar máis de probas, de como informar correctamente dun erro para que recibamos menos mensaxes como “Ahhh... nada funciona”.
E, por suposto, atopar erros complicados e pouco obvios.
Quería axudar aos equipos a probar novas funcións e darlles a oportunidade de mirar a funcionalidade implementada desde un ángulo diferente.

Implantación

A nosa xornada estivo formada por varios bloques:

briefing;
unha pequena charla sobre as probas, na que só tocamos os puntos principais (obxectivos e principios da proba, etc.);
sección sobre "regras de boas maneiras" ao introducir erros (aquí os principios están ben descritos);
catro sesións de probas para proxectos con escenarios descritos de alto nivel; antes de cada sesión houbo unha pequena charla introdutoria sobre o proxecto e división en equipos;
pequena enquisa sobre o evento;
resumindo.

(Tampouco nos esquecemos dos descansos entre sesións e xantar).

Regras fundamentais

A inscrición para os eventos é individual, que soluciona o problema de que todo o equipo se esgota por inercia se unha persoa decide non ir.
Os participantes cambian de equipo cada sesión. Isto permite que os participantes poidan ir e vir en calquera momento, e tamén podes coñecer máis xente.
Comandos dúas persoas antes de cada sesión fórmanse aleatoriamente, isto faino máis dinámico e rápido.
Os erros introducidos son premiados puntos (de 3 a 10) dependendo da criticidade.
Non se conceden puntos por duplicados.
Os erros deben ser arquivados por un membro do equipo segundo todos os estándares internos.
As solicitudes de funcións créanse nunha tarefa separada e participan nunha nominación separada.
O equipo de auditoría supervisa o cumprimento de todas as normas.

Outros detalles

Inicialmente, quería facer un evento de proba "avanzada", pero... Moitos rapaces de equipos que non son de produtos rexistráronse (SMM, avogados, PR), tivemos que simplificar moito o contido e eliminar casos complexos/perfil.
Debido ao traballo das unidades en Jira en diferentes proxectos, segundo o noso fluxo, creamos especialmente un proxecto separado no que configuramos un modelo para introducir erros.
Para calcular puntos, planearon utilizar unha táboa de clasificación que se actualizase mediante webhooks, pero algo saíu mal e ao final o cálculo tivo que facerse manualmente.

Todo o mundo ten problemas á hora de organizar eventos e, para facelo un pouco máis fácil, describirei os nosos problemas que pode evitar.

Un dos falantes de súpeto caeu enfermo e tivo que buscar un novo.
Tiven a gran sorte de atopar un substituto do mesmo equipo ás 9 da mañá). Pero é mellor non confiar na sorte e ter un recambio. Ou estea preparado para dar vostede mesmo o informe necesario.

Non tivemos tempo para lanzar a funcionalidade, tivemos que intercambiar os bloques.
Para evitar tirar un bloque enteiro, é mellor ter un plan de copia de seguridade.

Algúns usuarios de proba caeron, tivemos que volver crear rapidamente outros novos.
Comprobe os usuarios de proba con antelación ou pode facelo rapidamente.

Case ningún dos rapaces para os que se simplificou o formato chegou.
Non hai que arrastrar a ninguén pola forza. Humíllate.
Hai unha opción para prescribir estrictamente o formato do evento: "afeccionado"/"avanzado", ou preparar dúas opcións á vez e decidir cal celebrar despois do feito.

Puntos organizativos útiles:

reservar unha reunión con antelación;
organiza as mesas, non te esquezas dos cables de extensión e dos protectores contra sobretensiones (cargar portátiles/teléfonos pode non ser suficiente para todo o día);
automatizar o proceso de puntuación;
preparar táboas de clasificación;
facer folletos en papel con inicios de sesión e contrasinais dos usuarios de proba, instrucións para traballar con Jira, scripts;
Non esquezas enviar recordatorios unha semana antes do evento, e tamén indica o que tes que levar contigo (portátiles/dispositivos);
cóntalles aos teus compañeiros o evento nunha demostración, nos xantares, tomando un café;
acordar cos devops non actualizar nin lanzar nada neste día;
preparar altofalantes;
negociar cos propietarios de funcións e escribir máis escenarios para probar;
pedir golosinas (galletas/doces) para lanches;
non esquezades falarnos dos resultados do evento.

Descubrimentos

Durante todo o día, os rapaces conseguiron probar 4 proxectos e crear 192 erros (134 deles únicos) e 7 problemas con solicitudes de funcións. Por suposto, os propietarios do proxecto xa coñecían algúns destes erros. Pero tamén houbo achados inesperados.

Todos os participantes recibiron doces premios.

E os gañadores son termos, chapas, sudaderas.

O que resultou interesante:

os participantes atoparon inesperado o formato de sesións duras, cando o tempo é limitado e non se pode dedicar moito tempo a pensar;
conseguiu probar o escritorio, a versión móbil e as aplicacións;
miramos moitos proxectos á vez, non había tempo para aburrirnos;
coñeceron a diferentes colegas, analizaron os seus enfoques para introducir erros;
sentiu toda a dor dos probadores.

Que se pode mellorar:

facer menos proxectos e aumentar o tempo de sesión a 1,5 horas;
preparar agasallos/souvenirs con moita antelación (ás veces a aprobación/pago leva un mes);
relaxarse e aceptar que algo non sairá segundo o previsto e haberá forza maior.

avaliacións

Anna Bystrikova, administradora do sistema: “A esmola é moi educativa para min. Aprendín o proceso de proba e sentín toda a "dor" dos probadores.
Nun primeiro momento, durante o proceso de proba, como usuario exemplar, comproba os puntos principais: se fai clic no botón, se vai á páxina, se o deseño se moveu. Pero máis tarde dáse conta de que cómpre pensar máis fóra da caixa e tentar "romper" a aplicación. Os probadores teñen un traballo difícil; non abonda con "picar" por toda a interface; cómpre tentar pensar fóra da caixa e estar moi atento.
As impresións só foron positivas, aínda agora, un tempo despois do evento, vexo como se está a traballar nos erros que atopei. É xenial sentirse implicado na mellora do produto ^_^".

Dmitry Seleznev, desenvolvedor front-end: "A proba en modo competitivo motívanos moito a atopar máis erros). Paréceme que todos deberían tentar participar en Baghunting. As probas exploratorias permítenche atopar aqueles casos que non están descritos no plan de proba. Ademais, as persoas que non coñecen o proxecto poden dar comentarios sobre a comodidade do servizo".

Antonina Tatchuk, editora senior: “Gustabame probarme como probador. Este é un estilo de traballo completamente diferente. Estás intentando romper o sistema, non facerte amigo del. Sempre tivemos a oportunidade de preguntarlles aos nosos compañeiros algo sobre as probas. Aprendín máis sobre a priorización de erros (por exemplo, estou afeito a buscar erros gramaticais nos textos, pero o “peso” de tal erro é moi pequeno; e viceversa, algo que non me pareceu moi importante acabou sendo un erro crítico, que foi solucionado inmediatamente).
No acto, os mozos fixeron un resumo da teoría das probas. Isto foi útil para persoas non técnicas. E uns días despois deume pensar que estaba a escribir en apoio doutro sitio usando a fórmula "que-onde-cando" e describindo en detalle as miñas expectativas do sitio e da realidade".

Conclusión

Se queres diversificar a vida do teu equipo, bótalle unha ollada á funcionalidade, organiza un mini "Come a túa propia comida para cans", entón podes tentar realizar un evento deste tipo e despois poderemos discutilo xuntos.

Todo o mellor e menos erros!

Fonte: www.habr.com

Bagelny: BUgHunting. Como atopar 200 erros nun día