what is sdet know difference between tester
Aquest tutorial tracta tots els aspectes d'un SDET (enginyer de desenvolupament de programari en proves), inclosos els coneixements tècnics, els rols i les responsabilitats, el salari i la trajectòria professional:
Discutirem en profunditat el paper de SDET, les expectatives i responsabilitats d’aquest paper que esperen les empreses, el conjunt d’habilitats que ha de posseir un SDET, eines i tecnologies que el candidat hauria de tenir en mà i també els salaris en general. ofert.
Què aprendreu:
Comprensió del paper SDET
La forma ampliada de SDET és - Enginyer de desenvolupament de programari en proves
En paraules molt senzilles, aquest rol és una combinació d’un intermedi entre un rol de desenvolupador pur i un de provador pur. Els SDET són professionals qualificats tant en enginyeria de qualitat com en desenvolupament de programari.
El terme SDET va ser inventat per primera vegada per Microsoft, que va ser seguit i utilitzat per la majoria de noms de productes grans com Google, Amazon, Adobe, Expedia, etc. Les principals expectatives dels rols eren substituir les tasques manuals repetitives amb certa automatització per augmentar l’eficiència i fiabilitat per a les aplicacions sotmeses a prova.
Comparació entre SDET i control de qualitat manual
Els provadors manuals de control de qualitat se centren principalment en la prova de caixa negra o d'aplicacions. El que vol dir, per a un provador de control de qualitat, és important especificar com es comporta una aplicació quan se li dóna una determinada entrada.
quin és el millor convertidor de vídeo
El provador de QA només hauria d’utilitzar l’aplicació / el sistema que s’està provant com ho faria qualsevol usuari / client normal, però centrant-se en els detalls més detallats, així com en els escenaris de vora, provant diferents combinacions d’entrada, etc.
Els SDET es centren tant en les aplicacions de White Box com en les proves de Black Box. Dit d’una altra manera, també serien conscients del funcionament intern de l’aplicació, que els permet escriure proves d’automatització utilitzant tècniques de proves White Box o Black Box.
En essència, un enginyer de desenvolupament de programari en proves ha de ser conscient de totes les tècniques de proves de Black Box juntament amb el coneixement pràctic de desenvolupament / codificació per entendre el funcionament intern de l’aplicació, que garanteix millors estàndards de qualitat i un producte de programari menys defectuós.
Bàsicament, un SDET hauria d’actuar com a facilitador d’una QA eficaç per qualsevol mitjà. Això també significa que l'individu utilitzarà les seves habilitats per garantir que totes les parts del programari sotmès a prova es validin de la millor manera possible, que hauria d'incloure proves tant d'àrees funcionals com no funcionals.
Vegem la comparació SDET i el verificador manual de diferents paràmetres
Paràmetre | SDET | Tester manual |
---|---|---|
Abast de la prova | Se centra en una gran varietat de tècniques i tipus de proves. Exemple: Funcional, no funcional, seguretat, rendiment, etc. | En general, centreu-vos en la perspectiva de la funcionalitat de l'aplicació que es prova. Un provador manual es comporta com un usuari / client de l’aplicació que s’està provant i el valida des d’aquesta perspectiva. |
Automatització | Els SDET se centren principalment en automatitzar escenaris repetitius per garantir que els verificadors manuals es puguin centrar en escenaris més complexos i de vora i utilitzar el seu ample de banda i habilitats de manera més eficient. | Els verificadors manuals posseeixen algunes o cap habilitat per a l'automatització. Tot i això, cal que els provadors manuals siguin conscients de l’ús d’eines que ajudin a les proves manuals Exemple: Ús de Postman per a l’execució de punts finals de l’API, ús de proveïdors de núvols, com ara laboratoris de salsa, per a l’execució de proves en diferents versions de la plataforma, etc. |
Conjunt d’habilitats primari | Els SDET són els principals responsables d’automatitzar casos de proves, així com d’escriure scripts / eines reutilitzables que ajudin l’equip a reduir els esforços repetitius. Un membre sènior de l’equip SDET també és responsable de crear frameworks d’automatització i permetre a altres SDETs escriure proves mitjançant el framework. | Els verificadors manuals se centren principalment en la funcionalitat de les aplicacions, se centren en escenaris de casos majúsculs i casos de prova complexos. Per exemple: Un provador manual que provi una aplicació mòbil, a més de tots els escenaris funcionals, pensaria en escenaris com ara - Què passa si tanco l’aplicació quan hi ha una operació de backend / trucada de xarxa en curs. - Què passa si el mòbil s'apaga de sobte quan el client es trobava en una pàgina concreta de l'aplicació. - Què passa si Internet s'apaga enmig de penjar un document en una aplicació, etc. |
Salaris | En general, als SDET se’ls ofereix salaris més alts (un 40-50% més elevats que els verificadors manuals), a causa de les habilitats que posseeixen i l’experiència que tenen. | Les funcions de proves manuals pures tenen un salari inferior en comparació amb una funció híbrida en què un provador manual també s’esforça per aprendre noves eines i afegir valor al producte que s’entrega. |
Enginyer de desenvolupament de programari en Test Skillset
A continuació es detallen els conjunts d’habilitats que ha de posseir un SDET:
# 1) mentalitat oberta
El primer i principal conjunt d’habilitats és que qualsevol enginyer de desenvolupament de programari en proves hauria d’estar obert a l’aprenentatge de qualsevol llenguatge de script / eines que siguin necessaris per permetre’ls fer proves exhaustives de l’aplicació sotmesa a prova.
És molt probable que, com a SDET en una empresa, pugueu acabar treballant amb la pila de tecnologia Microsoft / .NET, però en una altra empresa, el llenguatge de desenvolupament és principalment Java, de manera que s’espera que SDET tingui una mentalitat oberta per aprendre coses noves / tecnologia com i quan sigui necessari.
# 2) Adaptatiu
Un enginyer de desenvolupament de programari en proves s’ha d’adaptar a les necessitats del projecte, eines i tecnologies, bases de dades, etc. Per exemple - Com a SDET és possible que tingueu experiència en fer proves d'API, però un altre paper requereix que proveu la interfície d'usuari o la interfície. Per tant, el paper requereix que us adapteu a les necessitats del projecte per oferir un producte estàndard d’alta qualitat.
# 3) Multitarea
A la majoria de les empreses de productes, sovint la relació DEV i QA es desvia en gran mesura. Això vol dir que és habitual veure equips amb una relació DEV: QA de 4: 1 o fins i tot de 5: 1. Per tant, és imprescindible que s’espera que un SDET estigui involucrat en diverses coses i que s’entregui.
Aquestes són algunes de les responsabilitats en què es preveu que treballi un SDET:
- Participar en les reunions dels grups d'interès: un SDET ha de relacionar-se estretament amb els desenvolupadors i amb la gent del producte per entendre el producte tant dels desenvolupadors com del punt de vista del producte i, a continuació, idear / suggerir una estratègia d'automatització.
- Crear marc / eines
- Estratègia de la planificació de proves
- Elevar / investigar defectes
- De vegades es pot exigir que contribueixi a les proves d’unitats juntament amb els desenvolupadors.
# 4) mentalitat exploratòria
Cada SDET hauria de recordar aquestes línies en tot moment - ' Si repetiu les mateixes accions tot el temps, penseu en automatitzar-les '
La persona tindria una mentalitat per reduir l’esforç de qualsevol cosa que li arribés amb l’ajut d’eines per millorar la productivitat i per garantir productes de programari d’alta qualitat.
A més de tota la feina d’automatització, la tasca principal de SDET és oferir productes d’alta qualitat amb tot el que calgui, per tant, també hauria de centrar-se en provar productes a través de formes exploratòries per descobrir cada cop més errors i defectes ocults.
# 5) Col·labora, contribueix i comunica't
El paper de SDET obliga a establir contactes entre diferents grups d'interès com ara desenvolupadors, productes, verificadors manuals, etc.
És important que els SDET col·laborin amb tots els grups d'interès necessaris i que comuniquin tots els detalls necessaris quan i quan sigui apropiat.
Els equips SDET i QA mantenen les portes de qualitat d’un producte abans que siguin obertes al públic i, per tant, juguen un paper important pel que fa a la consideració d’un producte apte per ser llançat als clients o no.
Rols i responsabilitats
Intentem, doncs, entendre què són les tasques i responsabilitats diàries dels SDET i les diferents tasques que s’espera que facin.
- Col·laboreu al costat de desenvolupadors i de les parts interessades del negoci i procureu automatitzar els criteris d’acceptació. Això significa, en paraules simples, que: un SDET primer entén els requisits des de la perspectiva d’acceptació / client i també ha d’entendre la manera com es desenvolupa el producte en termes de llenguatge de codificació, bases de dades, etc., i després planifica una estratègia per automatitzar els escenaris màxims possibles. .
- Responsable de la creació de solucions d'automatització de proves robustes i d'alta qualitat per a proves funcionals, de regressió i de rendiment.
- Creeu scripts / eines reutilitzables sempre que sigui necessari.
- Contribuir a les àrees de prova tant funcionals com no funcionals. Les proves funcionals inclouen proves des de la perspectiva de la funcionalitat / dels requisits i es basen en gran mesura en criteris d’acceptació o històries dels usuaris.
Tanmateix, també són importants les proves no funcionals. Per exemple, la rendibilitat de l’aplicació, l’aplicació és prou segura, assegureu-vos que no quedi cap pirata informàtic a l’aplicació que pugui dificultar la seguretat de l’aplicació i pot acabar causant una gran pèrdua tant als clients com a l’organització. - També participen en les discussions de disseny i disseny arquitectònic, a més de proporcionar comentaris efectius en les ressenyes de codis.
Converteix-te en un gran SDET
Per convertir-vos en un SDET excel·lent, vegem alguns consells / eines bàsiques i habilitats tècniques que s’han d’aprendre per millorar els seus papers.
A la secció anterior, vam conèixer les qualitats que ha de posseir un enginyer de desenvolupament de programari en proves per esdevenir excel·lent en els seus papers. Han de tenir una mentalitat oberta, ser adaptatius i han de ser capaços de comunicar-se, col·laborar-hi i contribuir de la manera que ho exigeixi el producte o l’equip.
Vegem una llista d'algunes eines i tecnologies habituals que han d'aprendre els SDET:
- Hauria de tenir una comprensió sòlida dels principis, tipus de proves i metodologies de proves.
- Molt competent en problemes de depuració: apreneu eines de depuració com: Depurador web de Chrome que són extremadament útils per a la depuració d'aplicacions web, així com per investigar els registres de xarxa d'una aplicació en proves.
- Haurien de poder escriure codis / seqüències d’ordres reutilitzables i, per tant, haurien de dominar almenys un llenguatge de seqüències d’ordres. El més fàcil d’aprendre és Python, que es podria aplicar a una gran varietat de tasques, marcs d’automatització, etc.
- Conegueu les proves de l'API a clients com POSTMAN
- Hauria de ser conscient de les eines i tècniques de prova de la caixa blanca, com ara els marcs burlats ( Mockito ), etc, ja que es podria esperar que contribueixin a escriure proves unitàries també quan sigui necessari.
- Haurien de ser conscients d'eines de versions com Vaja . A més, haurien de conèixer els conceptes de Extracte de sol·licituds , ressenyes de codis, etc.
- Comprensió de l'arquitectura d'aplicacions web i del model general client-servidor.
- Hauria de ser conscient dels conceptes bàsics de programació orientada a objectes i comprendre’n S SOLLID model ( S responsabilitat ingle, O bolígraf / Principi tancat, L iskov Substitució, Jo Segregació de la interfície, D inversió ependencial)
- Comprensió bàsica de Integració contínua / Lliurament continu conceptes (CI / CD) i també haurien de ser conscients de les eines de CI com Jenkins / Bamboo, etc.
Generalment, s’espera que els SDET s’encarreguin dels problemes de desplegament, de manera que és imprescindible entendre aquestes eines. - Haurien de familiaritzar-se amb almenys un marc d’automatització frontal. El més fàcil i el més utilitzat a Seleni . És el Sant Grial de les proves front-end per a aplicacions web i gairebé totes les organitzacions utilitzen el marc Selenium per automatitzar les proves d’interfície d’usuari.
- Aprendre els conceptes bàsics de les proves de rendiment i escriure scripts senzills mitjançant eines de prova de rendiment de codi obert com JMeter és molt útil i podeu consultar-ho Tutorial Jmeter . Això és útil, ja que també s’espera que els SDET s’encarreguin de requisits no funcionals, com ara proves de rendiment.
- També haurien de ser conscients dels conceptes fonamentals de les proves de seguretat. Això també inclou tenir coneixement dels estàndards bàsics de codificació, cosa que garanteix que no quedi cap defecte bàsic de seguretat sense tractar a l'aplicació. OWASP és una gran referència per a tots aquests conceptes fonamentals.
- S'espera que els SDET coneguin, comprenguin i implementin metodologies de desenvolupament àgil i haurien de ser còmodes treballant amb equips mitjançant la metodologia Sprint / Scrum d'àgil.
- Hauria de ser conscient de qualsevol plataforma de tecnologia al núvol com: Amazon AWS , Google GCP , o Microsoft Azure .
Com que ara la majoria de les empreses es mouen a una infraestructura basada en el núvol, és bàsic tenir una comprensió bàsica de les eines i les tecnologies del núvol.
Certificació per a SDET
En general, no hi ha certificacions específiques disponibles per als SDET
Si algú vol iniciar el seu enginyer de desenvolupament de programari en el viatge de proves, només pot centrar-se en els punts que s'esmenten a la secció 'Com convertir-se en un gran SDET' d'aquest tutorial i, a continuació, els SDET amb mentalitat oberta haurien de continuar el seu viatge d'aprenentatge en el treball.
Per provar la terminologia i els conceptes bàsics, és bo que tothom que estigui en la professió de proves de programari tingui la certificació de Certificat de proves de la Fundació ISTQB .
Aquesta certificació cobreix tots els conceptes bàsics de proves de programari com:
- Tipus de proves: funcionals / no funcionals
- Prova de caixa negra / caixa blanca / caixa grisa
- Planificació de proves / Gestió de defectes
- Tècniques de prova: particionament d'equivalència, matriu de traçabilitat, etc.
També hi ha altres certificacions internacionals de proves de programari disponibles, però la majoria no són criteris de selecció molt importants perquè les empreses contractin SDET.
Hi ha disponible una llista de totes aquestes certificacions aquí.
com configurar la xarxa de seleni
Entrevistes
Amb la majoria de les empreses de productes més grans, l’enginyer de desenvolupament de programari a l’entrevista de prova és molt més comparat amb les entrevistes a desenvolupadors, ja que s’espera que coneguin la major part del desenvolupament de metodologies i conceptes relacionats.
Tot i això, les entrevistes són una mica indulgents en comparació amb els desenvolupadors. El que es posa èmfasi aquí és com el candidat aborda un problema i quina amplitud pot tenir una persona sobre el problema.
En general, les entrevistes SDET consisteixen en seguir rondes / tipus de preguntes en gairebé totes les grans organitzacions de productes com: Amazon, Microsoft, Adobe, Expedia, etc.
- Ronda escrita: Redacció de casos de prova per a un determinat producte. Aquí, la intenció és fer-se una idea de com pot pensar la persona sobre el candidat totes les facetes de les proves si pensa / llista tots els escenaris funcionals, els casos de cas, si el candidat se centra en proves de seguretat, proves de rendiment, etc.
- Ronda de codificació: Es fa un petit exercici de codificació i també s’espera que el candidat escrigui tots els escenaris de proves unitàries i de proves funcionals. Aquí es tracta de l’àrea o habilitat que s’està provant: coneixements / construccions bàsiques de codificació, escriptura de codi comprovable i coneixements sobre tècniques de proves de caixes blanques com la prova d’unitats, la burla, etc.
- Ronda de disseny: Es llança una pregunta sobre el disseny del sistema, exemple , com dissenyaries youtube
Aquest tipus de preguntes solen tenir més rellevància per als desenvolupadors, però per als SDET, l’entrevistador busca quina amplitud pot pensar la persona, sap el candidat sobre els conceptes de POO, és el candidat capaç de pensar en l’escalabilitat, la robustesa, l’equilibri de càrrega, etc. , pot el candidat utilitzar bases de dades adequades per a l'aplicació que s'ha de dissenyar - Ronda de RRHH / gerent: Aquí s’observen coses com la condició física de l’equip, la cultura, etc. sobre el candidat, així com les discussions sobre salaris i també es fan negociacions.
Lectura recomanada => Preguntes d'entrevista SDET
Salari SDET
Com hem comentat a les nostres seccions anteriors, els SDET obtenen salaris més alts que la majoria de funcions de proves manuals. En molts casos, els salaris són comparables als de desenvolupadors amb un nivell d’experiència similar.
Podeu referir-vos aquí per conèixer la gamma de salaris en diferents perfils SDET en diferents organitzacions. En general, el salari SDET difereix per banda d’experiència i per organització.
A continuació es mostra una comparació dels salaris de SDET per a empreses destacades com Microsoft, Expedia.
Nivell | Microsoft ($) | Expedia ($) |
---|---|---|
SDET - Jo | 65.000-80.000 | 60.000-70.000 |
SDET - II | 75.000-11.000 | 70000-100,000 |
Sr SDET | 100.000-150.000 | 90000-130,000 |
Trajectoria de la carrera
En general, l’escala de carrera SDET comença i creix de la següent manera:
- SDET-1 - SDET de nivell junior capaç d'escriure scripts d'automatització.
- SDET-2 - SDET experimentat capaç d'escriure eines reutilitzables i marcs d'automatització.
- Sr SDET - SDET de nivell superior capaç de ser un col·laborador individual com SDET 1 i SDET 2, però també és capaç de fer-ho
- Realització de ressenyes de codis.
- Participa en discussions de disseny i fes suggeriments per tenir els canvis adequats en el disseny.
- Participa en l'estratègia global de proves del producte.
- Participar en models de lliurament de CI / CD, crear canonades d’execució, etc.
- Gestor SDET - Després de SDET2, podeu triar Sr SDET o SDET Manager Path. Un gerent de SDET té responsabilitats de gestió / lideratge, a més del treball bàsic de SDET.
- Arquitecte de proves / enginyer de solucions - Arquitecte de proves o enginyer de solucions és algú que principalment dissenya / arquitectura un marc general per a diversos projectes, que emmarca les especificacions de les proves, que també pot actuar com a gestor de lliurament. Aquestes persones són persones que van a la recerca i ajuden a diversos projectes a aconseguir els seus resultats de proves i envien un producte molt ben provat i lliure de defectes.
A continuació, es mostra una representació a nivell de bloc del camí professional SDET:
Conclusió
En aquest tutorial, hem après en profunditat sobre què és un SDET en termes de rols i responsabilitats, habilitats imprescindibles, quina diferència hi ha entre SDET i verificadors manuals i què es necessita per convertir-se en un gran enginyer de desenvolupament de programari en proves.
En general, SDET és un paper molt demandat i gairebé totes les empreses de bon producte tenen aquest paper als seus equips i són molt valorades.
Lectura recomanada
- Preguntes i respostes de l'entrevista SDET (guia completa)
- 10 MILLORS empreses i serveis de desenvolupament de programari personalitzat el 2021
- 20 MILLORS eines de desenvolupament de programari (rànquings 2021)
- Mesures per SSDLC (cicle de vida segur de desenvolupament de programari)
- Fases, metodologies, processos i models de SDLC (cicle de vida de desenvolupament de programari)
- Desenvolupament de programari i metodologies de proves (amb avantatges i inconvenients)
- 5 coses que un desenvolupador principiant (i un provador) hauria de saber sobre les proves de programari
- 5 maneres de ser un provador de programari audaç i segur