This document describes Masaki Nakagawa's role as a Software Engineer in Test (SWET) at DeNA. It provides details about his background, responsibilities in developing test frameworks and automated tests, and approach to testing. As a SWET, he writes test code, builds test environments, and automates testing to improve developer productivity. He advocates for testing activities to be integrated with development and uses techniques like gray box testing to balance automated testing with readable, writable and maintainable test code.

1. Software Engineer in Test
at DeNA
Masaki Nakagawa / @ikasam_a
DeNA Co., Ltd.

2. http://dena.com/topics/2013/07/
swettechtalk33.php

4. About Me
• @ikasam_a
• github.com/masaki
• metacpan.org/author/MASAKI

5. at DeNA
• JOIN (2011/10)
• Founder of QA Team (2012/01)
• (...developed tests...)

6. Currently Status
• SWET (Software Engineer in Test)
• TE (Test Engineer)

7. What is SWET?
• a developer role for testing
• write test framework
• build test environments
• write tests

8. http://en.wikipedia.org/wiki/SET

9. http://googletesting.blogspot.jp/2011/02/how-google-
tests-software-part-two.html

10. Several Names
• SWET @DeNA
• SET (Software Engineer in Test) @Google
• SDET (Software Development Engineer in Test)
@Microsoft
• QAE (Quality Assurance Engineer) @Amazon.com

11. Developer Productivity
• to improve productivity
• Base Technology Team
• Development Infrastructure Team
• “Dandelion” a.k.a.“Tanpopo”
• as SWET
• productivity of testing
• productivity using test technology

12. at DeNA
• JOIN (2011/10)
• Founder of QA Team (2012/01)
• (...developed tests...)

13. Previous Works
• as a Developer
• Web API (Ruby)
• Web Application (Ruby)
• Windows Application (VC++)
• Embedded Application/Library (C++)
• as a Developer Productivity
• Automation of build and test
• CI/CD

14. Write Codes w/ Unit Test
in all Products

15. Ruby
• RSpec,Webrat(!), Selenium, Cucumber
• Cucumber is overkill...
• make Webrat’s custom node matchers
• many monkey patches

16. C++/VC++
• Google Test, Google Mock
• very difficult to search freamworks
• aggregate test cases automatically
• easy setup and teardown
• flexible mocks
• monkey patching
• sexyhook
• can stubbing Win32API

17. Do Everything
where Automation is not enough

18. Automation
• JavaScript
• PhantomJS
• QUnit + qunit-tap.js (for Jenkins)
• @t_wada++
• Java
• Maven2 + local repo
• replace to JMockit from djUnit

19. QA Process
• wrote many-many automated tests
• Unit Test and Integration Test
• against conventional process
• automation v.s. manual testing
• discontinuity w/ QA dept.

20. Testing Activities
SHOULD
be in Developments

21. I met “SET”
• Google Testing Blog
• http://googletesting.blogspot.com
• How Google Tests Software
• http://googletesting.blogspot.jp/2011/01/how-google-tests-software.html

22. QA Team at DeNA
• did not like THE name :D
• was worried misleading
• would like to do SWET

23. QA Team
Mission Statement
• For platform engineers
• To develop new features
• Should keep the quality of platform system

24. About QA Team
• To verify the Platform System
• To write AUTOMATION tests
• To improve Platform System quality
is NOT a tester, is a TEST ENGINEER

25. Mobage Open Platform
(Outline)
API Server Gadget Server
mobage Developers (WebApp)
Internal Tools / Databases / Middlewares
Developer
Game Server / Game Client (User)
API ServerAPI Server Gadget ServerGadget Server

26. Target & Level
• tests “Interfaced” components
• API, Gadget, mobage Developers, ...
• lack of integration level tests
• end-to-end

27. Browser Game Testing
• Browser Game for Test
• Smartphone Emulated Browser
• E2E Test Codes
API Server
Gadget Server
Smartphone
(Emulation)
Platform

28. API Testing
• Mobage API HTTP Client for Test
• Gray-Boxed Fixture Library
• E2E Test Codes
API Server
Test Scripts
(in Platform)
Platform

29. WebApp Testing
• App-Specialized Browser
• E2E Test Codes
mobage DevelopersPC Browser
Platform

30. Techniques
• Gray Box Testing
• mixed Black Box and White Box
• Black Box-ed test cases
• White Box-ed test fixtures
• Multi-environmental tests
• multi-region
• multi-environment

31. Policy
• Test Engineering
• as an engineer (developer)
• Gray Box
• clean codes
• Readable
• Writable
• Maintainable

32. as an Engineer
• for Gray Box
• requires Skills
• understands the Product (including code)
• behaves an product engineer, if necessary

33. Code Quality
• Readable
• What do you testing ?
• Writable / Maintanable
• How do you add or modify ?

34. Conclusions
• Developing E2E Tests over the past year
• acts as SWET
• reduce distance between Test & Dev
• SWET is hard and crazy, but FUN!
• if interesting, please talk to me!

35. Any Questions?