Training Preparation -- Current Practices of 100 Attendees

How do you test your code? What is your target system? What development tools do you use? What is your code review practice? How much time does it take to do an incremental build, load, and start running your code so you can start to test it? What percentage of your development time is spent coding? What percentage of your development time is spent testing? What percentage of your development time is spent debugging?
Integration and Functional/System Tests. stm32F429 with motors, pumps, and various peripherals. Keil MDK Segger JLink VS Code We are developing software development workflows which are now including Code Reviews with associated Git Pull Requests. 1-5 minutes 4 2 4 Show
Personal projects: largely TDD Professional projects: a bit of TDD Current: Multi Arduinos used on a NASA project for photovoltaic R&D, to improve power output for the Lunar Gateway project. Simulated sun system for testing PV's on earth, plus balloons to 120,000 ft to calibrate things in space. Eclipse, Arduino IDE, Rare. Usually when there are questions. Or at end of completion of a new feature area. 11-30 seconds 30 30 40 Show
unit test, integration test Embedded Visual Code Thorough code reviews 1-5 minutes 50 35 15 Show
Our testing is done manually. Manually writing test cases for functions and modules. Arm Cortex-M4, mainly STM32F4s Keil uVision MDK, Parasoft C/C++ Test Reviews are done during pull requests of our git-based repository. 30-60 minutes 30 40 30 Show
C production code is tested using CUnit. We chose this library because it was very easy to compile with our custom toolchain and does not require an OS. C++ production code is tested with CxxTest. We chose this library because the python script that auto generates the test harness is easy to configure for use without an OS. All unit tests are run on the target system. This allows us to unit test things like GPIO assertions and interrupt handlers. SoC with a custom MIPS processor. Custom C and C++ compiler and toolchain (gcc patch). CMake for defining the build rules, which generate Makefiles we use for building. CUnit for C unit testing. CxxTest for C++ unit testing. Emacs Usually involve 4-6 reviewers, each reviewer spends 2 weeks annotating the code. We use a custom tool that allows reviewers to collaborate and make in-line annotations without modifying the code. 1-5 minutes 50% 40% 10% Show
unity test harness running on simulator, manual with debugger Microchip dsPIC33, ST stm32f4, multiprocessor safety-critical system MPLAB X, Keil uVision, Visual Studio Code, batch files Not optimal 11-30 seconds 33 33 33 Show
Testing the end product directly, with a human. Various avionics systems, some of which are ARM microcontrollers, and some which are x86 embedded linux systems. VSCode, Various IDEs for different microcontrollers, svn, git Using crucible currently, but not very experienced with it 5-30 minutes 50 20 30 Show
I generate a test plan independent of the SW project based on user requirements/use-cases and then manually create a test document to run the SW through the tests x86/ARM Visual Studio, Eclipse, Android Studio In my prior position as a Sales Engineer I lacked access to really experienced mentors for code reviews. I'm hoping to get a lot of feedback from code reviews in my new role in Engineering. 1-5 minutes 60% 30% 10% Show
Test using the product and multiple different inputs to see if I get the desired result. Zebra mobile printers running on c/c++ QNX Momentics I call another developer that is an SME in that area and show them my changes. They ask me to change something or give their approval then and there. 1-5 minutes 20 40 40 Show
The most important are functional developer tests. Automated testing is carried out in development with cmocka. Our system test writes much more extensive automated tests, mostly in Python. Our target systems are 2G / 3G / 4G radio modules. Qualcomm Build Environment, Qualcomm tools like QPST, QXDM and many more. Are done together with colleagues. 5-30 minutes 25% 25% 25% Show
In most cases: pepper with Debugs, run & check, remove debugs Embedded multicore systems editor, compiler, debugger In most cases I am involved in advance and know the changes. 5-30 minutes 50 25 25 Show
1) compiler as static code analyzer 2) cpp check as static code analyzer 3) source code review 4) manual tests 5) cmocka on a daily base via jenkins 6) system test cases on a daily base via jenkins Embedded system with multiple cores, typically based on ARM 32/64 bit. Source Insight Beyond Compare CPP Check Very useful. The skill is to invite people which are able to give useful feedback. 5-30 minutes 20 60 20 Show
Jenkins CI Debugger Logging Embedded ARM Some Gitlab 5-30 minutes ? ? ? Show
Testsuites provided by OS manufacturer (Windows kernel drivers), self written test suites (Android and Linux drivers), manually (everything). X86 systems with Windows or Linux, Android systems. No embedded systems! Many, depends on the kind and target of my current task. ? 1-5 minutes 50 25 25 Show
cmocka (job), by using it (private) in general: embedded platforms in detail: embedded C or Linux based linux and google I try to take them serious. if I can't read it like a book or simply do not understand something, I complain. Under 10 seconds 3 3 1 Show
directly in client - server scenarios - - - 5-30 minutes 50% 30% 20% Show
I typically add unit and integration tests when I am working on something that could have runtime errors that could result from my code, like parsers, algorithms, etc. In Rust I often avoid writing tests by using the type system to make certain error cases impossible. I typically develop on Ubuntu, but I recently got a Mac with Apple Silicon, and I also use Windows. Basically, everything. I typically use VS Code + Rust Analyzer + Cargo. We often develop in a mob, allowing for live code review. 11-30 seconds 80 15 5 Show
Using some flavor of test driven development. No specific system in mind, usually application-specific. Primarily VS Code and everything that comes with it. Currently depends on the project, but generally pretty high-level. 1-5 minutes 60 20 20 Show
gtest unit tests Cortex M4 dual controller system with BLE my collegues can answer this better than i could. my collegues can answer this better than i could. 31-60 seconds 20 20 20 Show
gtest unit tests Cortex M4 dual controller system with BLE my collegues can answer this better than i could. my collegues can answer this better than i could. 31-60 seconds 20 20 20 Show
For newly created software units, unit tests are applied during development ( first the logic is implemented, then tested). For legacy code, tests are done by looking at the integration level. Low power Microcontroller 32-bits. Eclipse, IAR , Visual studio, azdo, EA. It depends on the project. Done via Pull request 1-5 minutes 20 50 30 Show
unit-tests, integration-tests medical embedded devices VS-Code, Docker, gcc (cross compiler), gdb debugger, git, microsoft azure for change management and continuous integration one reviewer, using pull-request workflow 11-30 seconds 50 30 20 Show
Currently, either Cucumber or just running the code against CI when I push to Git. Small evaluation board from ST fitted with a custom display Visual Studio Code STM32CubeIDE We do mob programming, so we don't *usually* do code reviews as everyone is generally in the loop. Sometimes when we have to do solo work, though, we'll pull 1-2 people in to ensure the code is sane. 31-60 seconds 15 15 70 Show
ideally most of my day -- above 80% -- spent in the happy place of the red-green-refactor micro loop. 3 months into job here, about 5% in that place, 95% in what Geepaw calls GAK activity, others, yak shaving. bare metal rust some kind of STM processor (new to this space I am) rust; c++ for the legacy bits; applying strangler pattern to eliminate that, in hopes of 100% rust 0% C++ we mob - reiews are real time; asynchronous review (I'm looking at you, Git PR) are for those sad souls who default to solo. Under 10 seconds 10 45 45 Show
unit tests, integration tests, regression tests ARM Cortex M VSCode/Vim, GDB, STLink, Rust/C++ done by Mob/Pair Programming 1-5 minutes 3 4 3 Show
Using google-test. Write code, then test. Target is 100% coverage, for application logic down to device drivers. Embedded ARM device CLion VS-Code docker clang, iar, git gitlab we do a code-review per pull-request. review is done by second person, a pull-request holds code from 3-5 days of work. 31-60 seconds 40 30 30 Show
As a DevOps engineer I mostly write scripts, and then by executing the script, I would see, wether the script works as expected or not. (In my side projects I use gtest and the Visual Studio native unit test framework, and the debugger) n/a GitHub, Docker, Azure Done through pair coding and at the pull requests 1-2 hours 50 30 20 Show
Combination of class-level unit tests, automated integration tests and system tests, plus manual exploratory manual testing. Arduino, embedded linux, embedded Windows, desktop exercises. Mix: Macbook, Eclipse, AtmelStudio, Aduino IDE, TextMate, Visual Studio varies by project, from zero to by weekly to pairing 31-60 seconds 10 40 50 Show
VS code 4-8 hours 8 5 7 Show
Writing unit tests for existing code Uses java script and python VS Code They go through peer review processes 5-30 minutes 33 33 33 Show
Test in development environment, code review, test on target platform, then whole system integration testing. Laptop running Windows 10 Visual Studio, git, VMWare Peers review code individually and provide feedback prior to an online meeting where we review the code, what its supposed to do, and what it actually does Under 10 seconds 60 20 20 Show
We are using Google Test / Google Moack for Unit testing and we have own frameworks for end to end testing. TDD is encouraged but not implemented correctly in the company. STM32 The team can provide information We use the four eyes principles and all code is checked before being committed. We have recently moved to using Git Pull requests for all activities (last week ) 5-30 minutes 40 30 20 Show
- Manually on the target according test reports New development of a laser system for eye surgery - responsible for the FW in distributed system (Win10 (GUI); Linux (System controller); 7 x FW w/o OS). Subsystems with FW connected as slaves over USB to the System controller - STM32CubeIDE - Enterprise Architect (UML/SysML) Only if searching a bug or if listed as a step in test report. No formal procedure defined. 11-30 seconds 70 10 20 Show
As a DevOps engineer I mostly write scripts, and then by executing the script, I would see, wether the script works as expected or not. (In my side projects I use gtest and the Visual Studio native unit test framework, and the debugger) n/a GitHub, Docker, Azure Done through pair coding and at the pull requests 1-2 hours 50 30 20 Show
PyTest, UnitTest, other test API, and trial and error I am currently developing test software using a Windows 10 Lenovo x64 machine, but plan to create tests to be deployed and triggered on Raspberry Pi 4's for actual CDCI. Visual Studio Code IDE, Thonny IDE (for Pi Pico or lightweight Pi 4 work), GitHub Actions I do not have code reviews as a Verification Technician. 1-5 minutes 40 40 20 Show
yes embedded platforms Tornado 2.2 peer 31-60 seconds 33 33 33 Show
By unit tests using Google Test Insulin Pump System with two MCU's (stm32l476xx & stm32wbxx) - Visual Studio Code - SEGGER J-Link - Azure DevOps The code reviews are done by a reviewer using the pull request feature of Azure DevOps. 1-5 minutes 30 50 20 Show
On unit-test level we are using CppUTest. We are using a 3 cpu system Eclipse VisualStudioCode Code reviews are done in Pull Requests of Azure Dev Ops by a technical leader. As a basis there are review report templates bound to our internal processes. 11-30 seconds 30 20 50 Show
We are at the moment in the setup phase of our project. We plan to use Google Test for Unit tests. And we want to have automated integration tests by using Robot Framework. In my past projects testing was mainly done directly after implementation, but for my feeling mainly rudimental tests. There was a seperate System Test deparment. Embedded platform for ethernet fieldbuses. The plan is to use C++ where possible. Static Code Analysis Azure DevOps Currently in setup phase of the project and no fixed process is implemented so far. 31-60 seconds 40 20 40 Show
Unit tests are executed during the build. Higher-level tests are still largely manual and/or ad-hoc. I'm seeking to improve this at the organizational level. Military vehicles, ranging from microcontrollers to desktop-level machines. Eclipse. We need better participation. Authors need to do a better job making it easier for others to participate. We also fundamentally need to reduce the need for them by adopting better, more modern practices that include a lot more testing. 11-30 seconds 60 20 20 Show
Depends on the project. In the project I am now: program the device, hope it works. The testing team will do the unit tests later. Medical device containing two microcontroller (one main, one supervisor) and bluetooth connectivity. It injects drug. VS Code / Eclipse, Parasoft, C, Azure Dev Ops, conan package manager Done in Pull Request in Azure Dev Ops. Sometimes thorough, sometimes not. 5-30 minutes 4 3 3 Show
pytest or unittest embedded instruments, proprietary serial bus interface, gui is touchscreen, outputs are relay contacts, 4-20mA analog signals Rust software, C++ embedded, python system integration test automation team reviews 5-30 minutes 4 1 2 Show
I test it manually and we have a test team Congatec QSeven imx6 running Linux VS 2019 for C# Code review is done mostly if there is a big change. 5-30 minutes 50 25 25 Show
I test the code manually before I pass it on to the test engineers. A YOCTO linux systems that communicates with nodes that contain STM32 microcontrollers. Visual Studio Qt Creator STM32CUBE IDE Texas Instruments CCS Matlab We work with GitLab. When we want to commit larger changes, we normally create a merge request and ask a colleague to review the changes in GitLab. 11-30 seconds 40 30 30 Show
Unit Tests, UI and integration tests are done manually Windows, Linux, Mobile Devives Visual Studio I dont have time for code reviews nowadays, they were done when I started programming Under 10 seconds 70 10 20 Show
fully from user standpoint Blackfin BF537 DSP VisualDSP++, Visual Studio 2019 rarely review 1-5 minutes 2 2 5 Show
Currently NUnit and Ceedling (CUnit). Write failing test, write code behind the test, make the test pass, commit, refactor a bit where necessary. (I could use more discipline on the refactoring bit). It's kind of a typical pre-web embedded system comprised of a microcontroller for data acquisition (embedded C) communicating to a single board computer running a Windows C# application via a CAN bus. For the embedded bit, use Atmel studio (now MPLAB X), but found that CLion is a more navigable IDE (refactoring tools inclusive). For the C# side it's Visual Studio with the Resharper plugin (for unit testing and refactoring/autocomplete tools). We don't currently do any code reviews. At best in Valley Forge, it is one developer per product/product line. Would like to start - emphasis on readability/testability over style. 31-60 seconds 15 30 55 Show
Manually functional with unit or simulation Windows PC and embedded windows PC Visual studio By my self 31-60 seconds 60 15 25 Show
unittests, software in the loop for Signalprocessing Devices: Digiphone, ESG, Ferrolux Software written in C on a Blackfin from Analog Devices Visual DSP, Cppcheck, Jenkins, Matlab using ccpcheck to find defects 1-5 minutes 40 40 20 Show
unittests, software in the loop for Signalprocessing Devices: Digiphone, ESG, Ferrolux Software written in C on a Blackfin from Analog Devices Visual DSP, Cppcheck, Jenkins, Matlab using ccpcheck to find defects 1-5 minutes 40 40 20 Show
Manually check the functionality. Self-developed PCB board, controlled by an FPGA. Intel Quartus II, Visual Studio I'll give the code to a colleague to test. 31-60 seconds 20 40 40 Show
A combination of automated unit tests and manual testing on hardware. Historically, this has skewed mainly towards the latter, but in the last couple of years I have begun to test as much as possible via unit tests. As a project team, we are looking to perform more automated testing on hardware. This is not something I have been involved with personally yet, but am looking forward to learning about it. We typically develop hand held products used for electrical test. These products often involve multiple processors, and need to be designed with safety in mind. Hstorically, IAR tools, but we're moving to GCC and other open source tools that play better integration with CI tools. We develop primarily on Windows, although there is some Linux/WSL work (particularly with CI). We also use Matlab/Simulink. We try to review all code that is integrated with the develop branch. There is no formal process for how. Sometimes it is done via screen share, sometimes via Bitbucket pull request. Reviewees nominate a reviewer familiar with the subject. Under 10 seconds 70 20 10 Show
None STM32 and Atmel range of microcontrollers Atmel studio, System Workbench (STM32) None 11-30 seconds 10 20 20 Show
I currently mostly test simulink models (from which c++ code is being generated) via matlab scripts: framework inheriting from matlab.unittest. The system is a electrical measuring instrument which has two microcontrollers: STM32F7(GUI) and STM32L4R5 (measurement) matlab/simulink, visual code, gcc (wsl on windows 10), stmcube ide Our code review are either informal (just one reviewer without any records of any requested changes when the original work is relatively small) or done using pull request on bitbucket when the work is more substential. 1-5 minutes 33 33 33 Show
Have started testing with google-test on new code. Code that is being reused is currently hard to start testing.. Embedded arm microcontrollers, controlling all kinds of hardware, sensors, motors ++ VSCode STM32CubeMX CMake, Ninja, arm-gcc, openocd Policy to use 1+ reviewers depending on what has changed. Code needs to be approved (most cases) before it can be merged. 11-30 seconds 50 30 20 Show
Unittest with the Google test framework STM32 microcontroller VSCode, MinGW, CMake, Ninja Performed by code owner after merge request is sent. 31-60 seconds 25 25 50 Show
SonarCube + black/grey box module testing and functional test STM32 MCU Visual Studio Code / GCC Passed SonarCube screen, code is reviewed in meet with designated colleague with functionality and readability in scope. 31-60 seconds 33 33 33 Show
Manually Embedded System VS code Peer review then senior programmer review 11-30 seconds 20 30 50 Show
Manual testing. I try to make my outputs very clear, so I am able to follow the execution. I use debugging tools to step through the code. Visual Studio Code, Pycharm, Git I need to clean my functions. I need to optimize my code as I work with it, do not leave it to the end. 5-30 minutes 40 20 40 Show
Debugger, test by using devices Atmel 8 bit mcu, PC, stm32 VS Code We use GitLab MR 1-5 minutes 20 20 20 Show
I only did a little embedded here so far, there was no unit-testing, no regression tests, no gated checkin, no stubbing, mocking.. TDD.. forgive me for I know how I have sinned. Oof. I only did a bit of embedded. ATmega128, we don't really care about 'performance' that much, so careful thought into tailored code is often not an issue. Energy efficiency is not an issue, stack-size might be. I wish I could use e.g. valgrind.. GCC debug.. I like IDE's like CLion, but we often resort to Atmel studio and are bound to Windows ¯\_(ツ)_/¯ Visual Studio is still my favorite though. We check the style, but the code reviews usually happen 'after' a rather big chunk of work is done. We could be more agile, do not employ scrum. Code reviews are more of a feedback/suggestion oftentimes. 30-60 minutes 20 10 70 Show
Mostly with manual testing AVR, ARM, x86, x64 Git, Visual Studio, clang-format, qt creator (PuTTY, RealTerm, HxD) When I review others, I usually focus on execution speed/avoiding bloated code. I also enjoy code that looks tidy, and testable, if possible. 11-30 seconds 40 20 40 Show
Building, uploading and running it, and then create a situation where changes in the code will show. Sometimes I need to provoke the system or even introduce another bug to see how the system reacts. Then, if the change seems to work, test the change in multiple different situations/over a period of time Robot firmware mainly Git, Jira, Microchip studio, VS Code We review git merges, or when someone is unsure about something 1-5 minutes 60 20 20 Show
On bench setup or in real application. Autostore cube storage, automated logistics solution STM Cube IDE 11-30 seconds 50 10 40 Show
Tested manually. Bare metal embedded plattform. Clang, Git, GitLab Multiple reviewers are approving the code changes before merging into the master branch. 1-5 minutes 40 20 40 Show
With the goal of uncovering issues and bugs as early as possible. Basically i'm doing manual unit testing. Manually manipulating input to modules/functions by any means in order to test all edge cases that I can think of. In addition to this I would also do targeted/specialized integration testing before merging any code. Robot firmware running on STM32-controllers. Requiring high degree of robustness and stability while also keeping focus on functional details. Aspects related to performance and durability of the robots are important as well. Git. Jira/Confluence. SonarQube. A bunch of internal tools. Partly good. 5-30 minutes 10% 70% 20% Show
cargo test STM32Fx ( and some NXP ) gcc , VS code, git, rust All merges should be independantly reviewd and pass CI Under 10 seconds 7 2 1 Show
Some unit testing, a lot of manual testing STM32 microcontroller VS studio Code Merge request before a branch is merged to master. Reviewers will look through the code and accept/decline. Build server makes sure the branch builds, but does not run any tests. 11-30 seconds 20 50 30 Show
Simulation via Simulink - Requirements tests, integration tests, baseline/equivalence tests. And on target hardware / system. Embedded control system. Compiler Debugger Code Editor Version Control (Git) Simulator (Simulink) Often slow. But thorough. Under 10 seconds Don't know Don't know Don't know Show
Testing directly on the target hardware. No unit tests as such. Embedded system based on STM32 MCUs for controlling robots for storage system. Eclipse Visual Studio Code GCC Code review are done upon merge requests by another software developer (lead) 1-5 minutes 60 20 20 Show
System tests, automatic jig tests and local happy testing. B1 robot is a multi CPU system with real-time requirements and a fair bit of dynamics (motor control). gcc, VS Code, pytest (for integration testing), Confluence for doc, Jira, git, Gitlab. Clang-format checks on commits (new). SonarQube for analysis We have MR (Gitlab merge request) that needs to be approved before they are allowed into the master branch. We have some preliminary checklists of what to check and are currently requiring 1 approver and preferably also a second reviewer. 5-30 minutes 2 2 6 Show
GTest Not sure, I'm a new engineer at this company. VSCode, mingw, gdb/make/ninja, arm toolchain. Not sure, I'm a new engineer at this company. 1-5 minutes 40% 40% 20% Show
Gtest, GMock Bare metal Arm Cortex-Mx MCU's VS Code, Eclipse Before any merge request there is always min. 2 colleagues which go through the code for style and compatibility. 11-30 seconds 50 10 40 Show
By running it on the target. With debugger, print statements or normal operation depending on how much has changed. Embedded systems, STM32 Git, Gitlab, Jira, Eclipse, Visual Studio Code One or more relevant persons will look through the changes and confirm it does what it is supposed to and adheres to the defined coding guidelines. The author is responsible for testing the code and making any requested changes. 11-30 seconds unknown unknown unknown Show
Bench testing (have a std set of instructions and debuggers) + we have dedicated team to do unit testing Linux Different IDEs We use code collaborator to do code reviews. Usually 2-3 reviewers+ moderator are present 31-60 seconds 4/10 4/10 6/10 Show
Depends on the feature/issue I'm working on. For feature, I use T32/lauterbach to add breakpoints and verify the states of the variables. For issues I re-run the failing tests and recommend adding additional tests to increase coverage. ARM R8 based embedded system. Bare metal programming. lauterbach, ARM toolchain n/a 1-5 minutes 4 3 3 Show
Running on actual HW that has attached debugger Pre-commit tools Simulator Enterprise SSD Visual Studio GCC / GDB ARM cross compiler / assembler T32 debugging Peer review with review system 5-30 minutes 20 30 50 Show
Run test cases SSD Lauterbach T32 emulator Our code need be reviewed by at least one member from each of 3 groups. 31-60 seconds 4 3 3 Show
bench test, some regression test cycles ARM based SOC lauterbach t32 UART Firmware traces code collaborator, standard review process with 2 peer and 1 moderator 1-5 minutes 2 2 6 Show
Targeted testing / injection on real devices and in simulation environments, plus automated sanity test suites Proprietary SSD devices ARMCLANG, SlickEdit, Git, Visual Studio, make Some automated coding standard checking, but loosely enforced. Emphasis on correctness and functionality over style. Quality and scope varies depending on factors unrelated to the code (schedule, reviewers, etc.) 1-5 minutes 80 10 10 Show
Regression testing various: SystemC model Python models/parsers NVMe SSD device FW VS Code, GDB varies: For model development, optional Bitbucket centric reviews. For FW, code collaborator required. 11-30 seconds 40 20 40 Show
bench tests, debugger manipulation, integration tests Many CPUs, lots of hardware acceleration. VSCode, Trace32, home made. use of review bots is handy. can take a long time to get a review completed. 1-5 minutes 40 40 20 Show
Bench test and putting breakpoint in the code I used Linux and windows both as target systems Source Insight for C++ development I make sure to file a bug if I see an incorrect implementation 1-5 minutes 30 40 30 Show
using host applications developed by third parties or internal test teams Linux, windows based systems connected to SSDs ARM DS5, VS studio, Source Insight I look at code structure first then logic 4-8 hours 30 30 40 Show
different team does the testing. no unit testing Samsung ASIC ARM, Bash, batch reviews consist of syntax and logic verification. 1-5 minutes 60 10 30 Show
Test applications using the APIs of my code. Mostly embedded devices based on a ARM solution, with Linux or ThreadX. The toolchain for our targets based on the supplier delivery (SCons, bitbake, gnu compiler chain for the build system. Lint and CppCheck for static code analysis. We mostly use GitLab. On older projects based on ClearCase, we use a ms-word review-template. 5-30 minutes 40 40 20 Show
build, and afterwards by flashing the module, Wireless module, with a lwm2m client, connects to a web server and helps with provisioning of an embedded SIM. source insight, vim/gvim. +Qualcomm tools to debug. normally done in gitlab 5-30 minutes 2 3 5 Show
As unit test with bash scripts, with intention for automatisation in CI (jenkins). If not possible only manually. Especially for audio topics to recognize if audio path really enabled we have few sensor options to realize woking software. Embedded system with mostly ARM processor, main software delivered by processor producer, do we advancing the system and make it compatible in the customer environment. Source Insight, Notepad++, propiritary tool of the the processer producer (Qualcomm, Mediatek), git (last years), before clear case as version management Reviews in git lab: Check for syntax problems or obviously better to handle functions. To get deeper in the right 5-30 minutes 6 2 2 Show
As I am mostly bugfix others code or just enhance vendor code, tests are usually very specific. Often this is done by individual agreements (case-per-case) with system test department. several SoC's form Qualcomm, MTK, ... plain text editor + vendor specific env. project specific. Currently: most changes are to be reviewd by at least one another developer using gitlab. 1-5 minutes 30 10 60 Show
Jenkins CI server 64 bit ARM/Cortex processor for 5G products GIT,Jenkins The code review is automatically initiated by pushing the code changes to the server. Sometimes it is challenging to understand the functionality when the review contains a lot of code. 5-30 minutes 7 2 1 Show
Ci, Jenkins Several Base band Processor systems gcc, make, cmake Gitlab tools 5-30 minutes 60 20 20 Show
Jenkins, CTS Android Compiler, Source Insght, Lauterbach debugger Organized with Jira tooling 5-30 minutes 20 60 20 Show
manually Mobile Phone SOCs several GitLab based merge requests documented in Jira 30-60 minutes 33 33 33 Show
unit tests, on target tests various vendors using different OS, e.g. Siemens, TTPCom, Qualcom, MediaTek, Intel gcc,g++,vendor compilers, ... make, cmake, scons, ... gdb, Lauterbach, language debuggers vim, emacs, SourceInsight, Eclipese, ... gprof, gcov ClearCase, git, mercurial Jenkins, Gitlab, Jira, Confluence, ClearQuest ... using Gitlab merge requests 1-5 minutes 50% 30% 20% Show
I write every line of code imaginable, as fast as I can, and use a binary search to find the bugs sdf asdf asdf 11-30 seconds 45 45 10 Show
unit or bench test by developer and then test cases by test group Linux Debian or VxWorks workbench performed with each release 30-60 minutes 0 0 0 Show
internal group cellular tracker devices with various sensors for perishable and healthcare market na internal Under 10 seconds 0 0 0 Show
Testing by running on target - testing function and unhappy paths. Linux on arm, VxWorks on X86 Eclipse, Workbench/Tornado We do them, from an internal check list enumerating items to check. 1-5 minutes 35 50 15 Show
I build my own testing classes/blocks/methods/functions to unit test my code vs expected results. Windows, PLCs/Controllers For my current job I use ISaGRAF, VS Code, Visual Studio and StarTeam for version management. Code reviews with peer developers. 1-5 minutes 25 45 30 Show
The tag cloud words are from attendees 'Current test practice'